Přenos souborů po síti je starý jako internet sám a vlastně ještě mnohem starší. Dlouhá léta se k tomu používal výhradně protokol FTP, kterému ale chybí jakékoliv zabezpečení, takže se postupně opouští. Co ale použít místo něj? Aby to bylo bezpečné, šifrované, široce podporované a všude dostupné.
Nabízí se SSH, které splňuje všechny tyto podmínky: dbá na bezpečnost, umí šifrovat autentizaci i přenos, může používat klíče nebo certifikáty, dovoluje uzavřít uživatele v jeho prostoru a je dostupné všude. Problém ovšem je, že SSH trpí při přenosu souborů malým výkonem. Pokud jste jej někdy takto používali (ať už se SCP nebo SFTP), víte, že se můžete dostat na třetinovou i nižší rychlost než tomu bývalo u FTP.
Čím je to způsobeno? Většina lidí se domnívá, že za to může přidané šifrování, které prostě vytíží procesor a ten toho nezvládne víc připravit k přenosu. Není to ovšem pravda. Pokud by tomu tak bylo, musel by být procesor během přenosu vždy vytížen naplno. Navíc by maximální propustnost byla konstantní, protože by byla dána výkonem procesoru. Ani jedno ale neplatí. Stává se, že procesor je vytížen třeba jen na třetinu a data stejně tečou pomalu, navíc se rychlost liší podle cíle naší komunikace.
Dnešní moderní procesory mají obrovský výkon a navíc mohou šifrování hardwarově urychlit. Úzké hrdlo tudíž není v něm, ale někde úplně jinde – v bufferech.
Příliš čekání rychlosti zabrání
Když v roce 1996 vznikla nová verze protokolu označovaná jako SSH2, byla jednou z velkých novinek podpora multiplexu bezpečných kanálů přes jedno TCP spojení. To umožňuje sestavit jeden kanál s jednou autentizací a poté přes něj hnát paralelně různé druhy provozu. Jelikož ale jednotlivé kanály neví nic o stavu TCP spojení pod sebou, bylo potřeba zavést řízení toku (flow control) na aplikační úrovni.
Způsob byl převzat právě z TCP a používal stejný mechanismus. Zjednodušeně řeší problém toho, že příjemce datového proudu neví, jak rychle může posílat data přes síť. Příjemce má v paměti vstupní buffer (vyrovnávací paměť), který má omezenou velikost a pokud by byl přeplněn, došlo by k zahazování paketů. Proto může příjemce signalizovat odesílateli velikost tohoto zásobníku. Odesílatel pak posílá data v přesně odměřených dávkách a čeká, až příjemce zásobu zpracuje, potvrdí ji a tím si řekne o další.
Jak se zvyšují rychlosti sítí i počítačů, stává se správná volba velikosti bufferu klíčovou. Pokud totiž používáme příliš malou vyrovnávací paměť, prodlouží se čekací doba mezi odesláním malého množství dat a jeho potvrzením. Lapidárně řečeno: odesílatel pošle pár bajtů a pak čeká na jejich průchod sítí a stejnou dobu pak čeká na návrat potvrzovacího paketu. Při malém bufferu tak vznikají zbytečně dlouhé prostoje a klesá efektivita – doba čekání je neúměrně dlouhá době skutečného odesílání. Poměr se navíc ještě zhoršuje s délkou přenosové trasy.
To si samozřejmě uvědomili tvůrci TCP stacků a proto byly v průběhu let buffery zvětšeny a byly vymyšleny různé metody, jak jejich velikost měnit dynamicky. Říká se tomu autotuning a jádro systému se snaží podle různých parametrů konkrétního TCP spojení měnit velikost vyrovnávací paměti na vstupu. Linuxové jádro například začíná na velmi skromných 85 kB a je schopno škálovat až nad 64 MB.
Bohužel, tohle OpenSSH nedělá. Přestože podkladové TCP spojení zvládne výrazně více, SSH nad ním přenášelo dříve data pouze po 64kB blocích. Později byl tento limit navýšen na 1024 kB. Tím dochází k neoptimálnímu využití sítě, které je zvlášť pozorovatelné na dnešních rychlých linkách na velké vzdálenosti. V extrémním případě kvůli tomu může rychlost klesnout i pod desetinu teoretického maxima. To je ono úzké hrdlo při přenosu souborů po SSH.
Řešením je HPN-SSH
Problémem se zabývala skupina čtyř odborníků především z Pittsburgh Supercomputing Center, jmenovitě: Chris Rapier, Michael Stevens, Benjamin Bennett a Mike Tasota. Řešením je změna velikosti vstupního bufferu na rozumnější hodnotu. Výsledkem jejich práce je HPN-SSH neboli High Performance SSH.
Jde o patch pro OpenSSH, který zavádí několik změn. Předně je to právě zmíněná úprava velikosti vstupního bufferu. V dnešních sítích by měla být tato hodnota podle tvůrců nastavena na 64 MB nebo spíše na 128 MB. Slepé navýšení této hodnoty by ale naopak vedlo ke snížení výkonu, protože by se tím pravděpodobně zahltily buffery routerů na trase, což by vedlo k zahození paketů a jejich opakování.
Proto bylo vymyšleno jiné řešení: aplikace se před každým odesíláním dat zeptá jádra operačního systému, jak velké je v danou chvíli TCP okno. Informace se tedy přenesou mezi různými vrstvami OSI modelu tak, aby se v obou případech zvolila optimální velikost. Protože na extrémně rychlých linkách (třeba na místní LAN) vytváří toto dotazování další prodlevu v přenosu, je možné jej parametrem nebo konfigurační volbou potlačit a ptát se jen při sestavování spojení.
Další problém klasického OpenSSH vzniká při šifrování dat. To je totiž s přenosem dat synchronní, takže dokud program neví, že může posílat další data, ani je nešifruje. Tím opět vzniká prodleva a vytížení procesoru není na takové úrovni, jak by mohlo být a klesá výkon celého řešení. Díky lepšímu využití přenosové cesty obvykle HPN-SSH také zefektivní použití procesoru, který se pak může stát limitujícím faktorem. Proto patch zavádí možnost zvolit jako šifrovací algoritmus NONE, tedy nešifrovat vůbec. Autentizační data zůstávají stále v bezpečí, ale samotný přenos pak probíhá nešifrovaně a tedy maximální rychlostí. Snižuje to sice razantně bezpečnost celého řešení, ale pro konkrétní účely se může taková volba hodit.
HPN-SSH se také snaží získat nějaký ten výkon pomocí paralelizace. Zatímco klasické OpenSSH provádí všechny operace s paketem sériově, zavádí patch možnost lépe využít dnešní moderní vícejádrové procesory a provádět operace paralelně. Stejně tak některé šifry (AES-CTR) dovolují paralelizovat algoritmy nebo je alespoň možné zpracovávat více paketů najednou na různých vláknech.
Výsledkem všech těchto změn je dramatický nárůst výkonu. Autoři uvádějí výsledky svých měření, při kterých se s klasickým OpenSSH dostali jen na 0,69 MB/s, zatímco HPN-SSH dosáhlo na 37 MB/s a s vypnutým šifrováním přenášených dat dokonce na 52 MB/s. To vše na 1Gb/s transatlantické lince se zpožděním 114 ms.
Kde se to dá sehnat
HPN-SSH je distribuován ve formě velkého patche, který musíte aplikovat na zdrojové kódy OpenSSH. Ty stáhnete na OpenSSH.org, patch samotný je ke stažení na SourceForge. Upravit je potřeba ideálně obě strany, přestože teoreticky stačí jen ta strana, na kterou se budou data přenášet – ta rozhoduje o velikosti svých bufferů. V praxi chcete mít ale pravděpodobně rychlejší oba směry.
Uživatelé některých distribucí to budou mít jednodušší, například v Gentoo je useflag hpn a patřičný ebuild umí sám zařídit stažení patchů a jejich aplikaci. Pozor na to, že patch není vždy dostupný pro každou verzi OpenSSH, takže vám to může rozbít automatické aktualizace. Například v Debianu bylo ale přijetí patche zamítnuto, protože správce balíků nechce situaci komplikovat přidáváním dalších velkých úprav. Ty by měly jít nejdříve do upstreamu.
Proč to není v OpenSSH
Jistě vás napadla otázka, proč tohle vlastně není součástí OpenSSH. Chris Rapier na to odpovídal na StackOverflow, kde píše, že vývojářům OpenSSH nejde tolik o výkon, takže se takto složitým a velkým patchem jednoduše nechtějí zabývat. Naštěstí to ale nebrání v jeho rozšiřování a některé velké společnosti ho běžně používají: Google, Yahoo, Apple nebo třeba NASA.
That's a long story and people who know the OpenBSD team probably already know the answer. I understand many of their reasons – it's a big patch which would require additional work on their end (and they are a small team), they don't care as much about performance as security (though there is no security implications to HPN-SSH), etc etc etc. However, even though OpenSSH doesn't use HPN-SSH Facebook does. So do Google, Yahoo, Apple, most ever large research data center, NASA, NOAA, the government, the military, and most financial institutions. It's pretty well vetted at this point.
Zdroj: High Speed Bulk Data Transfer Using the SSH Protocol [PDF], domovská stránka projektu
ČLÁNKY DO MAILU