De transportlaag: UDP en TCP

Een applicatie verzendt via een socket, de interface tussen haar proces en de transportlaag. De transportlaag laat processen op verschillende hosts lijken alsof ze direct communiceren. Dit is logische communicatie: de gegevens gaan nog steeds over verbindingen en via routers, maar de applicatie werkt via haar lokale socket.

Volg de gegevens door de lagen

Bij de zender neemt het transportprotocol applicatiegegevens, verdeelt die zo nodig in stukken en voegt een transportheader toe. Het resulterende segment gaat naar IP. IP voegt zijn eigen header toe, waardoor een IP-datagram ontstaat dat het netwerk transporteert. Op de bestemming geeft IP het segment aan het transportprotocol, dat de transportheader interpreteert en de gegevens bij een socket aflevert.

De protocollogica wordt uitgevoerd op de eindhosts. Gewone routers sturen IP-datagrammen door; ze verzorgen geen TCP-ontvangstbevestigingen en hertransmissies namens de applicaties. Zie een IP-adres als het adres van een gebouw en de ontvangende socket als de beoogde ontvanger binnen. Een brief naar het gebouw brengen en die bij de juiste persoon bezorgen zijn afzonderlijke taken.

IP biedt aflevering tussen hosts zonder garanties. Datagrammen kunnen verloren gaan, dubbel aankomen, van volgorde veranderen of beschadigd raken. De transportlaag breidt de aflevering uit naar processen en kan mechanismen toevoegen die deze problemen herstellen.

Vergelijk de diensten

UDP, het User Datagram Protocol, voegt poorten en een foutcontrole toe aan de aflevering van IP. Een segment kan aankomen zonder voorafgaande uitwisseling om een verbinding op te zetten. UDP herstelt een verloren segment niet en houdt een later segment niet vast totdat een eerder segment aankomt.

TCP, het Transmission Control Protocol, bouwt verbindingstoestand op vóór de normale gegevensoverdracht. Het nummert bytes, controleert op fouten, ontvangt bevestigingen en verzendt ontbrekende gegevens opnieuw. De ontvangende applicatie krijgt een betrouwbare bytestroom in volgorde. Stroomregeling beschermt de buffer; congestiebeheersing reageert op de netwerkbelasting.

Betrouwbaarheid maakt het onderliggende netwerk niet betrouwbaar. Als een IP-datagram verdwijnt, verstuurt TCP een nieuwe kopie van de ontbrekende gegevens. Als latere bytes eerder aankomen, kan de ontvanger ze vasthouden totdat het ontbrekende deel is aangevuld. De applicatie ziet een herstelde aflevering, maar moet mogelijk langer wachten. TCP noch UDP kan een uiterste aflevertijd beloven of netwerkcapaciteit reserveren alleen doordat het boven op IP zonder garanties werkt.

Kies de dienst bij de socket

Een streamsocket kiest doorgaans TCP; een datagramsocket kiest UDP. HTTP/1.1 en HTTP/2, e-mailoverdracht met SMTP en inloggen op afstand met SSH gebruiken TCP. Gewone DNS-query's gebruiken vaak UDP. HTTP/3 gebruikt QUIC boven op UDP: QUIC biedt betrouwbare streams en beveiliging boven op de minimale dienst van UDP.

Een TCP-verbinding alleen houdt een wachtwoord niet geheim. TLS voegt versleuteling en authenticatie toe boven op TCP; QUIC integreert TLS in zijn ontwerp. Betrouwbaarheid gaat over de vraag of bytes correct en in volgorde bij de applicatie aankomen. Vertrouwelijkheid gaat over de vraag of een waarnemer ze kan lezen.

Een host heeft vaak veel sockets open. Multiplexing verzamelt uitgaande gegevens van die sockets en voegt transportheaders toe. Demultiplexing selecteert voor elk aankomend segment de ontvangende socket.

Lees de adresgegevens

Zowel TCP als UDP bevat een 16-bits bronpoort en een 16-bits bestemmingspoort. De waarden lopen van 0 tot 65.535. De bestemmingspoort identificeert de ontvangende dienst; de bronpoort helpt de andere kant het antwoord te adresseren. IANA verdeelt poorten in systeempoorten 0–1023, gebruikerspoorten 1024–49151 en dynamische poorten 49152–65535.

Servers luisteren op afgesproken poorten: SSH gebruikt 22, SMTP 25, DNS 53, HTTP 80 en HTTPS meestal 443. Clients krijgen meestal een tijdelijke poort van het besturingssysteem. Het ingestelde bereik hoeft niet gelijk te zijn aan het dynamische bereik van IANA: een gebruikelijke Linux-standaard is 32768–60999, terwijl Windows meestal 49152–65535 gebruikt.

Bij een aankomend IP-datagram bepaalt de host eerst het transportprotocol. IPv4-protocolwaarde 6 betekent TCP en 17 betekent UDP; IPv6 identificeert het protocol van de bovenliggende laag via de keten van volgende headers. TCP-poort 53 en UDP-poort 53 behoren tot verschillende naamruimten van transportprotocollen. Daarna gebruikt de ontvanger adressen en poorten om een socket te selecteren en plaatst hij de gegevens in een wachtrij voor de applicatie.

UDP: veel clients, één ontvangende socket

In het basismodel van een niet-verbonden UDP-server wordt de ontvangende socket geselecteerd op basis van IP-bestemmingsadres en bestemmingspoort. Verschillende clients kunnen allemaal naar dezelfde socket sturen.

Een server op 203.0.113.53 luistert op UDP-poort 53. Verzoeken van 198.51.100.7:51000 en 192.0.2.44:62011 bereiken deze ene serversocket. Het eerste antwoord gaat van 203.0.113.53:53 naar 198.51.100.7:51000. De applicatie krijgt het bronadres en de bronpoort van elk verzoek, zodat ze de juiste client kan antwoorden. Een verbonden UDP-socket kan ook beperken van welke andere partij die ontvangt; er wordt geen UDP-handshake toegevoegd.

TCP: onderscheid verbindingen met vier waarden

Een TCP-server heeft een luistersocket en afzonderlijke verbindingssockets. Een verbinding wordt geïdentificeerd door het viertupel van IP-bronadres, bronpoort, IP-bestemmingsadres en bestemmingspoort.

Voor een server op 203.0.113.10:80 zijn dit verschillende verbindingen:

• 198.51.100.7:50312 → 203.0.113.10:80
• 198.51.100.7:50313 → 203.0.113.10:80
• 192.0.2.44:50312 → 203.0.113.10:80

De eerste twee verschillen in bronpoort. De eerste en derde delen een bronpoort maar verschillen in bronadres. Alle drie gebruiken serverpoort 80. Een aparte serverpoort per client is niet nodig, omdat het volledige viertupel hun verbindingssockets onderscheidt. Eén proces kan veel van zulke sockets afhandelen.

Als geen socket overeenkomt

