2.1 Inleiding
Begin van FileHet hart van het internet is gebaseerd op twee protocollen, IP en TCP. Deze twee protocollen leveren verschillende functies. Het IP protocol (Internet Protocol), zorgt ervoor dat het TCP-protocol netwerk- onafhankelijk kan draaien. Dit betekent dat dus TCP zo ontwikkeld kan worden dat deze geen rekening hoeft te houden met wat voor netwerk-architectuur wordt gebruikt om communicatie met verschillende processen tot stand te brengen. TCP (Transmission Control Protocol) levert dus schijnbaar, aan de applicaties die draaien boven de TCP laag, een betrouwbare gegevensoverdracht over het op datagram gebaseerde IP protocol. In de bijlage staat een uitsplitsing van de TCP/IP protocollen onderverdeeld in de diverse lagen.In figuur 2.1 zijn de verschillende lagen aangegeven, met daarbij een aantal voorbeeld applicaties, en netwerk protocollen.
We kunnen een aantal observaties maken over het TCP protocol:
1. TCP werkt boven IP, en IP levert een 'best-try datagram transmissie service'. Dit is een hele interessante observatie omdat TCP de applicaties waar het voor werkt laat denken dat ze te maken hebben met een rechtstreekse (virtual circuit) verbinding met het remote proces. Het vernufte is dus dat betrouwbare services wordt aangeboden over een connectionless datagram gebaseerde netwerk verbinding.
2. TCP levert zogenaamde End-to-End fout detektie door gebruik te maken van een her-transmissie-algoritme van onbetrouwbare segmenten. Doordat er dus gebruik wordt gemaakt van hertransmissie moeten de segmenten genummerd zijn. Dit is noodzakelijk voor zowel ordening van binnengekomen segmenten, als voor detectie van duplikaten segmenten die veroorzaakt zouden kunnen worden door hertransmissie.
3. Omdat de zender natuurlijk niet als maar segmenten kan blijven sturen, omdat de buffer van de ontvanger dan zou overlopen, moet er dus ook iets gedaan worden aan flow-control van de segmenten om 'buffer-overflow' te voorkomen.
4. In een pakket georiënteerd netwerk is het mogelijk voor een pakket om in het netwerk rond te circuleren voor onbepaalde tijd, en komt deze dan op een willekeurig moment binnen bij de ontvanger dan raakt deze de kluts kwijt. Vandaar dat dus ook zoiets als een TTL (Time To Live) Parameter aan de pakketten worden meegegeven. Als niet binnen de TTL tijd het pakket is aangekomen bij de ontvanger dan wordt dit pakketje vernietigd, zodat ook geen congestie in het netwerk kan optreden.
5. Omdat TCP werkt met een full-duplex verbinding moet dus de opbouw en afbreking van een connectie volgens een goed gedefinieerde en gestandaardiseerde methode gebeuren. Anders blijven er zogenaamde ghost verbindingen bestaan die de poort blijven vasthouden, en deze poort dan nooit wordt vrijgegeven. Op den duur loopt dan het systeem uit de beschikbare poorten.
6. Elk proces die een tcp-connectie maakt met een proces draaiend op de remote systeem, moet zonder problemen meerdere conversaties met andere of dezelfde processen aankunnen zonder dat hier verwarring over bestaat. Vandaar dat een tcp-connectie altijd uniek met een lokaal host, lokaal poort, remote host, remote port geindentificieerd kan worden.
7. Omdat de pakketten over verschillende netwerken worden gestuurd, en dat elke netwerk zijn eigen maximale pakketlengte heeft kan het voorkomen dat dus de pakketten worden opgesplitst in kleinere stukken. TCP moet er dus ook zorg voor dragen dat als een segment is opgesplitst in stukken dat deze het weer aan elkaar plakt, voordat de segment wordt verstuurd naar de applicatie.
Begin van File
2.2 Data encapsulatie
Zoals in figuur 2.1 te zien is loopt de data van de applicatie door verschillende lagen van het netwerk communicatie model heen. Elke laag voegt aan de data wat informatie toe die voor die laag van belang is. Deze redundantie toevoegen maakt uiteraard de lengte van de pakketten groter. Afhankelijk van de lengte van de data, optie velden, e.d. kan een pakket een maximale lengte hebben. In figuur 2.2 staat de route die de data doorloopt en geeft aan welke laag de data encapsuleert met een header.
Begin van File
2.3 De gebruikte datastructuren
Applicaties die gebruik van TCP maken noemen de data die wordt verstuurd een 'stream', terwijl applicaties die gebruik maken van UDP refereren naar data als 'message'. TCP noemt data een 'segment', en UDP noemt het een 'pakket'. De Internetlaag noemt zijn data een 'datagram'. De Netwerk Acces Laag noemt de data die hij het netwerk opstuurt of opvangt een 'frame' of 'pakket'. In figuur 2.3 staan de diverse datastructuren vermeld.
Alle datastructuren die in figuur 2.3 zijn genoemd, hebben allemaal dezelfde betekenis namelijk data die verstuurd moet worden. De bijlage geeft schematisch de afhankelijkheid aan van de subprotocollen, en de volgende bijlage geeft weer hoe de communicatie verloopt tussen de protocollen onderling.
Begin van File
2.4 TCP Service Model
TCP levert aan de applicaties een betrouwbare verbinding door gebruik te maken van een virtuele connectie (vergelijk met het X.25 netwerk). Dit betekent dat er tussen twee processen die op twee verschillende machines draaien deze verbinding gebruikt kan worden om data van de ene proces naar de andere te versturen. Een proces draait meestal op een Internet host die bekend is door een Internet Protocol adres. Een host wordt geindentificeerd door zijn IP adres, en een poort op deze host wordt gekenmerkt door een 16 bits getal. Een combinatie van IP adres en poort nummer wordt een socket genoemd. Als een proces probeert te communiceren met een andere proces op een remote host, stuurt hij zijn eigen socket door. De remote host heeft ook een IP adres en een poort waarop een draait. Nu kan een TCP connectie worden aangeduid door de sockets van beidde hosts. Het is belangrijk te weten dat een socket in meer dan een verbinding kan worden gebruikt. Dit wordt geïllustreerd in figuur 2.4.
Beschrijving van figuur 2.4:
1. We zien dat er een tweetal connecties zijn opgebouwd, namelijk:
Connectie: [193.78.240.1] (23) en [193.78.240.2] (1234)
Connectie: [193.78.240.1] (23) en [193.78.240.13] (xxxx)
2. We zien dat er een server telnet socket aanwezig is waarop cliënten kunnen verbinden:
Well-known server Telnet socket: [193.78.240.1] (23)
3. We zien dat er een cliënt telnet socket is:
Cliënt Telnet socket: [193.78.240.2] (1234)
Er zijn een aantal poorten gedefinieerd als Well-known sockets, waarop standaard processen draaien. Zo is bijvoorbeeld in figuur 2.4, poort 23 de standaard telnet socket van een host. In RFC 1700 kunnen nog andere well-known sockets gevonden worden. Door de afspraak om bepaalde processen een well-known poort nummer te geven, is het voor software fabrikanten welke TCP/IP-client programmatuur schrijven makkelijk om deze standaardpoorten in hun produkt te verwerken. Processen welke gebruik maken van een TCP verbinding, willen graag een verbinding kunnen OPEN-en, actief of passief (ook wel door LISTEN aangeduid), informatie kunnen SEND(en) en RECEIVE(n), de STATUS van een verbinding kunnen opvragen, een verbinding kunnen CLOSE(n), of als noodzakelijk blijkt een verbinding kunnen ABORT(en).
Begin van File
2.5 Basis parameters voor TCP connecties
Zoals eerder in dit verslag is vermeld, levert TCP een betrouwbare, gesequenseerde aflevering van een stream van bytes, door gebruik te maken van de onderliggende, onbetrouwbare datagram service (IP). Om dit te kunnen bereiken maakt TCP gebruik van hertransmissie op time-outs en positieve bevestiging (ack) bij ontvangst van de informatie. Omdat door hertransmissie ook duplikaten frames/pakketen kunnen voorkomen, onderhoudt TCP ook een pakket-nummeringsalgoritme. Ook een verschijnsel wat wordt geïntroduceerd door hertransmissie te gebruiken, is out-of-order aankomst van de pakketten. Dat betekent dat dus voordat TCP de data doorgeeft aan de applicatie deze op volgorde gezet moeten worden. Flow control in TCP maakt gebruik van de windowing algoritme, waarbij de ontvangende zijde van de verbinding de zender aangeeft welke pakketnummers de zender direkt mag versturen en het geeft ook aan de ontvanger door welke pakketten hij reeds ontvangen heeft (deze methode wordt ook wel accumulatieve bevestiging genoemd). De accumulatieve bevestiging maakt het mogelijk om beidde kanten informatie-uitwisseling over de connectie tot een minimum te beperken.
De Urgentie pointer is een 16-bit waarde welke de offset (verschuiving) aangeeft vanaf de sequentie nummer van het pakket waarin de Urgentie pointer zit. De som van het sequence nummer en de urgentie pointer is het sequentienummer van de laatste byte van urgente data. Urgente data is data waarvan het URG-bit is gezet, dus een ‘1’ bevat. Door gebruik te maken van het URG-bit en de Urgentie Pointer kan TCP zo belangrijke segmenten voorrang geven boven de segmenten waarvan de URG-bit niet is gezet. Zo kan dus belangrijke segmenten voorrang krijgen. Zoals in figuur 2.5 kan worden gezien, kan een tcp-segment ook opties bevatten. De opties zitten in het laatste gedeelte van een segment en zijn altijd een veelvoud van 32 bits, als dit niet het geval is dan wordt het padding-veld gebruikt om de opties aan te vullen tot de 32 bits. In een segment mogen meerder opties voorkomen. Hieronder is een sommatie gegeven van de beschikbare opties.
Een optie kan in twee formaten opgegeven worden:
1. Een enkele byte
2. Een driedelige optie, welke een byte bevat die aangeeft welke type optie aanwezig is, een andere die aangeeft
hoeveel bytes de opties beslaan, en als laatste de bytes die de opties aangeven.
Mogelijk opties:
Begin van File
2.6 TCP connectie opbouw
Beschrijving van figuur 2.6
De sequentie nummers worden willekeurig gekozen, afhankelijk van de waarde van de ISN (Initiële Sequentie Nummer). Zoals in figuur 2.6 wordt geïllustreerd, wordt tijdens de opbouw van de verbinding een ISN (Initiële Sequentie Nummer) onderhandeld. Zo geeft TCP A aan dat zijn ISN=100 is in zijn SYN-segment. TCP B ontvangt het SYN-segment van TCP A, en verstuurd een SYN-RECVD-segment met zijn ISN=200 samen met een bevestiging van het SYN-segment (ACK=101). Dus hiermee geeft TCP B aan dat het eerst volgende pakketnummer welke hij verwacht van TCP A dus 101 is. Zie later meer over de initiele sequence nummering.
Ook zien we dat een TCP connectie zich in een bepaalde state kan bevinden. Zo staat tijdens de opbouw van de verbinding TCP A in de state CLOSED en staat TCP B in de state LISTEN. De verschillende TCP toestanden hangen af van de applicaties die op deze hosts draaien, zo heeft een server applicatie andere toestanden dan een cliënt applicatie. In figuur 2.6 is duidelijk te zien dat TCP a de cliënt is, en dat TCP B de server applicatie is.
Aangezien een TCP verbinding een full-duplex verbinding is, kan het dus ook voorkomen dat TCP A en TCP B tegelijkertijd een connectie met elkaar proberen te openen. Deze situatie is beschreven in figuur 2.7.
Beschrijving van figuur 2.7:
TCP A en TCB B zitten beidden in de CLOSED state. In stap 2 wordt door TCP A een SYN-segment verstuurd naar TCB B, en terwijl deze nog onderweg is wordt in stap 3 door TCP B een SYN-segment verstuurd naar TCP A. Het segment van TCP B komt aan bij TCP A en deze gaat van de SYN-SENT state naar de SYN-RECVD state. In stap 4 gebeurt hetzelfde bij TCP B, deze ontvangt de SYN-segment van TCP A en gaat van SYN-SENT state naar SYN-RECVD state. In stap 5 verstuurt TCP A een bevestiging van het SYN-segment naar TCP B terwijl de bevestiging van TCP A nog onderweg is, wordt door TCP B ook een bevestiging van het SYN-segment verstuurd naar TCP A. In stap 6 krijgt TCP A de bevestiging van TCP B binnen en gaat naar de ESTABLISHED stat. In stap 7 komt even later de bevestiging van TCP A binnen, en gaat deze ook naar de ESTABLISHED state.
Begin van File
2.7 Het detecteren van een oude dubbele connectie-opbouw
Beschrijving van figuur 2.8:
Het voordeel van de 3-wegs handshaking van TCP is dat heel gemakkelijk oude SYN-segmenten kunnen worden gedetecteerd. Figuur 2.8 illustreert hoe een oude SYN-segment wordt opgevangen door TCP. In lijn 2 wordt een goedde SYN-segment verstuurd, maar deze wordt vertraagd waarbij intussen dan een oudde SYN-segment, van een vorige sessie, bij TCB B aankomt (lijn 3). Als de ACK voor het oude SYN-segment terugkomt in lijn 4 reageert TCP A met een RST (RESET) segment (lijn 5). Als het RST-segment aankomt bij TCP B terwijl TCP B in een ongeschynchronieerde toestand bevindt ( SYN-SENT of SYN-RECVD), zal TCP B terug vallen naar de passieve OPEN of actieve OPEN state. Het is dus van belang dat TCP bijhoudt of het in actieve OPEN state of passieve OPEN state bevond. TCP gaat dan terug naar de LISTEN toestand. Nu komt de originele SYN-segment aan bij TCP B welke wel aan de eisen van de huidige connectie voldoet (lijn 6), nu wordt dus weer een gewone connectie opgebouwd zoals altijd.
Begin van File
2.8 Half open connectie detectie
Beschrijving van Figuur 2.9:
Het kan ook voorkomen dat tijdens een verbinding een van de machines crashed. Figuur 2.9 laat dan zien hoe deze situatie wordt opgelost. In lijn 1 is te zien dat TCP A crashed tijdens een verbinding die al opgezet was. Nu gaat TCP A weer trachtten om een verbinding op te zetten, terwijl TCP B denkt dat de connectie nog steeds bestaat omdat het geen FIN-segment heeft ontvangen. TCP A verstuurt een SYN-segment met nummer 400 naar TCP B, als deze aankomt bij TCP B dan weet deze geen raad met het segment maar bewaart deze wel. TCP B verwacht een pakket met nummer 300, en maakt dit kenbaar door een segment te versturen dat hij op ontvangstnummer nummer 101 zit te wachten, en dat het alle pakketten van voorheen goed heeft ontvangen. In regel 4 verwacht TCP A een ACK op zijn SYN-segment, maar krijgt nu een pakket met een totaal andere nummer, TCP A verstuurt dan in regel 5 een RST(reset)-segment om TCP B te resetten. TCP B ontvangt het RST-segment en verbreekt zijn verbinding. Nu haalt TCP B weer het oude ontvangen segment op, en stuurt hier een response op, dus een SYN-segment naar TCP A. Dit gebeurt dus in lijn 7. Hierna wordt dus weer een normale connectie opgebouwd.
Connecties worden over het algemeen gereset als er data binnenkomt welke niet voor de huidige connectie is bedoeld. Als het niet zeker is of de data bedoeld is voor de huidige connectie, worden de volgende regels gevolgd om te bepalen of er een RST-segment moet worden verstuurd of niet.
1. Als de connectie niet bestaat (bv. CLOSED is), dan wordt een reset verstuurd op response van een inkomend segment , tenzij het een RST-segment betreft. Als het inkomende segment een ACK bevat, wordt het reset segment zo opgebouwd dat het, het pakketnummer van het ACK segment bevat. In alle andere gevallen wordt een reset segment verstuurd met pakketnummer 0, en de ACK-veld wordt gezet op de som van de pakketnummer en de lengte van het segment welke het probleem in eerste instantie veroorzaakte. De connectie blijft gesloten.
2. Als de connectie zich in een niet gesynchroniseerde toestand bevindt (bv. LISTEN, SYN-SENT, of SYN- RECVD) , en het inkomende segment bevestigt iets dat nog niet is verstuurd, of als het inkomende segment andere niet correcte attributen bevat (bv. goede security of precedence indicators) dan moet dus ook een reset verstuurd worden. De pakketnummer en het ACK veld worden gegenereerd zoals in 1. staat vermeld.
3. Als de connectie zich in een gesynchroniseerde toestand bevindt (bv. ESTABLISHED) dan wordt elke niet accepteerbare segment (bv. foutieve pakketnummers, e.d.) opnieuw verstuurd in een ACK segment welke geen data bevat . Dit segment moet dan het huidige pakketnummer en een bevestigings nummer hebben welke nog ontvangen moet worden.
Meer details kan gevonden worden in RFC 793 en RFC 1122. Zie de Literatuur verwijzing in de bijlagen van dit verslag.
Begin van File
2.9 Keuze van het Initiële Sequentie-nummer
Voor het hergebruik van sockets (poort nummer, en adres) zijn vrijwel geen restricties gedefinieerd. Nieuwe incarnaties van een oude socket kunnen problemen opleveren als de nieuwe incarnatie van de socket dezelfde sequentie nummers gaat gebruiken die net voorheen in een eerdere connectie werd gebruikt. Het is noodzakelijk om connecties te kunnen hergebruiken, anders zouden de vrije sockets langzaam opraken, voornamelijk als een host is gecrasht.
Het ISN (Initiële Sequentie Nummer) heeft een grote maar doch een eindige waarde. De ISN kan waarden aannemen tussen 0 en 232-1. In het huidige ontwerp van de TCP/IP-protocol specificatie , wordt aangenomen dat een initiële sequentie nummer generator tikt met een snelheid van ongeveer één tick per vier microseconde. Het initiele sequentie nummer begint elke 4.55 uur weer opnieuw met zijn tel cyclus. Hierbij wordt aangenomen dat een segment niet zo lang in het netwerk aanwezig is, zodat tegen de tijd dat de ISN zijn nieuwe cyclus begint, elke vorige segment welke dezelfde ISN nummer gebruikt al lang weg is van het netwerk. Deze aanname wordt helaas moeilijker als men gaat werken met high speed netwerken, waarbij dus de cyclus tijd van het ISN veel kleiner is. Hier wordt apart aandacht aan geschonken in een van de paragrafen over hoge snelheid netwerken. Ondanks een goede voorzorgsmaatregel voor ontwerp van het protocol, kan als een host crasht deze alle informatie kwijtraken over zijn vorige verbindingen en hoe lang het down is geweest. Voor deze gevallen, is het noodzakelijk voor het TCP protocol dat een host welke down is geweest geen nieuwe connecties accepteert of erop reageert, gedurende de MSL (Maximum Segment Lifetime) tijd welke volgens de TCP specificaties 2 minuten bedraagt. Deze tijd wordt ook wel de quiet time genoemd. Gedurende deze tijd mag de host geen verbindingen opzetten of accepteren. Een alternatief op de quiet time is om segmenten een soort van een tijd stempel (time-stamp) te geven. Met de tijd stempel kan nagegaan worden hoe vers de segmenten zijn. Meer hierover wordt verderop in dit hoofdstuk behandeld.
Begin van File
2.10 Normale connectie verbreking
Beschrijving van Figuur 2.10:
Omdat TCP full-duplex communicatie toelaat, is het zo, dat als één kant de verbinding verbreekt dat niet wil zeggen dat dan automatisch de andere kant ook klaar is met het versturen van data. De TCP CLOSE operatie betekent dus meer 'Ik heb geen data meer te versturen' dan 'Ik wil geen data meer ontvangen'. Dit betekent dus dat als de ontvangende TCP de connectie moet blijven open houden totdat hij alle data binnen heeft en van de zendende TCP de melding krijgt dat de verbinding verbroken mag worden. Ook al is het proces aan de ontvangende TCP klaar en heeft aan de operating systeem doorgegeven dat het klaar is met versturen van data, moet de verbinding open blijven totdat de zendende TCP ook klaar is met het versturen van data.
Er zijn drie manieren waarop een verbinding gesloten kan worden:
1. De lokale TCP voert een close uit als response op de applicatie.
2. De remote TCP doet een close (segment waarbij het FIN control veld '1' is)
3. Beide TCP's sluiten tegelijkertijd (Simultane close)
In figuur 2.10 wordt in stap 2 door TCP A een FIN-segment verstuurd naar TCP B . Hiermee geeft TCP A dat het klaar is met het versturen van data. TCP A gaat dan naar het FIN-WAIT toestand, en wacht op bevestiging van zijn FIN-segment of op een FIN-segment van TCP B. In lijn 3 krijgt TCP A een bevestiging van TCP B van zijn FIN-segment en gaat nu in de TIMEWAIT toestand, en wacht op een FIN van TCP B. In lijn 4 ontvangt TCP A een FIN-segment van TCP B, in lijn 5 verstuurt TCP A dan een bevestiging van het FIN-segment van TCP B. TCP B gaat naar de CLOSED toestand zodra het de bevestiging van TCP A heeft ontvangen, dus in lijn 5. In lijn 5 wacht TCP A een tijd van 2 x de MSL (Maximum Segment Lifetime) voordat het de verbinding daadwerkelijk verbreekt. Deze manier van connectie verbreking gebeurt dus op manier 1 zoals hierboven vermeld. Voor manier 2 geldt hetzelfde als manier 1 maar dan zijn de rollen van TCP A en TCP B verwisseld.
Manier 3, de simultane connectie verbreking, wordt getoond in figuur 2.11.
Begin van File
2.11 Window Management
Om de doorvoer van segmenten te controleren, gebruikt TCP een window om bij te houden hoeveel en welke bytes er door een TCP connectie verstuurd wordt. De window grootte wordt aangegeven in elke TCP header. De ontvanger van een pakket geeft aan in de TCP header van een bevestigings pakket hoeveel bytes verstuurd mag worden en ook, gebaseerd op de waarde van de bevestiging veld in de TCP header, welke byte sequentie nummer verstuurd mag worden. De ontvangende TCP mag de window grootte aanpassen om zo de hoeveelheid data te vergroten of verkleinen die het zou willen ontvangen als het bevestigingen stuurt van vorige ontvangen data pakketten. In normale omstandigheden wordt tijdens de opbouw van een verbinding ook de window grootte onderhandeld, en kan al naar gelang worden veranderd als er behoefte naar is. Als de window grootte zo wordt verkleind dat het permissies terug neemt van pakketten welke al waren toegekend om data te versturen, wordt dit gezien als een error.
In figuur 2.12 staat aangegeven hoe een zend window eruit ziet, als de bron TCP een zend window heeft van 3 bytes data. In het begin is de zend window 3 bytes lang, en zoals figuur 2.12 laat zien is er nog geen data verstuurd. Figuur 2.13 laat nu zien hoe de window eruit ziet nadat er 2 bytes data is verzonden door de window.
Zoals in figuur 2.13 is te zien, zien we dat er nog geen ontvangst bevestiging is van de twee verzonden pakketten, daarom blijft het begin van de window staan op pakket 0. We zien dat er nu alleen nog pakket 3 verstuurd mag worden, dit geeft tevens onze maximale aantal pakketten welke verstuurd mogen worden aan, dus 1.
In figuur 2.14 is nu te zien hoe de zend window eruit ziet als een bevestiging van de twee verstuurde pakketten is ontvangen.
We zien in figuur 2.14 dat als de verzonden bytes worden bevestigd de linker kant van de window 2 opschuift. Aangezien de zend window hier drie bedraagt schuift de rechterkant van de window ook mee, dus twee naar rechts.
In de vorige figuren is duidelijk geworden hoe de zend window wordt gebruikt om pakketten te kunnen bijhouden welke al verstuurd zijn, en wat de maximale uitstaande pakketten mogen zijn. De zend window mag ook op nul gezet worden als er bijvoorbeeld geen pakketten meer verstuurd mogen worden. Als dit het geval is, mag de zendende TCP toch kleine data segmentjes versturen naar de ontvangende TCP om te kunnen achterhalen of de host niet gecrasht is. Dit wordt in vaktermen ook wel het 'proben van een window' genoemd op bepaalde tijdstippen.
Begin van File
2.12 Hertransmissie Timeouts
Als een segment verloren gaat in het netwerk, wordt gebruik gemaakt van timeouts aan de zender kant om zo de verloren segmenten op te vangen. De zender start een timer als het een segment verstuurd, als niet binnen de timer tijd een ACK op de verzonden segment wordt ontvangen, zal het de betreffende segment opnieuw gaan versturen. De keuze van de timeout teller is een hele delicate kwestie, omdat als deze niet goed is afgesteld zal onnodig bandbreedte van het netwerk worden gebruikt voor nutteloze hertransmissies van segmenten. Als de timeout te lang is, zal de effectiviteit van de datatransmissie snelheid afnemen omdat door herstelling van verloren data te traag zal gebeuren. Omdat vertragingen in een store-and-forward netwerk erg varieert, is het een zware uitdaging om een optimale timeout waarde te vinden.
Er zijn voor TCP twee belangrijke optimalisaties ontwikkeld door Van Jacobsen, Philip Karn, en Craig Partridge.
De oorspronkelijke round trip time schatting werkte alleen onder omstandigheden waarbij de round-trip tijd niet
erg varieerde. Dus dat betekende dat de oorspronkelijke algoritmes herschreven moesten worden, omdat de
oorspronkelijke algoritmes niet in alle omstandigheden correct werkten. Bijvoorbeeld in een lage snelheid
netwerk kan de round trip tijd van pakketten erg varieren afhankelijk van de grootte van de pakketten, welke dus
problemen geeft als de originele algoritmes gebruikt zouden worden.
Een goedde berekening van de round-trip tijd zal hertransmissies tot een minimum beperken, zodat optimaal van
de beschikbare bandbreedte gebruik kan worden gemaakt.
Karn specificeert welke gemeten round-trip tijden gebruikt zouden moeten worden in de algoritme voor het
berekenen van de round-trip tijd. Van Jacobsen recommandeert een methode om de geschatte round-trip tijden te
verfijnen, welke uitgaat van de gemeten variantie van de round-trip tijd.
Voor verdere studie over de schatting van de round trip tijd, kan men de bijbehorende RFC’s doorlezen. Dit zijn
de RFC’s 1072, 1185.
Begin van File
2.13 Netwerken met lange vertragingen
Zoals eerder is geconstateerd is een combinatie van bandbreedte en round-trip tijden bepalend voor de efficientie van de gebruikte netwerkverbinding. Het produkt van de snelheid van het netwerk met de round-trip tijd wordt ook wel ‘delay bandwidth product’ genoemd. Als dit produkt groter is dan toegestane windowgrootte zal de throughput er onder gaan lijden terwijl de zender het versturen van paketten uitstelt totdat de bevestigingen van de verstuurde data. Als de ‘delay bandwidth product’ groter is dan de maximale grootte van de window, is er geen enkele mogelijkheid om dit probleem te verhelpen.
Een tweede probleem die zich voordoet in long-delay netwerken, is de cummulatieve werking van de bevestigings algoritme welke gebruikt wordt in TCP. Als een segment verloren gaat, zullen de segmenten die daarna komen en goed overkomen, niet bevestigd kunnen worden, totdat het verloren segment wordt bevestigd. Zo kan dus door 1 segment, welke is verloren gegaan, de daarop volgende segmenten niet geaccepteerd worden door de ontvangende TCP, totdat er een hertransmissie heeft plaats gevonden van het verloren segment. Dit betekent dus dat onnodig de andere segmenten ook opnieuw verstuurd zouden moeten worden, die eigenlijk goed waren aangekomen.
Voorbeeld:
Er wordt een segment met nummer 1 verstuurd. Dit segment gaat verloren. De zendende TCP gaat door
met het versturen van segmenten. Deze segmenten komen goed aan bij de ontvangende TCP, maar deze zit te
wachten op een segment met nummer 1. Dus de ontvangende TCP negeert alle andere segmenten totdat het
segment 1 krijgt, en gaat dan pas weer andere segmenten accepteren.
Uit het bovenstaande voorbeeld kan dus worden geconcludeerd dat het misschien beter is om een selectieve bevestiging algoritme te gebruiken. Hierbij kan dus aangegeven worden welk segment niet is aangekomen en of alleen dat segment opnieuw verstuurd kan worden. Een derde nadeel van long-delay netwerken is dat de round-trip tijd continu gemeten moet worden, om zo veranderingen in de round-trip tijd te kunnen opvangen. Als dit niet gedaan wordt kan dit leiden tot congestie van het netwerk of inefficiënt gebruik van de netwerkcapaciteit. Omdat het berekenen van de round-trip tijd erg tijd consumerend is, wordt bij sommige TCP implementaties alleen de round-trip tijd van 1 segment per window opgemeten. Voor een netwerk welke gebruik maakt van kleine windows is deze algoritme goed te gebruiken, maar voor long-delay netwerken met grote window grootte is deze algoritme niet goed genoeg. Een oplossing voor dit soort netwerken is ontwikkeld door Jacobsen en Braden. Jacobsen en Braden stellen voor om, de ingestelde window grootte flexibel te kunnen wijzigen, gebruik te maken van een selectieve bevestigings algoritme en gebruik te maken van TCP echo optie om de round-trip tijd te berekenen. De window Schalings optie, vergroot de effectieve window grootte met 2S waar S de window schalings factor is. In de huidige specificaties is S kleiner dan of gelijk aan 14, dus een effectieve window grootte levert tot aan 230, oftewel 1 gigabyte. Om de ontvanger het mogelijk te maken om de zender te laten weten dat data niet in volgorde binnenkomt, wordt een selectieve bevestiging algoritme gebruikt. Omdat een selectieve bevestigings algoritme nog niet is gestandaardiseerd, zal dus TCP’s met de originele bevestigings algoritme ondersteund moeten blijven. Dit zal dus goed gaan, maar zal nooit zo effectief werken als gebruik wordt gemaakt van de selectieve bevestigings algoritme.
Begin van File
2.14 Hogesnelheids netwerken
Gigabit netwerken beginnen nu op de markt te verschijnen. TCP door zijn begrensde window grootte (65536 bytes max.) , kan van deze hogesnelheids netwerken geen optimaal gebruik maken van de transmissie capaciteit, als de vertraging voor bevestiging groter is dan de tijd om een volledig maximum grootte window te versturen. Van Jacobsen, Braden en Zhang beschrijven methoden om deze limieten te overwinnen. Hoge snelheidsnetwerken hebben nog een extra uitdaging en dat is dat de sequentie nummering sneller verloopt dan in de andere netwerken waar TCP/IP in eerste instantie voor bedoeld was. Als dit gebeurt bestaat een grote kans dat oude duplikaten pakketten als huidige pakketten worden gezien, en worden geaccepteerd, waardoor TCP helemaal de mist in loopt en zijn oorspronkelijke functie, het leveren van een 100% betrouwbare gegevensoverdracht, niet meer waar kan maken. Duplicaten van sequentie nummers kan voorkomen, als de sequentie nummers hergebruikt worden in de huidige connectie voordat alle vorige pakketten, welke die sequentie nummers gebruiken, worden afgeleverd of omdat een oude connectie pakketten heeft achter gelaten in het netwerk en een nieuwe connectie gestart wordt voordat de oude pakketten verdwenen zijn.
De snelheidsverloop van de nummering sequentie is gedeeltelijk een functie van een netwerk om verkeer te accepteren en de permissie van de ontvanger om data te ontvangen. Als er geen limitaties worden gezet aan de snelheid van de nummerings tijd, beschrijft tabel 1 de diverse tijden in netwerken dat de sequentie nummering afloopt en weer begint bij de beginwaarde.
Zoals gezien kan worden in tabel 1, zien we dat bij snelheden sneller dan 45 Mbits/sec komt de wrap time (tijd om sequentie nummers te doorlopen) tegen de tijd van de MSL (Maximum Segment Lifetime = 120 seconden) tijd aan waardoor de TTL mechanisme de mist in zal lopen. Van Jacobsen, Zhang en Braden stellen voor om tijdstempels te gebruiken . Het idee is dat elk segment die aankomt welke een tijdstempel heeft die kleiner is dan de meest actuele geaccepteerde segment tijd stempel, weggegooid moet worden als een oudde duplikaat.
Een ander probleem die zich ook voor kan doen is dat sequentie nummers verkeerd worden gebruikt na een crash
van een systeem welke bezig was om segmenten te versturen. De standaard TCP specificatie zegt dat een zgn.
quiet time gewacht moet worden voordat de gecrashte host weer een connectie kan proberen te maken. Dit wordt
gespecificeerd als 2 keer de MSL (Maximum Segment Lifetime). Eenzelfde strategie wordt gebruikt voor het
sluiten van verbinding om beidde zijden de mogelijkheid te geven om goed de connectie te kunnen afsluiten.
Volgende hoofdstuk
