Windows 10 Anniversary Update maakt het IP-verkeer sneller

Noud van Kruysbergen
0

Microsoft heeft met de Anniversary Update voor Windows 10 en Windows Server 2016 vijf nieuwe features in de netwerkstack geïmplementeerd. Ze dienen allemaal om nog net iets meer uit je internetverbinding te persen.

Microsofts updates voor de jongste besturingssystemen Windows 10 en Windows Server 2016 voegen allerlei verfijningen toe waarover de community zijn zegje al uitgebreid gedaan heeft. Minder bekend is dat de updates ook gevolgen hebben voor de netwerkperformance.

Het betreft vijf nieuwe functies voor de TCP-stack (Transmission Control Protocol): TCP Fast Open, Initial Congestion Windows 10, TCP Recent ACKnowledgment, Tail Loss Probe en TCP LEDBAT.

Alle vijf verbeteren ze het gedrag bij het opvragen van internetdata door de latency te verkorten; Dat is de tijd tussen het activeren van een proces tot het uitvoeren van het gewenste effect. Interessant is dat het bij drie functies om goedgekeurde RFC-specificaties gaat, maar dat TCPRecent ACKnowledgement en Tail Loss Probe (TLP) nog experimentele concepten zijn.

Kortere latency

three_way_handshake

Three-way handshake: tot dusver kon een Windows-client pas nuttige data van een webserver opvragen als de handshake was afgerond. Dat leidt bij moderne websites tot aanzienlijke vertragingen bij de paginaopbouw. Er bestaan echter methodes om deze latencies te verkleinen.

Browsers moeten voor het laden van een website veel TCP-verbindingen opbouwen. Voor elke afzonderlijke verbinding is een 3-way-handshake nodig (zie afbeelding). Bij normale TCP-stacks worden de gewenste gegevens pas na afloop van deze handshake verstuurd. Bij één TCP-verbinding is dat niet zo’n probleem. Je hebt dan nog steeds het gevoel dat er direct wat gebeurd. Maar omdat webpagina’s content vaak van verschillende domeinen ophalen, ontstaan er veel verbindingsverzoeken voor verschillende servers en stapelen de afzonderlijke latency’s zich op, zodat je het effect wel gaat merken: de gewenste pagina wordt dan langzamer opgebouwd.

De latentie bedraagt voor elke traditionele TCP-verbinding 1,5 RTT (Round Trip Time). RTT is een relatieve waarde die afhankelijk is van de afstand tussen de client en de server waarop het benodigde pagina-element staat. Je kunt die waarde bijvoorbeeld bepalen met het ping-commando. Daarmee wordt aangegeven hoeveel tijd er zit tussen het moment dat de ping wordt verzonden en het antwoord dat van de gepingde server afkomt. Met een breedbandaansluiting moet je een nabijgelegen server in 40 à 50 ms kunnen bereiken, met een glasvezelaansluiting in zo’n 20 ms. Servers op grotere afstand antwoorden binnen 100 (VS) tot 300 ms (Azië).

Handshake

Met TCP Fast Open kun je 3-way-handshakes voorkomen die herhaaldelijk naar dezelfde server worden gestuurd. Daarvoor moet een server na de eerste keer verbinding te hebben gemaakt een cryptografisch veilige (d.w.z. zo min mogelijk voorspelbare) cookie naar de client sturen (TCP Fast Open Cookie). Die dient voor clients als sleutel om latere TCP-initialisaties met dezelfde server te versnellen: ze moeten het dan met het SYN-pakket meesturen. Een server die een geldige cookie krijgt, wacht dus niet eerst de SYN-ACK-afhandeling af, maar maakt gebruik van de reeds opgebouwde TCP-verbinding. Op die manier kunnen nuttige data meteen worden verzonden, hetgeen 1 RTT bespaart. Cookies worden periodiek om de zoveel seconden of minuten opnieuw gemaakt. De oudere worden dan ongeldig, waardoor replay-aanvallen door middel van onderschepte cookies moeilijker worden.

Extra gebruikersdata zoals cookies worden in principe in SYN-, SYN-ACK- en ACK-pakketten verstuurd. Een typisch voorbeeld is TLS-versleuteling (Transport Layer Security). Tot dusver wisselden server en client na het maken van de TCP-verbinding voor de afhandeling van TLS een server_hello en client_hello uit. De nuttige data worden daarmee pas na een RTT geleverd. Clients met TCP Fast Open stoppen de client_hello al in het SYN-pakket en besparen daarmee een RTT.

Ook webbrowsers mogen dergelijke data in het SYN-pakket meesturen – en dat al voor de eerste http-request. Dat is wel alleen toegestaan voor http-requests die herhaald mogen worden. De browser mag er namelijk niet op vertrouwen dat het besturingssysteem op de server SYN-data aan de webserver doorgeeft. Toepassingen als css en javascript, waarvan de http-requests door clients mogen worden herhaald, kunnen daarvan profiteren.

Congestion Window