Een SYN die naar een gesloten TCP-poort wordt gestuurd, krijgt normaal een TCP-reset terug, met de RST-vlag aan. Een UDP-segment dat naar een poort zonder ontvanger wordt gestuurd, leidt normaal tot een ICMP-melding “poort onbereikbaar”. Firewalls, filtering en beperkingen op antwoorden kunnen beïnvloeden wat terugkomt. Bij een poorttest wijst SYN-ACK op een luisterende TCP-dienst; RST duidt op weigering. Alleen stilte kan filtering niet onderscheiden van verlies of een host die niet beschikbaar is.

UDP verstuurt elk bericht onafhankelijk, zonder handshake of gedeelde verbindingstoestand voor volgnummers. De vaste header van 8 bytes bevat vier velden van elk 16 bits: bronpoort, bestemmingspoort, lengte en controlesom.

Tel de juiste bytes

De lengte omvat de UDP-header plus de gegevens. Die is minstens 8 bytes. Een bericht met 40 gegevensbytes heeft UDP-lengte 48. Met een IPv4-header van 20 bytes en zonder IP-opties is het volledige IP-datagram 68 bytes. De IP-header valt buiten de UDP-lengte.

De controlesom detecteert sommige bitfouten in de UDP-header en gegevens. Die omvat ook een pseudoheader die is opgebouwd uit IP-adresgegevens, het protocolnummer en de UDP-lengte. Die waarden helpen een segment te detecteren dat onder de verkeerde adresgegevens is afgeleverd. De pseudoheader is invoer voor de berekening; het is geen extra verzonden deel van de UDP-header.

Tel op met teruggevoerde overdracht

Behandel de invoer voor de berekening als 16-bits woorden. Zet het controlesomveld tijdens de berekening op nul. Tel de woorden op en voer elke overdracht voorbij bit 16 terug naar de lage kant. Dit is eencomplementoptelling. Keer ten slotte alle 16 bits van de teruggevoerde som om om de controlesom te krijgen. Als het aantal bytes oneven is, voeg je alleen voor de berekening een nulbyte toe.

Gebruik voor drie voorbeeldwoorden hexadecimale notatie om de overdracht zichtbaar te maken:

1. Tel A35C en 69C3 op tot 10D1F. De eerste 1 is een overdracht buiten 16 bits.
2. Voer die terug: 0D1F + 1 = 0D20.
3. Tel 1234 erbij op: 0D20 + 1234 = 1F54.
4. Neem het complement van elke bit: FFFF − 1F54 = E0AB.

De controlesom is E0AB. Als je de eerste overdracht simpelweg weglaat, krijg je de verkeerde som. Binair is de eindsom 0001 1111 0101 0100 en het complement daarvan 1110 0000 1010 1011.

Controleer bij de ontvanger

De ontvanger herhaalt de optelling met terugvoering over de pseudoheader en het ontvangen segment, nu inclusief het controlesomveld. Een ongewijzigd segment geeft alleen enen, FFFF. Hier geldt 1F54 + E0AB = FFFF. Een resultaat met een nulbit wijst op een fout. UDP verwerpt een segment waarvan de meegeleverde controlesom, als die niet nul is, de controle niet doorstaat zonder melding; het stuurt geen vervanging en herstelt de gegevens niet.

Alleen enen betekent dat de controle is geslaagd, niet dat elke mogelijke fout is uitgesloten. Compenserende veranderingen in verschillende woorden kunnen de som ongewijzigd laten. De controlesom detecteert fouten; die lokaliseert de verkeerde bits niet en corrigeert ze ook niet.

Waarom de eindhosts opnieuw controleren

Een controle op de verbinding beschermt een bepaalde verbinding. Sommige verbindingen hebben die controle mogelijk niet en ook binnen apparatuur tussen verbindingen kan beschadiging optreden. Een eind-tot-eindcontrole toetst wat de bestemmingshost heeft bereikt. Dit illustreert het eind-tot-eindprincipe: een eigenschap die over het hele pad nodig is, moet op de eindpunten worden gecontroleerd.

Bij IPv4 geeft een UDP-controlesomveld met waarde nul aan dat de zender de controlesom heeft weggelaten. Een berekende controlesom van nul wordt als allemaal enen verzonden om dit onderscheid te behouden. IPv6 vereist normaal een UDP-controlesom, met nauw omschreven uitzonderingen voor tunnels. TCP gebruikt ook een internetcontrolesom met een pseudoheader en vereist die controlesom.

De beperkte dienst van UDP geeft een applicatie controle over haar berichten. Er is geen transporthandshake vóór het eerste bericht, geen UDP-hertransmissiewachtrij en geen UDP-mechanisme dat latere gegevens vasthoudt achter een ontbrekend eerder bericht. De applicatie beslist wat ze verzendt en welk verlies van belang is.

Stem herstel af op het tijdstip waarop gegevens nog bruikbaar zijn

Neem spraakaudio die in stukken van 20 ms wordt verzonden: 50 berichten per seconde. Een ontbrekend stuk moet over 60 ms worden afgespeeld, maar het detecteren van het verlies en het verkrijgen van een nieuwe kopie duurt ongeveer 150 ms. Dat herstelde stuk zou te laat aankomen. Een spraakapplicatie kan latere stukken op tijd afspelen en het ontbrekende geluid maskeren, bijvoorbeeld door de onderbreking af te vlakken.

De bepalende grootheid is de resterende tijd tot het afspelen, niet de duur van 20 ms van één stuk. Als herstel vóór de deadline kan worden voltooid, kan hertransmissie helpen. TCP moet bytes in volgorde afleveren, dus een ontbrekende eerdere byte kan ook de aflevering van al ontvangen latere bytes vertragen. Dit wachten wordt binnen de stream vaak blokkering door het eerste element genoemd.

Een bestandsoverdracht heeft een andere prioriteit: elke byte moet correct aankomen en wachten op herstel is acceptabel. TCP biedt die dienst al. Bij gebruik van UDP verschuift het werk van verlies detecteren, vervangende gegevens aanvragen en de volgorde herstellen naar de applicatie of een ander protocol.

Wat de kleine header oplevert

De header van UDP is 8 bytes; die van TCP is minstens 20. Een UDP-server kan berichten van veel clients ontvangen zonder per client transportverbindingen op te zetten. Er zijn nog steeds socketbuffers en applicatiemiddelen, dus “verbindingsloos” betekent niet dat de host niets opslaat.

Veelvoorkomende toepassingen van UDP zijn gewone DNS-query's op poort 53, NTP-tijdsynchronisatie op 123, SNMP-beheer op 161 en DHCP-adrestoewijzing op 67 en 68. Gesprekken en games kiezen vaak UDP om berichten op tijd te leveren. Video op aanvraag gebruikt meestal HTTP via TCP of QUIC, dus “video gebruikt UDP” is een te algemene regel.

