TCP window scaling az Interneten

Címkék

2004 közepén egy általam csak "HUP bug"-nak nevezett problémát fedeztünk fel itt a HUP-on, amely rejtélyes kapcsolatban állt az akkor kiadás előtt álló 2.6.8-as Linux kernellel. A jelenség az volt, hogy bizonyos újabb kerneleket futtató kliensekkel a HUP nem volt olvasható. Akkor némi kutakodás után kiderült, hogy David S. Miller engedélyezte az akkori Linux kernelekben a TCP window scaling-et. Ezzel az eljárással a kommunkációban levő felek nagyobb adatmennyiséget is átvihetnek egymás közt, akkor ha ezt előre "megbeszélik". A TCP window scaling-gel kapcsolatos tudnivalókat az RFC1323 fogja össze. Bővebben a TCP window scaling-ről a korábbi, "HUP bug": TCP window scaling és a hibás routerek című HUP cikkben.
A lényeg az, hogy bizonyos TCP window scaling beállítások mellett nem volt olvasható néhány weboldal (köztük a HUP is), ha a webszerver és a kliens között olyan csomagszűrő / router volt található, amely nem kezelte megfelelően ez a TCP opciót, vagy a cél webszerveren nem követett el az adminisztátor bizonyos workaround-okat.

Most ismét hasonló problémával nézhet szembe az, aki a legújabb, kiadás előtt álló 2.6.17-es Linux kernelre frissít. Sok bosszúságtól kímélheti meg magát az, aki figyel, és visszaemlékszik majd erre a cikkre :-)

Nemrég Mark Lord jelezte az LKML-en, hogy a kiadás előtt álló 2.6.17-es kernellel nem tudja olvasni a www.everymac.com-ot. Miután elvégzett egy csomó tesztet, behatárolta, hogy a problémát egy nemrég felbukkant, "set default max buffers from memory pool size" nevű patchset okozza. John Heffner válaszul azt írta, hogy valószínűleg Mark gépe és a szóban forgó webszerver közt egy hibás (lásd a korábbi cikk) gép van, amelyet javítani kellene. Addig Mark a problémára a window scaling tiltását használhatja workaround-ként.

Linus megjegyezte a problémával kapcsolatban, hogy lehet, hogy nem kellene feltétlenül alapértelmezetten engedélyezniük a window scaling-et, vagy ha igen, akkor ki kellene dolgozni egy eljárást, amely észleli, ha az valamilyen oknál fogva az nem alkalmazható.

David Miller válaszában megjegyezte, hogy a window scaling már hosszú ideje alapértelmezetten engedélyezett, de csak 1-es vagy 2-es faktorral használták eddig. Továbbá válaszában megjegyezte, hogy nem lehetséges a hibás gépek detektálása és a window scaling kikapcsolása azután, hogy azt a kommunikációban résztvevő felek megbeszélték. Ezen kívül megjegyezte, hogy a window scaling 14 éve szabványosított és itt van körünkben azóta, amióta 1992. májusában publikálták az RFC1323-ban. Feltette a kérdést, hogy vajon mennyi ideig kellene még várni arra, hogy egyesek megfelelően használják?

A KernelTrap cikke itt.

Összefoglalva: ha valaki 2.6.17-rc5-ös vagy annál újabb kerneleket* használ, akkor alapértelmezetten problémája lehet olyan oldalak böngészésekor (vagy más szolgáltatások elérésekor), amelyeket úgy ér el, hogy közte és az oldal közt hibásan működő csomagszűrő / router található. Ha ilyen oldallal találkozik, akkor workaround-ként használhatja a következőt:

root@alderaan:/home/trey# echo "0" > /proc/sys/net/ipv4/tcp_window_scaling

vagy

root@alderaan:/home/trey# sysctl -w net.ipv4.tcp_window_scaling=0
net.ipv4.tcp_window_scaling = 0

Az aktuális érték lekérdezése:

root@alderaan:/home/trey# cat /proc/sys/net/ipv4/tcp_window_scaling
0

Maradandó beállítást a /etc/sysctl.conf-ban lehet elvégezni.

* Én 2.6.17-rc5-ös kernellel tapasztaltam azt a problémát, amelyet a www.everymac.com-mal kapcsolatban írtak. Korábbi -rc verziókkal is jelentkezhet a probléma, de azokkal nem teszteltem. Megjegyzem, hogy a 2.6.17-rc5-ös kernelt május 29-e óta használom probléma nélkül, és ha nem hívják fel a figyelmet a problémára, akkor valószínűleg észre sem veszem. Magyarul, valószínűleg meglehetősen kevés oldal (szerver, szolgáltatás) érintett a problémában.

Hozzászólások

Azt hiszem ez nem csak linuxoknál jelenthet problémát, hanem szinte minden oprendszeren, ahol ez default be van kapcsolva.

Mert valószínűleg ott fogom először észrevenni. Mint ahogy annak idején a HUP-nál is a web-nél vették észre, és most is egy weboldalnál vették észre. Az, meg hogy nem csak webet érint, azt hiszem egyértelmű. Aki megérti, hogy mi van a cikkben leírva, annak meg nem is kell magyarázni. Aki meg nem érti, annak meg tök mindegy.

--
trey @ gépház

Nekem vannak ilyen problémáim mostanság, de gőzöm sincs, h mi a gond. Van 1 pár gép itthon, mindenféle OS-ek, és adott weboldalak sehonnan sem jönnek be, némelyik bejön, de hibásan... stb. Akartam a router-re új firmware-t tenni, az Edimaxnak asszem nyílt forráskódú, unix-szerű firmware-e van, de az edimax.com sem jön be. Google sokmindent talál, de onnan meg szinte egy sem nyílik meg. Lehet, h SUX-Online para, de nekem nem teccik így.

FreeBSD-n kb 4 eve tortent hasonlo, szinten rfc1223 miatt. FreeBSD <-> barmi teljesen jol mukodott, viszont FreeBSD <-> FreeBSD csigalassu adatforgalom. Szoltam szolgaltatonak, de nem igazan tudtak mit csinalni vele, ugyhogy vegul ki lett kapcsolva a szerveren.

Amikor ez a probléma jelentkezett a HUP-pal (FreeBSD), akkor ki lett kapcsolva a
"net.inet.tcp.rfc1323". Utána nem volt probléma. Ha valahol ilyen probléma van útközben, akkor érdemes a szerveren kikapcsolni a window scaling-et. Persze csak akkor, ha nincs mód a javításra (mert más kezeli a hibás box-ot).

A HUP-on egyébként most is 0 az "net.inet.tcp.rfc1323" sysctl érték, úgyhogy a HUP-pal biztos nem lesz ilyen problémája senkinek.

--
trey @ gépház