Vlákno názorů ke zprávičce Jak zrychlit ssh od soriako - ale copak, že by ipv6 nakonec nebylo tak...
-
Záleží na tom, jak je v síti šestka zavedená. Pokud je tam nějaký tunel, může mít konektivita přes něj jiné vlastnosti než ta nativní. Ale to platí o jakémkoliv tunelování, u VPN to bude stejné.
Ale v běžném provozu není důvod, aby byl přenos pomocí jednoho protokolu rychlejší než pomocí jiného. Dnes je klidně možné čtyřku tunelovat čistě šestkovou sítí a taky to funguje stejně rychle.
-
MartinX (neregistrovaný)
IPv6 ma kvoli dlhsim adresam o trochu vacsi overhead (pomer hlavicky paketu k celkovemu mnozstvu prenasanych data), takze prenos bude urcite o nieco pomalsi ako IPv4. Prejavit sa to moze specialne pri aplikaciach ako SSH, kde sa kvoli interaktivite prenasaju relativne kratke pakety.
Takisto implementacia IPv6 stacku nemusi byt az tak optimalizovana, ako pri IPv4 stacku, kde sa vyvoju venoval dlhsi cas. Pri IPv6 je castokrat skor prioritou "aby to aspon fungovalo" a na performance optimalizaciu uz neostava cas a peniaze.
Z praktickeho hladiska bude ale, hlavne pri interaktivnom pouziti ssh (teda nie scp, sftp alebo sshfs), rozdiel minimalny. -
To je nesmysl. SSH v2 kompresi normálně podporuje. U SSH v1 se dá ještě ovládat "CompressionLevel", ale to neznamená, že u SSH v2 žádná není.
Viz man ssh:
-C
Requests compression of all data (including stdin, stdout, stderr, and data for forwarded X11, TCP and UNIX -domain connections). The compression algorithm is the same used by gzip(1), and the “level” can be controlled by the CompressionLevel option for protocol version 1. Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks. The default value can be set on a host-by-host basis in the configuration files; see the Compression option.
(o tom, že by SSH v2 nepodporovala kompresi tam nic není)a viz třeba tady:
https://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_05.htm#ch03-57773.html -
tom (neregistrovaný)
IPv4 je rychlejsi, protoze HW je na ni optimalizovan. Vsechno od TCP/UDP checksumu az po to, aby TCP ramce jednoho spojeni skoncili v L2 cache stejneho jadra, bude mnohem casteji implementovano pro IPv4 a jeste jsem nevidel HW, ktery by to umel pro IPv6 a pro IPv4 ne. Tvrdit, ze budou funguvat stejne rychle, je celkem zavadejici.
-
tom (neregistrovaný)
Zalezi na zatezi, na in-house HW/SW mame pri ocekavane zatezi o ~20% vetsi propustnost pokud se dorucuji ramce jednoho TCP spojeni na jedno jadro a ve spravnem poradi oproti tomu, pokud se to nedela. Samozrejme rozdil temer zmizi, pokud je tolik spojeni, ze se navzajem vystrkaji z cache.
Pokud se dela routovani/QOS/balancing v HW na L7, tak je to radove uplne jinde, nez pokud se na ramec musi divat SW, protoze rozhodujici data byla v ramci moc daleko na to, aby se HW mohl rozhodnout, co udelat.
-
. . (neregistrovaný)
měřil jsem rozdíl u infinibandu (od Mellanoxu) u IPoIB rozhranní a tam je u 56 Gb/s linky mezi servery ve stejném racku a rozdíl byl do 3 % ve prospěch ipv4. Redhat 7.3.
Poté mohu mluvit o reálném nasazení u několika klientů v ČR u interní sítě (desítky tisíc stanic) a tam ipv6 poskytuje lepší výkon, má průměrně o 1/3 méně hopů a ušetřilo se hodně díky absence NATu, opět ale rozdíl do 10 %.
Generické testy mi poskytuje v laboratorních podmínkách hodně podobné výsledky, většinou na 8000 Ciscách.
Mít naopak internet na ipv6 je i na velké služby často o dost pomalejší, Facebook a další velké obsahovky nemají asi dobré trasy pro ipv6, nevím, nejsem na takové síti.
-
j (neregistrovaný)
Zkousel sem nekoli ruznych tras po netu (= nikoli lan) na 4/6 nekdy je vic hopu na 6 jindy na 4 (klidne dvojnasobek). Rozdil latence do max 30%, ale na obe strany. Ovsem pri zapocitani poctu hopu mi obecne vychazi to, ze 6ka ma per hop zhruba polovicni latenci. Coz bych pricet predevsim tomu, ze tam bude novejsi a vykonejsi HW.
Co se tyce prutoku dat ... vychazi to +- 1% => nemeritelne. Ale obecne se da rict, ze se na 6tce v mnoha pripadech dostanes vyrazne vejs - predevsim na p2p sitich ti mnohem rychlejs klient saturuje linku, a to i za situace, kdy tech peeru co maji 6tku je trebas jen kolem 20%. Pricemz mluvim o situaci, kdy ma klient jak verenou 6tku tak verejnou 4ku. Pokud by verejnou 4ku nemel, bude to pocitam rozdil jeste mnohem razantnejsi.
Trebas yt mi po nativni 6tce jede subjektivne trochu lip, v pripade tunelovany 6tky je to nastejno se 4kou - aby ne, kdyz ten tunel po ni jede - proste to obcas reaguje jak zpomalenej film, ale na 6tce se to deje mene casto.
-
. . (neregistrovaný)
na jednom jádře nedokážeš takovouhle konektivitu saturovat, ty servery potřebují desítky jader, multi-thread napi pro ethernet je samozřejmost.
Tohle je intra-rack komunikace, žádný L3 switching se nepoužívá, nepotřebuješ routovat podle IP adresy. A ano, ipv6 je udělaná právě takhle divně, aby se využila infrastruktura pro ipv4 a nebylo potřeba výrazněji měnit HW.
-
lojzak (neregistrovaný)
@tom
"Vsechno od TCP/UDP checksumu az po to, aby TCP ramce jednoho spojeni skoncili v L2 cache stejneho jadra"
TPC/UDP jsou ale úplně jiné vrstvy. Co má společného poćítaní checksumTCP/UDP s nižší IP vrstvou?"Tvrdit, ze budou funguvat stejne rychle, je celkem zavadejici."
A to si jenom myslíš, nebo jsi to měřil?IPv6 má sice delší hlavičku, ale zato pevné velikosti, což usnadňuje zpracování.
-
lojzak (neregistrovaný)
"Pokud checksum pocita HW, tak chodne, protoze pokud HW nizsi vrstve nerozumi, tak ho nespocita."
1) Transportní vrstva není vyšší oproti síťové. Síťová vrstva je níže než transportní vrstvou. Znamená to tedy, že TCP/UDP datagramy jsou zabaleny v IP paketu. Z toho vyplývá, že pokud pošlu stejná data po IPv4 a IPv6, tak TCP/UDP datagramy budou v obou případech stejné. Lišit se budou teprve na L3 a níže.
HW tedy bude počítat checksum pro TCP/UPD datagram, který přišel přes IPv4 úplně stejně jako pro TCP/UDP datagram, který přišel po IPv6.2) IPv6 packet má hlavičku pevné délky, což je pro zpracování na HW úplně lepší (jednodušší HW).
3) IPv6 packet je jednodušší. Úplně třeba zmizel checksum, který se u IPv4 musí počítat.
-
pb. (neregistrovaný)
Ono to může být klidně tím, že na IPv4 jsou reverzní záznamy nastavené, na IPv6 ne. Potom nezdržuje IPv6, ale DNS, i když připojení přes IPv4 je okamžité, ale přes IPv6 si člověk počká. Když nebudete mít nastavené reverzní záznamy u IPv4, ale u IPv6 ano, situace se obrátí.
Tunely jsou taky kapitola sama pro sebe. Pokud potřebuju někam často rychlé spojení, ale k dispozici je pouze připojení přes HE, dělám si raději sit tunel - nemusím tlačit data přes půl světa. Tohle ale není problém IPv6, ale neschopného ISP.
Velmi často používám na IPv6 ipsec. U ipsec nebývá spojení k dispozici neustále, při prvním spojení se může provoz občas trochu zdržet. Na IPv4 by se dalo šifrování mezi dvěma IP zapnout taky, ale jednu stranu obvykle není možné nikam napojit (NAT). Tady už by bylo srovnání rychlosti IPv4 a IPv6 vyloženě nefér, protože na IPv4 ipsec asi nikdo nepoužívá.
ČLÁNKY DO MAILU