QUIC laat zien hoeveel een protocol boven UDP kan toevoegen: betrouwbare streams, congestiebeheersing en beveiliging met TLS 1.3. Het werd gestandaardiseerd in 2021 en gebruikt meestal UDP-poort 443; HTTP/3 werkt boven op QUIC. UDP zelf heeft die diensten er niet bij gekregen.

Houd berichten klein genoeg

UDP behoudt berichtgrenzen. Een ontvangbewerking leest één bericht, geen bytestroom die uit meerdere verzendingen is samengesteld. De applicatie moet een voldoende grote leesbuffer aanbieden; een kleinere buffer kan het bericht afkappen.

Voor IPv4 met een IP-header van 20 bytes is de theoretische maximale nettolading 65.535 − 20 − 8 = 65.507 bytes. Verzenden dicht bij die grens kan IP-fragmentatie vereisen. Op een pad dat IPv4-datagrammen van 1.500 bytes ondersteunt, passen 1.500 − 20 − 8 = 1.472 gegevensbytes zonder fragmentatie als er geen IP-opties zijn. Andere paden en headers kunnen die waarde verlagen.

Houd rekening met de ontbrekende regelingen

UDP heeft geen ingebouwde stroomregeling om een trage ontvanger te beschermen. Als de socketbuffer vol raakt, kunnen aankomende berichten worden verworpen. Het mist ook ingebouwde congestiebeheersing. Verantwoord werkende UDP-applicaties zorgen voor passende snelheidsregeling, zodat ze een gedeeld pad niet overbelasten. Sommige netwerken filteren UDP, dus applicaties hebben mogelijk een terugvaloptie nodig.

Het overslaan van verbindingsopbouw en herstel kan vertraging verminderen, maar UDP vergroot de capaciteit van een verbinding niet en voorkomt geen IP-verlies. Beoordeel het hele applicatieprotocol: het werk dat het boven op UDP toevoegt, kan belangrijker zijn dan de grootte van de header.

Een protocol voor betrouwbare gegevensoverdracht geeft de ontvangende applicatie correcte gegevens, in volgorde en zonder duplicaten, ook wanneer het onderliggende kanaal pakketten beschadigt. Bouw het ontwerp op door je af te vragen wat er in elke fase mis kan gaan. Bij deze protocollen gaan applicatiegegevens één kant op en gaat de terugkoppeling voor de besturing terug.

Beschrijf gedrag met toestanden

Een eindige toestandsautomaat legt de huidige toestand van de zender of ontvanger vast. Elke overgang heeft een gebeurtenis die de overgang veroorzaakt en acties die moeten worden uitgevoerd. Een toestand zoals “wachten op ACK 0” geeft aan welke bevestiging de zender nodig heeft om verder te gaan. In de notatie van toestandsautomaten geeft Λ aan dat er geen gebeurtenis of actie is; een inkomende onderbroken pijl markeert de begintoestand.

Bij een volledig betrouwbaar kanaal heeft versie 1.0 alleen verzending en aflevering nodig. De zender verpakt gegevens, de ontvanger haalt ze uit de pakketten en geen van beiden heeft terugkoppeling nodig. Als je bitfouten toevoegt, verandert het ontwerp.

Detecteer een fout en vraag om een nieuwe kopie

Versie 2.0 gebruikt drie mechanismen:

• Met een controlesom kan de ontvanger een pakket op beschadiging controleren.
• Een ACK meldt succesvolle ontvangst; een NAK meldt beschadigde gegevens.
• Hertransmissie verstuurt zo nodig een nieuwe kopie.

Samen vormen deze een automatisch herhaalverzoek (ARQ). De zender verstuurt één pakket en wacht op terugkoppeling voordat hij het volgende verstuurt: stop-and-wait. Hij bewaart een kopie van het huidige pakket, omdat hij het mogelijk opnieuw moet verzenden.

Maar terugkoppelingspakketten gaan over hetzelfde onbetrouwbare kanaal. Een beschadigde ACK laat de zender in onzekerheid: heeft de ontvanger de gegevens geaccepteerd of is een nieuwe kopie nodig? Opnieuw verzenden is alleen veilig als de ontvanger een vervangende kopie kan onderscheiden van nieuwe applicatiegegevens. Een controlesom alleen herkent geen duplicaten; twee geldige kopieën hebben dezelfde geldige inhoud.

Geef elk onbevestigd pakket een identiteit

Versie 2.1 voegt een volgnummer toe. Met maar één onbevestigd pakket is in dit stop-and-waitkanaalmodel een nummer van één bit dat afwisselt als 0, 1, 0, 1 voldoende. De ontvanger onthoudt welk nummer hij verwacht. Hij levert een geldig pakket met dat nummer eenmaal af en verandert daarna zijn verwachting. Een pakket met het vorige nummer is een duplicaat: bevestig het opnieuw, maar lever de gegevens niet opnieuw af.

De zender behoudt het huidige nummer tijdens hertransmissie. Hij gaat pas naar het andere nummer na de bijpassende, leesbare ACK. Beschadigde terugkoppeling of een NAK leidt in dit ontwerp met alleen fouten tot hertransmissie.

Vervang NAK's door herhaalde ACK's

Versie 2.2 verwijdert NAK's. De ontvanger reageert op een beschadigd of dubbel pakket met een ACK voor het laatste pakket dat hij heeft geaccepteerd. De ACK heeft daarom een nummer nodig.

Stel dat pakket 0 “A” bevat en correct aankomt. De ontvanger levert “A” af en stuurt ACK 0. Pakket 1 met “B” raakt beschadigd, dus herhaalt de ontvanger ACK 0. De zender wacht op ACK 1; deze dubbele ACK geeft aan dat hij pakket 1 opnieuw moet verzenden. De geldige vervanging wordt als “B” afgeleverd en met ACK 1 bevestigd.

Dubbele gegevens verwerpen en het dubbele pakket bevestigen zijn verschillende handelingen. Als de ontvanger een vervanging zonder melding zou negeren waarvan de eerdere ACK onleesbaar was, zou de zender nooit kunnen weten dat de aflevering was geslaagd. TCP gebruikt ook geen NAK's, hoewel de bytenummering en de regels voor snelle hertransmissie verschillen van dit eenvoudige protocol.

Terugkoppeling helpt niet als die nooit aankomt. Wanneer het kanaal een gegevenspakket of een ACK kan verliezen, heeft de zender een manier nodig om zonder bericht verder te gaan. Versie 3.0 voegt een afteltimer toe aan het alternerend-bitprotocol.

Ga om met stilte zonder dubbel af te leveren

De zender start de timer telkens wanneer hij het huidige pakket verstuurt, ook bij een vervanging. Een bijpassende, onbeschadigde ACK stopt de timer en maakt het volgende pakket mogelijk. Een beschadigde ACK of een ACK met het verkeerde nummer wordt genegeerd. Als de timer eerst afloopt, verzendt de zender hetzelfde pakket opnieuw en start hij de timer opnieuw.