De tweede belangrijke vernieuwing is de Congestion Window. Microsoft verhoogt die van 4 naar 10 MSS (Maximum Segment Size – IP-pakketcapaciteit min ethernet-, tcp- en ppp-header, vaak 1452 bytes). De Congestion Window is een door de zender berekend maximum aan data die zonder bijbehorende acknowledgements (ACK’s) onderweg mag zijn. De waarde dient ervoor om de buffers op het traject naar de ontvanger (bijvoorbeeld in routers) niet dicht te laten slibben. De zender voorkomt daarmee pakketverlies ten gevolge van te volle buffers.

Geen enkele host kent de maximale snelheid van een gebruikt transporttraject, dus probeert de host stap voor stap het maximaal haalbare te bereiken door de Congestion Window te verdubbelen zolang hij ACK’s ontvangt (slow start). Als die uitblijven, gaat de host uit van een verbindingsfout, waarna de zendsnelheid wordt gehalveerd.

Hoe kleiner de Congestion Window aan het begin van de verbindingsopbouw, des te langzamer de versnelling. Dat betekent: hoe korter een bestand, des te minder het een verbinding bij een kleine Congestion Window optimaal benut. De nu vergrote initiële Congestion Window past precies bij dit scenario. Korte bestanden hebben dus meer profijt van een snelle verbinding omdat ze in een of meerdere grote stukken worden overgezet.

Verbindingsfouten

Soms komt het voor dat gegevens aan het eind van een transmissie hun doel niet bereiken (Tail Loss Probe, TLP). De zender ontvangt dan de ACK’s voor de laatste segmenten niet. Normaal moet de zender dan minstens een seconde wachten voordat hij nog een keer zendt. Deze latentie kan met de functie Tail Loss Probe worden verminderd. De zender mag daarbij een herhaling starten zodra ACK’s gedurende 2 RTT’s uitblijven. Als de zender vervolgens wel ACK’s ontvangt, geeft hij die door zonder de Congestion Windows opnieuw te berekenen – net als bij SACKs.

Met Recent ACKnowledgement (RACK) reageert de server eerder op dataverlies. Bij de gangbare methode wacht de ontvanger een tijdje en stuurt dan vervolgens nog een keer de ACK die bij het laatst ontvangen segment hoort. Daarmee wordt pakketverlies aangegeven (duplicate ACK). Daarna stuurt de zender de gegevens die hij na de dubbele bevestiging had verzonden opnieuw.

Met RACK wacht de zender niet op dubbele ACK’s, maar houdt hij bij wanneer ACK’s zouden moeten binnenkomen. Als een ACK binnenkomt voor een segment dat duidelijk later werd verzonden dan data waar geen ontvangstbevestiging van is ontvangen, gaat de zender ervan uit dat de eerdere segmenten verloren zijn gegaan en stuurt hij ze opnieuw. Op die manier worden onbevestigde segmenten eerder opnieuw verzonden. Microsoft schakelt deze feature alleen in bij verbindingen waarvan de latentie meer dan 10 ms bedraagt. Bij lokale netwerkverbindingen blijft die dus uit. Dat lijkt zinvol omdat de berekeningen door de geringe latentie grote afwijkingen hebben.

Bewust vertragen

TCP LEDBAT (Low Extra Delay BAckground Transport) werd speciaal ontwikkeld voor niet-tijdkritische dataverbindingen op de achtergrond. Als een deelnemer te snel data stuurt, lopen de buffers vol. Daardoor wordt de latentie hoger omdat alle pakketten die erna in de buffer komen op hun beurt moeten wachten. TCP LEDBAT wordt door de zender gebruikt om datastreams met een lagere prioriteit ook navenant langzamer te versturen.

Hiervoor schat de zender regelmatig de latentie van de verbinding in door veranderingen van de Congestion Windows te analyseren. Een simpelere manier om de latentie te bepalen is door de tijd tussen het verzenden van een pakket en het aankomen van de bijbehorende ACK te bepalen. Als deze afstand toeneemt, gaat de zender ervan uit dat de buffers vollopen. Andere TCP-verbindingen maken immers ook gebruik van de lijn. Dan verlaagt de zender zijn zendsnelheid tot de latentie ook weer afneemt.

Er zijn commerciële traffic-shapers die de belasting van buffers al een aantal jaren kunnen meten. Een voorbeeld is cFos-Speed, waaraan ook de auteur van dit artikel heeft meegewerkt. Deze tool meet de latentie tot de volgende hop.

Microsoft heeft deze functie voor applicatieontwikkelaars geïmplementeerd als socket-option. Het kan handig zijn voor filesharing- of mailprogramma’s als ze lange e-mails versturen. Hoe developers deze functie kunnen gebruiken is tot nog toe niet gedocumenteerd. Microsoft geeft de details op aanvraag.

Meer informatie

(Martin Winkler/Marcel van der Meer)

Deel dit artikel

Lees ook

Managed vs unmanaged VPS: waar ligt het omslagpunt?

Kies je voor ontzorging in de vorm van managed VPS of wil je liever volledige technische vrijheid in de vorm van unmanaged VPS? Dat is de vraag die je...

Wireshark netwerk analysetool vernieuwd: Npcap en meer

Wireshark is ongetwijfeld de meest gebruikte netwerk analysetool. We laten de belangrijkste vernieuwingen zien door de overstap naar Npcap en gaan in ...

0 Praat mee

avatar
  Abonneer  
Laat het mij weten wanneer er