O problému TCP-in TCP vím, ale je možné nějak čátečně tento problém odbourat nějakou optimalizací parametrů TCP? (Na spodní vrstvě - tedy na straně ssh-sshd ). Ani ne přes system-wide nastavení, to by ovlivnilo celý systém. Je mi divné, že ssh toto ještě pořád nějak neumí, pokud si pamatuju. Přejít na tunelování přes UDP je samozřejmě řešení. Nějaké speciální parametry pro ssh, jako sack, retransmit, fast open, nodelay... Jde vůbec nějak TCP "downgradovat" co nejblíž k UDP, i s vědomím, že chci rovnák a ohejbák?
A když už jsem u toho, jsou u `ssh -R` a u `ssh -w` identické problémy s propustností resp. problémy s propadem rychlosti ? Obojí běhá po ssh, ale první je jen forwarding jednotlivých TCP spojení, druhé je tunelování celé sítě. Takže tam teoreticky může být rozdíl, protože je to nějak jinak pospojované.
Tedy pomůžu si, když změním jedno za druhé?
A třetí, hodně zvídavý dotaz, dá se nějak modelovat / odhadnout pokles rychlosti, když mám danou propustnost a latenci linky tunelu (od ssh k sshd) a propustnost a latenci protistrany (anyone k konci tunelu)
Ani nevim, jesli tohle se dá nějak(dokonce univerzálně ) spočítat, musí to záležet na flagách a parametrech protistrany, což je široké spektrum OS, stacků, v jakém směru jde traffic, výkyvy v rychlosti odesílající strany..
Nějaký ,aspoň řádový odhad existuje nebo jde o nemožnou věc?
Dám příklad, z 24Mbps pokles na 4Mbps. Ale jen v jednom směru. Latence tunelu 100ms, latence protistrany 9ms, rychlost 999Mbps. Jiný koncový bod, pokles na 12Mbps
2 Odpovědí
1968 Zhlédnutí