Bij een verloren gegevenspakket heeft de ontvanger niets te bevestigen; de time-out zorgt voor de vervanging. Bij een verloren ACK heeft de ontvanger de gegevens al afgeleverd. Wanneer de vervanging aankomt, herkent de ontvanger aan het volgnummer een duplicaat. Hij verwerpt de gegevens en stuurt de ACK opnieuw.

Een voortijdige time-out treedt op wanneer het oorspronkelijke pakket of de ACK alleen vertraagd was. De vervanging verspilt transmissiecapaciteit, maar detectie van duplicaten houdt de aflevering correct. Een bruikbare time-out moet ruimte bieden voor de verwachte rondlooptijd en verwerking door de ontvanger. Een te korte time-out veroorzaakt onnodige hertransmissies; een te lange vertraagt het herstel van werkelijk verlies.

Onderscheid transmissietijd en wachttijd

Laat de pakketlengte $L$ bits zijn en de transmissiesnelheid $R$ bit/s. De zender heeft $L\mathrm{/}R$ seconden nodig om één pakket op de verbinding te zetten. Als we de transmissie- en verwerkingstijd van de ACK negeren, duurt één stop-and-waitcyclus $RTT+L\mathrm{/}R$. Het deel van de tijd dat aan verzenden wordt besteed is

Voor pakketten van 1.500 bytes op een verbinding van 1 Gbit/s reken je eerst bytes om naar bits:

Daarna is $L\mathrm{/}R=12\mu \text{s}=\mathrm{0,012}\text{ ms}$. Bij een RTT van 40 ms geldt:

De zender is ongeveer 0,03% van de tijd actief. De doorvoersnelheid is ongeveer 12.000 bits per 0,040012 s, of 300 kbit/s. Een zeer snelle verbinding vervoert nog steeds weinig nuttig verkeer, omdat de zender bijna de hele cyclus wacht.

Verzend pakketten via pipelining

Met pipelining kunnen meerdere onbevestigde pakketten onderweg zijn. Als er maximaal $N$ pakketten in het zendvenster passen, wordt de ideale benutting:

Bij dezelfde verbinding geven 1.000 pakketten een benutting van ongeveer 0,30. Om de verbinding volledig bezet te houden zijn minstens $\mathrm{40,012}\mathrm{/}\mathrm{0,012}\approx \mathrm{3.334,33}$ pakkettransmissietijden nodig, dus rond je naar boven af op 3.335 pakketten. Als je naar beneden afrondt, blijft er een korte periode zonder verzending over vóór de eerste ACK.

Een grotere pijplijn vereist genoeg volgnummers om de pakketten te onderscheiden en genoeg bufferruimte om onbevestigde gegevens te bewaren. Afhankelijk van het protocol kan ook de ontvanger buffering nodig hebben. Go-back-N en selectieve herhaling maken hierin verschillende ontwerpkeuzes.

Als je alleen de transmissiesnelheid verhoogt, wordt de toch al korte transmissietijd nog korter. Bij een vaste pakketgrootte en RTT verlaagt dat de benutting van stop-and-wait. Meer gegevens onderweg stellen de zender in staat de beschikbare capaciteit te gebruiken.

Go-back-N (GBN) staat maximaal $N$ verzonden maar onbevestigde pakketten toe. Het schuifvenster van de zender schuift vooruit wanneer ontvangstbevestigingen de aflevering bevestigen. De ontvanger blijft eenvoudig: hij accepteert alleen het volgende pakket in volgorde.

Houd de bereiken van de zender uit elkaar

De variabele base geeft het oudste onbevestigde pakket aan. nextseqnum geeft het volgende nieuwe pakket aan dat kan worden verzonden. Vóór de cyclische terugloop van volgnummers zijn de bereiken:

• Onder base: al bevestigd.
• Van base tot en met nextseqnum − 1: verzonden, wacht op bevestiging.
• Van nextseqnum tot en met base + N − 1: beschikbaar voor nieuwe gegevens.
• Vanaf base + N: geblokkeerd totdat het venster opschuift.

Bij base = 10, nextseqnum = 13 en $N=5$ zijn pakketten 10–12 onbevestigd. Pakketten 13 en 14 kunnen worden verzonden. Pakket 15 niet. Een venster begrenst de hoeveelheid onbevestigde gegevens, niet het totale aantal pakketten in een overdracht.

Cumulatieve ontvangstbevestigingen verschuiven de ondergrens

GBN-ACK $n$ bevestigt alle pakketten tot en met $n$. Die verschuift base naar $n+1$. Eén latere cumulatieve ACK kan dus eerdere ACK's dekken die verloren zijn gegaan. Deze nummeringsconventie geeft het laatst geaccepteerde pakket aan; de ACK-conventie van TCP geeft de volgende verwachte byte aan.

GBN houdt één timer bij voor het oudste onbevestigde pakket. De verzending van het eerste onbevestigde pakket start de timer. Een ACK die de ondergrens verschuift, start de timer opnieuw als er nog onbevestigde gegevens zijn; bevestiging van alles stopt de timer. Wanneer de timer afloopt, verzendt de zender elk pakket opnieuw dat is verzonden maar onbevestigd blijft. Dat aantal kan kleiner zijn dan het maximale venster $N$.

Volg een ontbrekend pakket

Gebruik een venster van vier en verstuur pakketten 0, 1, 2 en 3. Pakket 2 gaat verloren. De ontvanger levert 0 en 1 af en stuurt ACK 0 en ACK 1. Pakket 3 komt na het ontbrekende pakket aan: de ontvanger verwerpt het en herhaalt ACK 1.

De eerste twee ACK's maken ruimte voor pakketten 4 en 5. Ook die komen na het ontbrekende pakket 2 aan, dus worden beide verworpen en met ACK 1 beantwoord. De ondergrens van de zender blijft 2. Bij een time-out verzendt hij 2, 3, 4 en 5 opnieuw. Die komen nu in volgorde aan en kunnen allemaal worden afgeleverd.

De kopieën van 3, 4 en 5 waren de eerste keer onbeschadigd. GBN verzendt ze opnieuw omdat de ontvanger geen pakketten buiten volgorde buffert. Dat bespaart toestand bij de ontvanger, ten koste van extra verkeer na verlies.

Laat één volgnummer buiten het venster

Een $k$-bits veld biedt $2^k$ pakketnummers, die cyclisch opnieuw worden gebruikt. GBN vereist:

Met drie bits zijn de nummers 0–7 en is het grootste zendvenster zeven. Als alle acht waren toegestaan, zou de ontvanger 0–7 kunnen accepteren en daarna weer 0 verwachten. Als alle ACK's verloren zouden gaan, zou een opnieuw verzonden oude 0 er dan als nieuw uitzien. Als alleen 0–6 zijn verzonden, verwacht de ontvanger daarentegen 7 en kan hij de opnieuw verzonden 0 als oud herkennen. Vensterberekeningen rond de cyclische terugloop volgen de cyclische volgorde, niet de gewone numerieke grootte.

