Optimera TCP

Ett ämne man inte ser så ofta är optimering av TCP. Dom flesta av oss har väll sett popups som lovar att öka våra överföringshastigheter och sänka våran ping. Många av dess är nog fortfarande bara bluff och båg (samt spyware). Men något som faktiskt kan öka överföringshastigheter ganska dramatisk utan att man behöver köpa ny hårdvara är att öka TCP:s Windowsize.

TCP i sig är ett ganska invecklat kapitel, men lite enkelt så finns det en buffer på både sändar och mottagar sidan. Storleken på dessa buffrar bestämmer hur mycket data som kan vara påväg (skickat men inte mottaget) mellan två noder (datorer). Är dessa buffrar små och tiden det tar att skicka mellan noderna är lång kommer detta att begränsa överföringshastigheten.

Vi tar ett litet exempel, i windows xp är windowsizen satt till 17 520 bytes som standard (kan ha ändrats med nått service pack till 65k). Vi ska nu ladda hem något från en kompis. Vi testar först att pinga och ser att vi har ungefär 50ms ping. Med dessa värden kan vi räkna ut den maximala överföringen med en TCP koppling.

överföringshastighet(bytes/s) = windowsize(bytes) / ping(s)

I detta fall blir då den maximala överföringshastigheten 17520/0.05 = 350000 bytes/s. Vilket är ungefär 2.6Mbit/s. Vilket kanske inte är så kul om man har en uppkoppling som ska klara 10Mbit/s (ännu värre med 100Mbit/s såklart). 50ms ping kanske är lite högt räknat när man räknar inom sverige, men om man ska ladda hem något från USA så får man räkna med 150ms+ och då blir det ju ännu värre (max överföringshastighet vid 150ms blir då 0.9Mbit/s).

För att se vilken windowsize du har kan du gå in på följande sida http://www.speedguide.net/analyzer.php . "Default TCP Receive Window (RWIN)" är storleken på ditt window. Dom visar även vilken din maximala överföringshastighet är vid olika svarstider.

