Tcp torlódásszabályozás, vagy miért ugrik ki a sebesség, csak mentsearlharbor
Valaha volt feltöltve egy fájl, és a sebesség lassan, de biztosan megnövekszik, aztán egy bizonyos ponton élesen csökken, majd ismét nő? Fájl feltöltése egyetlen adatfolyamba nem biztosít teljes csatorna-sebességet? Futtasd a torrent klienst, és a ping a játékban erősen ugrik? Használsz egy 3G modemet (vagy egy másik, viszonylag nagy csomagvesztéssel rendelkező vonalat), és nem tudod elviselni?
Biztosan hibáztattad az útválasztóját mindent, vagy azzal vádolta a szolgáltatóját, hogy alakítsa ki a formát? Érinti, de nem hibás.
Így találkozunk:
TCP-torlódásszabályozás vagy TCP torlódás-elkerülési algoritmus.
Mi ez?
Röviden, olyan algoritmusok, amelyek mindent megtesznek annak érdekében, hogy a leggyorsabb adatátviteli sebességet biztosítsák a két TCP-n keresztül továbbított csomópont között. Ezek szabályozzák a TCP ablak méretét, és célozhatják az RTT-t (Round Trip Time - a kérelem elküldéséhez szükséges idő a válasz átvételére), a csomagok elvesztését, a várakozási időre való várakozást, stb. Minden algoritmus másként viselkedik ebben a helyzetben, és nincs univerzális.
Melyek az algoritmusok?
Sokan vannak. A Linux 3.7 kernelben vannak:
- BIC TCP
- CUBIC TCP
- Highspeed TCP
- H-TCP
- TCP Hybla
- TCP-Illinois
- TCP alacsony prioritás
- TCP Vegas
- TCP NewReno
- TCP Veno
- TCP Westwood +
- Ja-TCP
BIC, CUBIC, Highspeed, H-TCP, NewReno, Illinois - ezeket az algoritmusokat az úgynevezett hosszúhálós hálózatokra tervezték - hosszú (és ezért magas RTT) és gyors hálózatokkal. A TCP Hybla műholdas kapcsolatokkal viselkedik, és a Veno vezeték nélküli hálózatokra van kialakítva, amelyek nagy csomagvesztéssel járnak. A TCP Low Priorityt alig lehet szűk keresztmetszeti algoritmusnak nevezni. Csekély, de egyszerűen próbál egy csomagot várakozás nélkül küldeni, a TCP Vegas-ot néha számos kapcsolaton keresztül használják, mert szinte állandó sebességet biztosít, bár messze nem ideális. A Westwood + egy kombinált algoritmus, a YeAH-TCP a legfiatalabb közülük, de a legérdekesebb, mert minden esetben többé-kevésbé viselkedik.
Az algoritmusokkal kapcsolatos további információk a post casperrr-ben találhatók
Amint láthatja, a CUBIC elmarad. Jelentősen növelte az RTT-t a 3G-csatorna teljes kihasználtsága mellett, míg a Westwood + és a NewReno többé-kevésbé megbirkózik ezzel a problémával.
Vessünk egy pillantást az újbóli átvételek számára:
Amint az a grafikonból látható, a CUBIC viszonylag sok újraküldése van
Ugyanakkor az egységnyi időegység adatátviteli sebességének vezetője.
Mit jelent ez? Ez azt jelenti, hogy a Westwood + vagy a NewReno használatával kényelmesen navigálhat az interneten, miközben nagy fájlt tölt le.
Nagysebességű csatorna teszt
A hatékony adatátvitelnél, az RTT-től függően, igen
A tényleges adatátvitel és a csomagvesztés függvénye, ismét YeAH az első helyen
Sajnos, a Yeah a 3.7-es kernelben néhány problémát okozott, egy idő múlva mérlegeli a rendszer szoftver interrupt'ami programját. Ezt a viselkedést a 3.6.
Hogyan lehet megváltoztatni?
Nagyon egyszerű változtatni a torlódási algoritmust, csak egy sort:
sysctl -w net.ipv4.tcp_congestion_control = westwood
Ahol a westwood helyett a / lib / modules /.../kernel/net/ipv4/tcp_....ko neveket illesztheti a tcp_ előtag nélkül.
Ahelyett, hogy befejezné
Az olyan csatornákon, mint az otthoni WiFi, javaslom a Westwood vagy a Veno használatát. Vezetékes csatornák esetén Igen (ha nincsenek benne problémák), a H-TCP vagy Illinois jó választás lehet.
Néhány tipp. Ha már rendelkezik 3.6+ rendszermaggal, feltétlenül engedélyezze a net.ipv4.tcp_fastopen engedélyezését. Nem lesz probléma az inkompatibilis szerverekkel, és a támogatott kiszolgálókhoz való kézfogás felgyorsul.
Azt is javaslom, hogy a net.ipv4.tcp_slow_start_after_idle értékét 0-ra állítsd, ez növeli az SPDY és egyéb tartós kapcsolatok sebességét.