Selectieve herhaling (SR) bewaart correct ontvangen pakketten, ook wanneer eerdere pakketten ontbreken. Elk geldig pakket krijgt een eigen ACK. De zender kan dan alleen een pakket vervangen waarvan de timer afloopt.

Houd elk pakket afzonderlijk bij

Het venster van de zender begint bij send_base, het oudste onbevestigde pakket, en bevat $N$ toegestane volgnummers. Elk onbevestigd pakket heeft een logische timer. Een ACK markeert dat specifieke pakket als ontvangen. Een ACK voorbij de ondergrens verschuift het venster op zichzelf niet: de ondergrens blijft bij het eerste ontbrekende pakket. Zodra dat pakket is bevestigd, schuift de ondergrens voorbij eventuele volgende pakketten die al zijn bevestigd.

Het venster van de ontvanger begint bij rcv_base, het volgende pakket dat nodig is voor aflevering. Een geldig pakket binnen het venster wordt bevestigd. Gegevens buiten volgorde worden gebufferd. Wanneer het pakket aan de ondergrens aankomt, levert de ontvanger het af, samen met elk opeenvolgend gebufferd pakket erna, tot aan het volgende ontbrekende pakket.

Een pakket in het direct voorafgaande venster is een oud duplicaat. De ontvanger bevestigt het opnieuw zonder het af te leveren. Deze regel is essentieel wanneer de oorspronkelijke ACK verloren is gegaan: de zender kan nog steeds wachten terwijl de ontvanger al verder is gegaan.

Herstel één verloren pakket

Gebruik $N=4$ en laat pakket 2 verloren gaan nadat de zender 0–3 heeft verstuurd. De ontvanger levert 0 en 1 af en bevestigt ze, en buffert en bevestigt daarna 3. Met die eerste twee ACK's kan de zender 4 en 5 versturen. Beide worden gebufferd en afzonderlijk bevestigd, maar send_base blijft op 2.

Wanneer de timer van pakket 2 afloopt, wordt alleen 2 opnieuw verzonden. Door de aankomst daarvan kan de ontvanger 2, 3, 4 en 5 samen afleveren en rcv_base naar 6 verschuiven. Zodra ACK 2 de zender bereikt, schuift ook zijn ondergrens naar 6, voorbij pakketten 3–5 waarvan hij de ACK's al heeft.

Waarom het venster maximaal de helft van de volgnummerruimte is

De ontvanger kan voorlopen op de zender omdat ACK's vertraagd of verloren zijn. Nieuwe acceptabele nummers mogen niet overlappen met nummers die nog als oude pakketten opnieuw kunnen worden verzonden.

Stel bij nummers van twee bits, 0–3, en een venster van drie dat de ontvanger 0, 1 en 2 accepteert. Zijn nieuwe venster is {3, 0, 1}. Als alle ACK's verdwijnen, past een opnieuw verzonden oude 0 in dit venster en lijkt die nieuw. De ontvanger kan die niet onderscheiden van een werkelijk nieuwe 0 die na een verloren 3 is verzonden.

Voor even grote zend- en ontvangstvensters is de veilige grens:

Nummering met drie bits staat dus SR-vensters tot vier toe, terwijl GBN zeven toestaat.

Onderscheid een oude kopie na cyclische terugloop

Venstergrenzen regelen de huidige vensters, maar een echt netwerk kan ook een oude kopie onderweg houden totdat nummers opnieuw worden gebruikt. Een maximale pakketlevensduur begrenst hoe lang zulke kopieën kunnen blijven bestaan. TCP noemt dit de maximale segmentlevensduur (MSL). Bij hoge snelheden kan TCP zijn 32-bits volgnummerruimte snel opnieuw gebruiken, dus helpt bescherming tegen cyclisch teruggelopen volgnummers (PAWS) op basis van tijdstempels om verouderde gegevens te verwerpen.

Een TCP-verbinding is toestand die wordt bijgehouden in twee eindhosts: buffers, bytetellers en andere variabelen die tijdens de verbindingsopbouw worden aangemaakt. De verbinding is punt-tot-punt, tussen twee eindpunten, en fullduplex, zodat beide tegelijk kunnen verzenden. Gewone routers sturen de IP-datagrammen door zonder de TCP-eindpunttoestand bij te houden.

Bytes hebben geen berichtgrenzen

TCP bewaart de volgorde van bytes, maar niet de grenzen van schrijfbewerkingen van de applicatie. Drie schrijfbewerkingen van 100 bytes kunnen de applicatie bereiken in één leesbewerking van 300 bytes, of in leesbewerkingen van 50 en 250 bytes. Een applicatie die berichten uitwisselt, moet zelf berichtafbakening verzorgen, bijvoorbeeld met een lengteveld of een scheidingsteken. Een korte leesbewerking bewijst niet dat een volledig bericht is aangekomen.

Schrijfbewerkingen van de applicatie komen in een zendbuffer. TCP kiest stukken om te verzenden en bewaart onbevestigde gegevens voor mogelijke hertransmissie. Binnenkomende gegevens komen in een ontvangstbuffer totdat de ontvangende applicatie ze leest.

Bepaal de grootte van gegevens los van de headers

De maximale segmentgrootte (MSS) begrenst de applicatiegegevens in een segment. Zowel TCP- als IP-headers zijn daarbij uitgesloten. Voor een pad dat IP-datagrammen van 1.500 bytes met een IPv4-header van 20 bytes en een TCP-header van 20 bytes ondersteunt, geldt:

Opties nemen meer ruimte in, dus een zender moet rekening houden met hun werkelijke headerlengtes. Elk eindpunt maakt tijdens de handshake de MSS bekend die het kan ontvangen; beperkingen van het pad kunnen verder beperken wat kan worden verzonden. Zonder MSS-optie wordt standaard uitgegaan van 536 gegevensbytes voor IPv4 en 1.220 voor IPv6.

Lees de headervelden

De minimale header bestaat uit vijf 32-bits woorden, of 20 bytes. Een gegevensoffset van 8 betekent 32 bytes, inclusief 12 bytes buiten de vaste header. De maximale offset is 15: in totaal 60 bytes, met ruimte voor maximaal 40 bytes aan opties.

Interpreteer vlaggen en opties

SYN synchroniseert volgnummers tijdens het openen. FIN sluit één verzendrichting. RST breekt een verbinding af of weigert die. ACK maakt het bevestigingsveld geldig. PSH vraagt om snelle aflevering aan de applicatie; het maakt geen berichtgrens. URG maakt de aanwijzer voor urgente gegevens geldig, hoewel nieuwe applicaties het advies krijgen dat mechanisme te vermijden. ECE en CWR bevatten signalen voor expliciete congestiemelding.