Så nu till det roliga, hur ändrar man dessa värden? Man kan gå in och rota i registret såklart, men det är inget jag gillar. Därimot har jag hittat ett väldigt bra verktyg för att ändra detta SG TCP Optimizer (http://www.speedguide.net/downloads.php). Man kan ställa in "TCP Receive Window" manuellt om man vill. Det som är viktigt är att kryssrutan för "Window Scaling" är ikryssad (annars är max windowsize ~65k). Men har man en 10Mbits lina eller mer rekomenderar jag att ni drar upp "Connection Speed" mätaren till 10k+ och klickar i "Optimal Settings".

Jag själv har en 100Mbit/s lina från BBB och jag har satt mitt Receive window manuellt till 2 044 000 vilket borde räcka för dom flesta. En sak man kan tänka på om man sätter det manuellt är att det ska vara en jämn multipel av MSS (vilket är 1460 i nästan alla fall). Så i mitt exempel har jag 1400*1460(MSS) = 2 044 000.

Ett tips till er som tvivlar, tanka tex filen ftp://ftp.kernel.org/pub/dist/knoppix-dvd/KNOPPIX_V5.0.1DVD-2... om ni får mellan 100-300kb/s på en uppkoppling som ska klara mer så vet ni att ni har för ett för litet windowsize. Testa gärna igen efter att ni optimerat och se vilken skillnad ni får.

En liten kort sammanfattning skadar kanske inte. Om man har RWIN (http://www.speedguide.net/analyzer.php) satt till ett lågt värde (17520 - 65000) och man har en hyffsad uppkoppling (10Mbit/s eller snabbare) bör man fundera på att öka detta eftersom detta kommer att begränsa uppkopplingen vid vanliga överföringar.

Några fler exempel:

Windowsize på 17 520 bytes:
-Ping 200ms = max ~0.6Mbit/s
-Ping 50ms = max ~2.7Mbit/s
-Ping 10ms = max ~13Mbit/s

Windowsize på 65 535 bytes:
-Ping 200ms = max ~2.5Mbit/s
-Ping 50ms = max ~10Mbit/s
-Ping 10ms = max ~50Mbit/s

Windowsize på 1 027 840 bytes:
-Ping 200ms = max ~40Mbit/s
-Ping 50ms = max ~150Mbit/s
-Ping 10ms = max ~800Mbit/s

Och allt detta är per TCP koppling så detta är ju inte ett max på vad eran uppkoppling klarar. Vid använding av bittorent eller liknande är detta sällan ett problem. Men vi "vanlig" nerladdning via FTP eller HTTP så spelar det större roll.

Om det av någon anledning skulle uppstå något problem så går det att återställa inställningarna via "File->Restore Backed up settings" eller "File->RestoreWindows Default Settings" (alltid bra att veta om nått skiter sig)

Edit:
Om ni inte kommer upp i ungefär 300kb/s när ni laddar hem testfilen så är det med största sanolikhet inte windowsizen som begränsar er utan något annat.

Edit2:
Detta gäller inte Windows Vista.
Vista har en funktion som heter TCP autotuning som är tänkt att ta hand om detta problem. (Det verkar även funka hyffsat)

Det är kul att se att det verkligen ger så stora ökningar, även på ADSL Det finns dock andra saker som kan sätta begränsingar för ADSL-användare tex att uploaden inte hinner med att "acka" alla paket. Men det kanske är mer vid bittorent och liknande tjänster som man märker av det.

Vad kan göra att det går långsammare? Vid packetloss kommer sändaren antingen att få Tripple-ACK eller en Timeout. Men mottagaren kommer väll aldrig att kasta bort paket? även om paket kommer i oårdning så kommer dom ju att sparasi bufferten.

Det enda negativa jag kan komma på är att det går åt mer minne för den större bufferten. Vilket man kanske ska tänka på. Tex om man sätter bufferten till 200kb och man drar igång nått Bittorent program som öppnar 100 anslutningar. Då blir det sammanlagt 20Mb i bara bufferutrymme.

Joo tcp (och även IP) har en checksum på 16bitar för felkontroll. Ethernet har dock ett 32bitars fält för felkontroll. (dock har IP bara checksum på headern)

Detta har man för att det finns inget som garanterar att länklagret eller nätlagret ska ha någon felkontroll alls. Det är ju inget som säger att man måste köra ip över ethernet

Tack för att du tar dig tid att diskutera detta. Bra och välskriven vet jag inte om jag kan hålla med om
Insiprationen till detta fick jag av en riktigt bra kurs i nätverk på universitet och en dag insåg jag att ping borde spela roll på överföringshastigheten vid TCP. Något som jag aldrig hade tänkt på förut. Efter lite mer undersökning så visade ju det sig att det var ett problem för folk med någolunda snabba uppkopplingar också. Men tillbaka till TCP

Menar du att det blir skillnad om man har olika storlekar på windowsize men dessa aldrig bromsar upp överföringen? Eller säger du att det är bra att ha ett för litet windowsize som gör att överföringen bromsas?

Jag förstår inte riktigt vad du menar eftersom fönstret är ju ett så kallat sliding window och sålänge det inte fylls upp så borde det inte spela någon roll.

Ett problem som jag kan se är om vi säger att servern skickar iväg en stor mängd paket och ett av de tidiga paketen försvinner så kommer servern att behöva skicka om allt efter det pakete som droppades. Men detta borde inte försämmra överföringshastigheten vid större fönsterstorlekar. Det enda är väll att servern har skickat mer data i "onödan". Men detta problem verkar dom ha löst med Selective Acknowledgements.

Jag har faktiskt försökt leta nackdelar med stora windowsizes men utan framgång så jag skulle vara väldigt tacksam om du kunde gå in lite mer noggrant på vad som gör att man får lägre länkuttnyttjandet vid större fönsterstorlekar.

Utan att veta vad du har för upkoppling är det ganska svårt att veta
Men om ditt windowsize är 200 000 eller mindre är det fortfarande det som sätter gränsen.

kolla på http://www.speedguide.net/analyzer.php så ser du vilket windowsize du har (RWIN).

Vill man inte ha ett så stort recive window så att det aldrig fylls? Den enda gången ett recive window ska fyllas är väll när man har en applikation som läser för sakta från socketen (flow control). I alla andra fall ska det vara congesion windowet som sätter gränsen? Så det borde inte vara någon skillnad så länge congestion windowet är mindre än recive windowet.

Eller säger du att det finns tilfällen då man kan uppnå en högre överföringshastighet med ett mindre recive window?