Veelvoorkomende opties zijn MSS, vensterschaling, tijdstempels en selectieve ontvangstbevestiging (SACK). Schaling vergroot het bereik van het ontvangstvenster. Tijdstempels helpen de RTT te meten en verouderde segmenten te verwerpen. SACK beschrijft ontvangen blokken na een ontbrekend deel.

Zonder opties voegen TCP en IPv4 samen 40 bytes toe. Een volledig gegevenssegment van 1.460 bytes neemt een IP-datagram van 1.500 bytes in beslag, waarvan ongeveer 97,3% applicatiegegevens is. Een zuivere ACK heeft geen gegevens, maar neemt nog steeds die 40 headerbytes in beslag.

TCP-volgnummers tellen bytes, geen segmenten. Het volgnummer van een segment geeft de eerste gegevensbyte aan. Het bevestigingsnummer beschrijft de tegenovergestelde richting: de volgende byte die deze zender verwacht te ontvangen.

Splits een stroom in segmenten

De SYN gebruikt een initieel volgnummer (ISN) van 3.000. De eerste gegevensbyte is daarom 3.001. Een bestand van 10.000 bytes met een MSS van 1.460 vereist zes volledige gegevenssegmenten en één korter segment:

Elk volgend volgnummer krijg je door de gegevenslengte van het vorige segment op te tellen. De laatste byte is 13.000, dus succesvolle ontvangst van het hele bestand levert cumulatieve ACK 13.001 op.

Bevestig een aaneengesloten prefix

ACK $n$ bevestigt alle bytes tot en met $n-1$. Die bevestigt byte $n$ niet. Als de ontvanger bytes tot en met 4.460 heeft, verwacht hij 4.461. Een segment dat bij 5.921 begint, laat een ontbrekend deel achter. Een ontvanger die dat segment buffert, stuurt nog steeds ACK 4.461 omdat zijn aaneengesloten prefix niet is gegroeid.

Daarom kan de ontvangstbevestiging niet simpelweg het grootste waargenomen volgnummer zijn. Latere bytes laten zien dat er iets na het ontbrekende deel is aangekomen; ze vullen het niet op. Wanneer het ontbrekende bereik aankomt, kan een cumulatieve ACK over al gebufferde gegevens heen springen.

Houd beide richtingen onafhankelijk bij

Stel dat de volgende byte van een client 1.000 is en de volgende byte van een server 5.000. De client verstuurt 200 gegevensbytes met volgnummer 1.000 en bevestigingsnummer 5.000. Het antwoord van de server bevat 1.200 bytes met volgnummer 5.000 en bevestigingsnummer 1.200. De volgende zuivere ACK van de client heeft volgnummer 1.200 en bevestigingsnummer 6.200.

De server heeft zijn eigen volgnummer niet afgeleid van de lengte van het verzoek. Elke richting heeft een eigen nummering. Een ACK met uitgaande gegevens meesturen heet meeliften van ontvangstbevestigingen. Een zuivere ACK verbruikt geen volgnummerruimte; SYN en FIN verbruiken elk één nummer, ook zonder gegevens.

Beheer beginwaarden en cyclische terugloop

Eindpunten kiezen een ISN wanneer ze een verbinding openen. Een klok en een pseudowillekeurige functie met een sleutel van de verbindingsadressen en poorten helpen een nieuwe verbinding te onderscheiden van oude vertraagde segmenten en maken geldige nummers moeilijk te raden voor een buitenstaander. Elke verbinding bij nul laten beginnen zou beide beschermingen verzwakken.

De velden zijn 32 bits, dus de nummering loopt cyclisch terug modulo $2^{32}$, ongeveer 4,3 miljard bytes. Bij 1 Gbit/s duurt het ongeveer 34 s om die ruimte te doorlopen; bij 10 Gbit/s ongeveer 3,4 s. PAWS op basis van tijdstempels biedt op snelle paden een extra controle op verouderde segmenten.

Voor gewone berekeningen buiten de cyclische terugloop is de volgende byte na een gegevenssegment het volgnummer plus de gegevenslengte. Als een SYN of FIN aanwezig is, tel je het ene extra nummer mee dat die besturingsvlag verbruikt. Pas de berekening afzonderlijk toe op elke richting.

Bij de verbindingsopbouw van TCP kunnen beide eindpunten een beginvolgnummer bekendmaken en vaststellen dat de andere kant het heeft ontvangen. Bij het latere afsluiten wordt elke richting afzonderlijk vrijgegeven. Deze besturingsuitwisselingen gebruiken dezelfde volgnummerruimte als gegevens.

Volg de drieweg-handshake

1. De client maakt verbindingstoestand aan, verstuurt SYN met ISN 7.000 en gaat naar SYN_SENT.
2. De server antwoordt met SYN-ACK, volgnummer 21.000 en bevestigingsnummer 7.001. Hij bevindt zich in SYN_RCVD terwijl hij op bevestiging wacht.
3. De client registreert het nummer van de server en stuurt ACK met volgnummer 7.001 en bevestigingsnummer 21.001. De client gaat naar ESTABLISHED; de server doet dat wanneer die ACK aankomt.

Elke SYN verbruikt één nummer. Het derde segment kan al applicatiegegevens bevatten. De gewone handshake kost één rondlooptijd voordat de client die eerste gegevens kan versturen. Een uitwisseling van twee berichten zou de server niet laten weten dat de client zijn ISN heeft ontvangen en zou ertoe kunnen leiden dat hij een vertraagde oude SYN als een nieuw verzoek accepteert.

Bij de socketinterface start connect een actieve opening. Een server luistert naar verzoeken en accept geeft na de verbindingsopbouw een nieuwe verbindingssocket terug. De luistersocket blijft beschikbaar voor andere clients.

Sluit elke richting

Een eindpunt stuurt FIN wanneer het geen bytes meer te verzenden heeft. De andere kant bevestigt die FIN door zijn ACK tot één voorbij de FIN te verhogen. De andere kant kan zijn eigen resterende bytes nog versturen: dit is een eenzijdige sluiting. Zijn latere FIN sluit de andere richting en heeft ook een ACK nodig. Sluiten gebruikt meestal vier segmenten, hoewel een FIN en ACK kunnen worden gecombineerd.

Voor een client die als eerste sluit, is het gebruikelijke toestandspad ESTABLISHED → FIN_WAIT_1 na het verzenden van FIN → FIN_WAIT_2 zodra die FIN is bevestigd → TIME_WAIT na ontvangst en bevestiging van de FIN van de andere kant → CLOSED. De andere kant gaat door CLOSE_WAIT terwijl de applicatie afrondt, daarna door LAST_ACK na het verzenden van een eigen FIN en ten slotte naar CLOSED bij ontvangst van de ACK.

Zorg dat de laatste ACK kan worden hersteld

Bij de gebruikelijke actieve sluiting duurt TIME_WAIT tweemaal de maximale segmentlevensduur. Als de laatste ACK verdwijnt, kan het andere eindpunt zijn FIN opnieuw verzenden en een nieuwe ACK ontvangen. Door te wachten krijgen oude segmenten ook tijd om te verlopen voordat het viertupel van de verbinding opnieuw wordt gebruikt. De MSL-waarde van twee minuten uit de standaard levert vier minuten op; implementaties kunnen andere tijden gebruiken, waarbij 60 seconden een bekende Linux-waarde is.

Een RST verschilt van FIN: die breekt de verbinding af of weigert een verzoek. Een SYN naar een gesloten poort krijgt normaal RST terug. SYN-ACK wijst op een luisterende socket; stilte kan het gevolg zijn van filtering, verlies of een onbereikbare bestemming.

Bescherm onvoltooide handshakes

Een SYN-flood verstuurt veel openingsverzoeken zonder ze te voltooien. Een server die voor elke halfopen verbinding middelen reserveert, kan zijn beschikbare ruimte voor toestand uitputten. SYN-cookies stellen de toewijzing van die toestand per verbinding uit. De server verwerkt verifieerbare verbindingsinformatie in zijn gekozen ISN met behulp van een geheim en tijdsafhankelijke invoer. Een geldige laatste ACK geeft de cookie terug via het bevestigingsnummer, zodat de server die kan controleren en toestand kan aanmaken. De server heeft nog steeds een luistersocket en gedeelde middelen; hij voorkomt dat voor elke SYN een afzonderlijke onvoltooide verbinding wordt opgeslagen.

TCP heeft een hertransmissietime-out nodig die lang genoeg is voor normale rondlooptijden, maar kort genoeg om snel van verlies te herstellen. De RTT varieert wanneer wachtrijen en paden veranderen, dus volgt de time-out zowel een afgevlakte schatting als de grootte van recente afwijkingen.

Neem een ondubbelzinnige meting

SampleRTT meet het interval vanaf het verzenden van gegevens tot de ontvangst van een ACK die die gegevens dekt. In een basisimplementatie meet TCP één geschikt segment tegelijk. Het algoritme van Karn sluit opnieuw verzonden gegevens uit van gewone RTT-metingen: een ACK kan naar de oorspronkelijke kopie of de vervanging verwijzen. Overeengekomen tijdstempels kunnen deze dubbelzinnigheid wegnemen.

De eerste geldige meting $R$ stelt EstimatedRTT in op $R$ en DevRTT op $R\mathrm{/}2$. Voordat er een meting is, is de aanbevolen initiële time-out 1 s.

Werk de variatie vóór het gemiddelde bij

Gebruik voor een nieuwe meting de vorige EstimatedRTT om de afwijking te meten:

Werk daarna het exponentieel gewogen voortschrijdend gemiddelde bij:

De aanbevolen gewichten zijn $\beta =1\mathrm{/}4$ en $\alpha =1\mathrm{/}8$. Oudere metingen behouden na elke bijwerking minder invloed. Als je het gemiddelde eerst bijwerkt, verandert de afwijking die in de eerste vergelijking wordt gebruikt.

Werk één bijwerking uit

Begin met EstimatedRTT = 100 ms en DevRTT = 10 ms; neem een meting van 120 ms.

1. Absolute afwijking: $\mathrm{\mid }120-100\mathrm{\mid }=20\text{ ms}$.
2. Nieuwe DevRTT: $\mathrm{0,75}(10)+\mathrm{0,25}(20)=\mathrm{12,5}\text{ ms}$.
3. Nieuwe EstimatedRTT: $\mathrm{0,875}(100)+\mathrm{0,125}(120)=\mathrm{102,5}\text{ ms}$.
4. Basistime-out: $\mathrm{102,5}+4(\mathrm{12,5})=\mathrm{152,5}\text{ ms}$.

De basisregel is:

De volledige standaard gebruikt EstimatedRTT + max(G, 4 DevRTT), waarbij $G$ de klokgranulariteit is. Wanneer de marge van vier afwijkingen groter is dan het klokinterval, geeft de basisregel hetzelfde resultaat.

De standaard beveelt aan een berekende waarde onder 1 s te verhogen tot 1 s. Werkelijke implementaties kunnen een lager minimum gebruiken; een gebruikelijk Linux-minimum is 200 ms. De berekende 152,5 ms is daarom een ruwe schatting, niet noodzakelijk de timer die een host instelt. Een optionele bovengrens moet minstens 60 s zijn.

Verleng de wachttijd na een time-out

Wanneer de timer afloopt, verzendt TCP de oudste onbevestigde gegevens opnieuw en verdubbelt het de time-out. Een huidige waarde van 0,75 s wordt 1,5 s en na nog een keer aflopen 3 s. Herhaalde onmiddellijke pogingen zouden verkeer toevoegen aan een pad dat al geen terugkoppeling aflevert.

Een nieuw aankomende ACK verlaagt die verlengde time-out niet noodzakelijk. TCP heeft een geldige nieuwe RTT-meting nodig om de schatting opnieuw te berekenen. Zonder tijdstempels verhindert de dubbelzinnigheid door hertransmissie dat een ACK voor de opnieuw verzonden gegevens als die nieuwe meting wordt gebruikt. Zodra geschikte nieuwe gegevens zijn verzonden en bevestigd, kan een nieuwe meting de berekende time-out verlagen.

TCP combineert een controlesom, bytevolgnummers, cumulatieve ACK's en hertransmissie om een betrouwbare stroom af te leveren. De zender moet een ACK die de aflevergrens vooruitbrengt onderscheiden van een ACK die de huidige grens herhaalt.

Volg de gebeurtenissen bij de zender

SendBase is de eerste onbevestigde byte; NextSeqNum is het volgende ongebruikte bytenummer. Nieuwe applicatiegegevens worden verzonden met volgnummer NextSeqNum, dat daarna met de gegevenslengte wordt verhoogd. Als er geen hertransmissietimer loopt, start verzending van onbevestigde gegevens de timer.

Het aanbevolen basistimeralgoritme gebruikt één hertransmissietimer voor het oudste onbevestigde segment. Bij een time-out wordt dat oudste onbevestigde segment opnieuw verzonden, het interval verdubbeld en de timer opnieuw gestart. Een ACK groter dan SendBase verschuift de ondergrens en start de timer opnieuw als er onbevestigde gegevens overblijven. Als alles is bevestigd, stopt de timer. Een dubbele ACK verschuift de ondergrens niet.

Verloren ACK's hoeven geen probleem te blijven

A verstuurt 500 bytes vanaf 501. B ontvangt ze en stuurt ACK 1.001, die verloren gaat. Als niets anders die bytes bevestigt, krijgt A een time-out en verzendt ze opnieuw. B herkent het duplicaat, levert geen extra gegevens af en stuurt opnieuw ACK 1.001.

Stel nu dat A ook de volgende 500 bytes had verstuurd, vanaf 1.001. Als ACK 1.501 vóór de time-out aankomt, bevestigt die beide segmenten. Het verlies van ACK 1.001 vereist geen hertransmissie. Een ACK is cumulatief, dus de zender heeft niet voor elk segment een afzonderlijke aangekomen ACK nodig.

Bij een voortijdige time-out verzendt A alleen het oudste segment opnieuw. Als vertraagde ACK's vervolgens beide oorspronkelijke segmenten bevestigen, hoeft A het tweede niet opnieuw te verzenden. Een time-out geeft aan dat terugkoppeling niet op tijd aankwam, niet dat elk onbevestigd segment is verdwenen.

Gebruik de timing van ACK's om ontbrekende delen te melden

Bij gegevens die in volgorde aankomen terwijl geen ACK wacht, mag de ontvanger een ACK kort uitstellen, minder dan 0,5 s, om ontvangstbevestigingen te combineren. Hij moet minstens elk tweede segment van volledige grootte bevestigen. Een tweede aankomst in volgorde terwijl een ACK wacht, leidt tot een cumulatieve ACK. Een aankomst buiten volgorde na een ontbrekend deel leidt onmiddellijk tot een dubbele ACK; het geheel of gedeeltelijk aanvullen van een ontbrekend deel leidt ook onmiddellijk tot een ACK.

Herstel een ontbrekend deel vóór de time-out

Stel dat A vijf segmenten van 1.000 bytes verstuurt die beginnen bij 1.001, 2.001, 3.001, 4.001 en 5.001. Het tweede gaat verloren. De ACK van B na het eerste is 2.001. De drie latere aankomsten leveren elk opnieuw ACK 2.001 op.

Na drie dubbele ACK's gebruikt A snelle hertransmissie om het segment dat bij 2.001 begint opnieuw te verzenden zonder op de time-out te wachten. Omdat de latere gegevens zijn gebufferd, kan B door het aanvullen van dat ontbrekende deel 6.001 bevestigen. De eerste ACK 2.001 is de oorspronkelijke ACK; de volgende drie zijn duplicaten. Eén of twee dubbele ACK's kunnen ontstaan door gewone herordening, wat verklaart waarom op meer aanwijzingen wordt gewacht.

TCP combineert ideeën uit beide vensterprotocollen. Zijn cumulatieve ACK's en eenvoudige enkele timer lijken op GBN, maar zijn buffering en gerichte hertransmissie lijken op SR. De overeengekomen SACK meldt byteblokken voorbij de cumulatieve grens, zodat de zender meerdere ontbrekende delen nauwkeuriger kan identificeren. TCP stuurt geen NAK voor een mislukte controlesom; het resulterende ontbrekende deel blijkt uit latere ACK's of een time-out.

Stroomregeling voorkomt dat een TCP-zender de buffer van de ontvanger laat overlopen. Ze reageert op hoe snel de ontvangende applicatie leest. Congestiebeheersing reageert op belasting in het netwerk; de twee regelingen beschermen verschillende middelen.

Bereken de beschikbare ruimte

Laat RcvBuffer de buffercapaciteit zijn, LastByteRcvd de laatste in volgorde opgeslagen byte en LastByteRead de laatste byte die de applicatie heeft gelezen. In dit model met aaneengesloten gegevens is de bezette ruimte LastByteRcvd − LastByteRead. Het ontvangstvenster is:

De ontvanger maakt de beschikbare ruimte bekend in het vensterveld van zijn teruggestuurde segmenten. De zender houdt zijn aantal onbevestigde bytes binnen die ruimte:

Bij RcvBuffer = 40.000 bytes, LastByteRcvd = 30.000 en LastByteRead = 18.000 is de bezetting 12.000 en rwnd 28.000 bytes. ACK 30.001 met dit venster staat onbevestigde bytes tot en met 58.000 toe. Als de zender al tot en met 34.000 heeft verzonden, heeft hij 4.000 onbevestigde bytes en mag hij er nog 24.000 verzenden. Het venster is de toegestane ruimte voor alle onbevestigde bytes, geen extra ruimte boven op die bytes.

Hervat na een nulvenster

Wanneer er geen ruimte meer is, maakt de ontvanger rwnd = 0 bekend en stopt de zender met de normale verzending van nieuwe gegevens. Wanneer de applicatie leest, maakt de ontvanger de nieuw beschikbare ruimte bekend in een vensterupdate.

Die update kan een zuivere ACK zijn, die op zichzelf niet betrouwbaar wordt afgeleverd. Als die verloren gaat, kan de zender blijven wachten hoewel er ruimte is. Testberichten bij een nulvenster, die meestal één byte bevatten, zetten de ontvanger ertoe aan zijn huidige venster terug te sturen. De tussenpozen tussen testberichten worden groter; het is geen normale verzending van grote hoeveelheden gegevens door een gesloten venster.

Breng het venster in verband met de doorvoersnelheid

Bij een vast venster en een vaste RTT voldoet de ideale doorvoersnelheid die door het venster wordt begrensd aan:

Gebruik bytes en seconden om bytes/s te krijgen. Een venster van 65.535 bytes bij een RTT van 0,1 s staat ongeveer 655.350 bytes/s toe, of 5,2 Mbit/s. Een hogere transmissiesnelheid kan deze venstergrens niet wegnemen.

Om een pad volledig te benutten moet het venster het bandbreedte-vertragingsproduct dekken. Bij 1 Gbit/s en 0,1 s zijn de vereiste gegevens onderweg 100 miljoen bits, of 12,5 MB. Dit is een noodzakelijke venstergrootte voor die ideale snelheid, geen garantie dat die wordt bereikt.

Schaal het veld en vermijd zeer kleine updates

Het 16-bits veld alleen kan zo'n groot venster niet weergeven. Een optie voor vensterschaling die in SYN's wordt overeengekomen, vermenigvuldigt latere vensterwaarden met $2^s$, waarbij $s\le 14$. De grootste schaal geeft iets minder dan 1 GiB. Een verschuiving van 7 staat maximaal 8.388.480 bytes toe; verschuiving 8 staat 16.776.960 toe, genoeg voor het voorbeeld van 12,5 MB. De schaal blijft vast voor die richting, terwijl de bekendgemaakte ruimte verandert. De venstervelden van SYN's zelf worden niet geschaald.

Als telkens na het vrijkomen van enkele bytes de ruimte wordt bekendgemaakt, kan het syndroom van kleine vensters ontstaan: veel zeer kleine segmenten met grote headeroverhead. Om dit te voorkomen wacht de ontvanger op een bruikbare hoeveelheid vrije ruimte, meestal één MSS of de helft van de buffer, afhankelijk van welke kleiner is. Het algoritme van Nagle pakt kleine schrijfbewerkingen bij de zender aan door ze vast te houden zolang eerdere gegevens onbevestigd blijven, of totdat er genoeg gegevens zijn voor een volledig segment.