Transportlaag

7.0. Transportlaag

7.0.1. Introductie

Datanetwerken en internet ondersteunen het menselijke netwerk door betrouwbare communicatie tussen mensen te bieden. Op één apparaat kunnen mensen meerdere toepassingen en services gebruiken, zoals e-mail, internet en instant messaging, om berichten te verzenden of informatie op te halen. Toepassingen zoals e-mailclients, webbrowsers en instant messaging-clients stellen mensen in staat computers en netwerken te gebruiken om berichten te verzenden en informatie te zoeken.

Gegevens van elk van deze applicaties worden verpakt, getransporteerd en afgeleverd bij de juiste applicatie op het bestemmingsapparaat. De processen beschreven in de OSI-transportlaag accepteren gegevens van de applicatielaag en bereiden deze voor op adressering op de netwerklaag. De transportlaag bereidt gegevens voor op verzending over het netwerk. Een broncomputer communiceert met een ontvangende computer om te beslissen hoe gegevens in segmenten worden opgesplitst, hoe ervoor kan worden gezorgd dat geen van de segmenten verloren gaat en hoe kan worden gecontroleerd of alle segmenten zijn aangekomen. Denk bij de transportlaag aan een verzendafdeling die een enkele bestelling van meerdere pakketten voorbereidt voor bezorging.

In dit hoofdstuk onderzoeken we de rol van de transportlaag bij het inkapselen van applicatiedata voor gebruik door de netwerklaag. De transportlaag omvat ook deze functies:

• Hiermee kunnen meerdere applicaties, zoals e-mailen en sociale netwerken, tegelijkertijd via het netwerk communiceren op één apparaat
• Zorgt ervoor dat, indien nodig, alle gegevens betrouwbaar en in orde worden ontvangen door de juiste applicatie
• Maakt gebruik van mechanismen voor foutafhandeling

7.1. Transportlaag-protocollen

7.1.1. Transport van gegevens

7.1.1.1. Rol van de transportlaag

De transportlaag is verantwoordelijk voor het tot stand brengen van een tijdelijke communicatiesessie tussen twee applicaties en het leveren van gegevens daartussen. Een applicatie genereert gegevens die vanuit een applicatie op een bronhost naar een applicatie op een bestemmingshost worden verzonden, ongeacht het type bestemmingshost, het type medium waarover de data moet reizen, het pad dat de data aflegt, de congestie op een link, of de grootte van het netwerk. Zoals weergegeven in de figuur, is de transportlaag de link tussen de applicatielaag en de onderste lagen die verantwoordelijk zijn voor netwerktransmissie.

De transportlaag biedt een methode om gegevens over het netwerk te verzenden op een manier die ervoor zorgt dat de gegevens weer correct kunnen worden samengevoegd aan de ontvangende kant. De transportlaag zorgt voor de segmentering van gegevens en de controles die nodig zijn om deze segmenten weer samen te voegen tot de verschillende communicatiestromen. In TCP / IP kunnen deze segmentatie- en herassemblageprocessen worden bereikt met behulp van twee zeer verschillende transportlaagprotocollen: Transmission Control Protocol (TCP) en User Datagram Protocol (UDP).

De primaire verantwoordelijkheden van transportlaagprotocollen zijn:

• Het volgen van de individuele communicatie tussen applicaties op de bron- en bestemmingshosts
• Gegevens segmenteren voor beheersbaarheid en gesegmenteerde gegevens opnieuw samenvoegen tot stromen toepassingsgegevens op de bestemming
• Identificatie van de juiste toepassing voor elke communicatiestroom

Individuele communicatie bijhouden

Op de transportlaag wordt elke specifieke set gegevens die tussen een brontoepassing en een bestemmingstoepassing stroomt, een conversatie genoemd (Figuur 1). Een host kan meerdere applicaties hebben die tegelijkertijd via het netwerk communiceren. Elk van deze applicaties communiceert met een of meer applicaties op een of meer externe hosts. Het is de verantwoordelijkheid van de transportlaag om deze meerdere gesprekken te onderhouden en te volgen.

Gegevens segmenteren en segmenten opnieuw samenvoegen

Gegevens moeten voorbereid zijn om in beheersbare stukjes over de media te worden verzonden. De meeste netwerken hebben een beperking op de hoeveelheid gegevens die in een enkel pakket kan worden opgenomen. Transportlaagprotocollen hebben services die de toepassingsgegevens segmenteren in blokken gegevens van de juiste grootte (Afbeelding 2). Deze service omvat de inkapseling die vereist is voor elk gegeven. Aan elk gegevensblok wordt een header toegevoegd die wordt gebruikt voor het opnieuw samenstellen. Deze header wordt gebruikt om de datastroom te volgen.

Op de bestemming moet de transportlaag de stukjes data kunnen reconstrueren tot een complete datastroom die nuttig is voor de applicatielaag. De protocollen op de transportlaag beschrijven hoe de kopinformatie van de transportlaag wordt gebruikt om de datastukken weer samen te voegen tot stromen die naar de applicatielaag worden gestuurd.

Identificatie van de toepassingen

Mogelijk zijn er veel toepassingen of services actief op elke host in het netwerk. Om datastromen door te geven aan de juiste applicaties, moet de transportlaag de doeltoepassing identificeren (Figuur 3). Om dit te bereiken, wijst de transportlaag aan elke applicatie een identificatie toe. Deze identificatie wordt een poortnummer genoemd. Elk softwareproces dat toegang moet hebben tot het netwerk, krijgt een poortnummer toegewezen dat uniek is in die host. De transportlaag gebruikt poorten om de applicatie of service te identificeren.

7.1.1.2. Conversatie-multiplexing

Het verzenden van bepaalde soorten gegevens (bijvoorbeeld een streamingvideo) over een netwerk, als één complete communicatiestroom, kan alle beschikbare bandbreedte gebruiken en voorkomen dat andere communicatie tegelijkertijd plaatsvindt. Het maakt ook foutherstel en heroverdracht van beschadigde gegevens moeilijk.

De figuur laat zien dat door het segmenteren van de gegevens in kleinere stukjes, veel verschillende communicaties van veel verschillende gebruikers kunnen worden geïnterleaved (gemultiplexed) op hetzelfde netwerk. Segmentatie van de gegevens door transportlaagprotocollen biedt ook de mogelijkheid om zowel gegevens te verzenden als te ontvangen wanneer meerdere toepassingen tegelijkertijd op een computer worden uitgevoerd.

Zonder segmentatie zou slechts één applicatie gegevens kunnen ontvangen. Bij een streamingvideo worden de media bijvoorbeeld volledig verbruikt door de ene communicatiestroom in plaats van gedeeld. U kunt geen e-mails ontvangen, chatten op instant messenger of webpagina’s bekijken terwijl u de video bekijkt.

Om elk gegevenssegment te identificeren, voegt de transportlaag aan het segment een header toe die binaire gegevens bevat. Deze header bevat velden met bits. Het zijn de waarden in deze velden die verschillende transportlaagprotocollen in staat stellen verschillende functies uit te voeren bij het beheren van datacommunicatie.

7.1.1.3 Betrouwbaarheid van de transportlaag

De transportlaag is ook verantwoordelijk voor het managen van betrouwbaarheidsvereisten van een gesprek. Verschillende toepassingen stellen verschillende transportbetrouwbaarheidseisen.

IP heeft alleen betrekking op de structuur, adressering en routering van pakketten. IP geeft niet aan hoe de levering of het transport van de pakketten plaatsvindt. Transportprotocollen specificeren hoe berichten tussen hosts moeten worden overgedragen. TCP / IP biedt twee transportlaagprotocollen, Transmission Control Protocol (TCP) en User Datagram Protocol (UDP), zoals weergegeven in de afbeelding. IP gebruikt deze transportprotocollen om hosts in staat te stellen te communiceren en gegevens over te dragen.

TCP wordt beschouwd als een betrouwbaar transportlaagprotocol met alle functies, dat ervoor zorgt dat alle gegevens op de bestemming aankomen. UDP daarentegen is een zeer eenvoudig transportlaagprotocol dat geen enkele betrouwbaarheid biedt.

7.1.1.4. TCP

Zoals eerder vermeld, wordt TCP beschouwd als een betrouwbaar transportprotocol, wat betekent dat TCP processen omvat om een ​​betrouwbare levering tussen applicaties te garanderen door het gebruik van bevestigde levering. TCP-transport is analoog aan het verzenden van pakketten die van bron naar bestemming worden gevolgd. Als een FedEx-bestelling is opgedeeld in verschillende zendingen, kan een klant online controleren om de volgorde van de levering te zien.

Met TCP zijn de drie basisbewerkingen van betrouwbaarheid:

• Verzonden gegevenssegmenten volgen
• Ontvangen gegevens bevestigen
• Alle niet-bevestigde gegevens opnieuw verzenden

TCP verdeelt een bericht in kleine stukjes die bekend staan ​​als segmenten. De segmenten worden op volgorde genummerd en doorgegeven aan het IP-proces voor assemblage in pakketten. TCP houdt het aantal segmenten bij dat vanuit een specifieke applicatie naar een specifieke host is verzonden. Als de afzender binnen een bepaalde tijd geen bevestiging ontvangt, gaat hij ervan uit dat de segmenten verloren zijn gegaan en verzendt deze opnieuw. Alleen het gedeelte van het bericht dat verloren is gegaan, wordt opnieuw verzonden, niet het hele bericht. Op de ontvangende host is TCP verantwoordelijk voor het opnieuw samenstellen van de berichtsegmenten en deze door te geven aan de toepassing. Het File Transfer Protocol (FTP) en het Hypertext Transfer Protocol (HTTP) zijn voorbeelden van toepassingen die TCP gebruiken om de levering van gegevens te garanderen.

Klik op de knop Afspelen in de afbeelding om een ​​animatie te zien van de TCP-segmenten die van zender naar ontvanger worden verzonden.

Deze betrouwbaarheidsprocessen zorgen voor extra overhead op netwerkbronnen vanwege de processen van bevestiging, tracking en opnieuw verzenden. Om deze betrouwbaarheidsprocessen te ondersteunen, worden meer besturingsgegevens uitgewisseld tussen de verzendende en ontvangende hosts. Deze besturingsinformatie is vervat in een TCP-header.

7.1.1.5. UDP

Hoewel de TCP-betrouwbaarheidsfuncties een robuustere communicatie tussen toepassingen bieden, leiden ze ook tot extra overhead en mogelijke vertragingen bij de verzending. Er is een afweging tussen de waarde van betrouwbaarheid en de belasting die dit op netwerkbronnen legt. Het opleggen van overhead om de betrouwbaarheid van sommige applicaties te garanderen, zou het nut van de applicatie kunnen verminderen en kan zelfs schadelijk zijn voor de applicatie. In dergelijke gevallen is UDP een beter transportprotocol.

UDP biedt alleen de basisfuncties voor het leveren van gegevenssegmenten tussen de betreffende toepassingen, met zeer weinig overhead en gegevenscontrole. UDP staat bekend als een best-effort leveringsprotocol. In de context van netwerken wordt levering naar beste vermogen onbetrouwbaar genoemd, omdat er geen bevestiging is dat de gegevens op de bestemming zijn ontvangen. Met UDP zijn er geen transportlaagprocessen die de afzender informeren of een succesvolle bezorging heeft plaatsgevonden.

UDP is vergelijkbaar met het plaatsen van een gewone, niet-aangetekende brief in de post. De afzender van de brief weet niet of er een ontvanger beschikbaar is om de brief te ontvangen, noch is het postkantoor verantwoordelijk voor het volgen van de brief of het informeren van de afzender als de brief niet aankomt op de eindbestemming.

Klik op de knop Afspelen in de afbeelding om een ​​animatie te zien van UDP-segmenten die van zender naar ontvanger worden verzonden.

7.1.1.6. Het juiste transportlaagprotocol voor de juiste toepassing

Zowel TCP als UDP zijn geldige transportprotocollen. Afhankelijk van de toepassingsvereisten kan een van deze transportprotocollen of soms beide worden gebruikt. Applicatieontwikkelaars moeten kiezen welk type transportprotocol geschikt is op basis van de vereisten van de applicaties.

Voor sommige toepassingen moeten segmenten in een zeer specifieke volgorde aankomen om succesvol te kunnen worden verwerkt. Bij andere toepassingen moeten alle gegevens volledig zijn ontvangen voordat ze als nuttig worden beschouwd. In beide gevallen wordt TCP als transportprotocol gebruikt. Toepassingen zoals databases, webbrowsers en e-mailclients vereisen bijvoorbeeld dat alle gegevens die worden verzonden, in de oorspronkelijke staat op de bestemming aankomen. Eventuele ontbrekende gegevens kunnen een corrupte communicatie veroorzaken die onvolledig of onleesbaar is. Daarom zijn deze applicaties ontworpen om TCP te gebruiken. De extra netwerkoverhead wordt nodig geacht voor deze toepassingen.

In andere gevallen kan een toepassing enig gegevensverlies tolereren tijdens verzending via het netwerk, maar vertragingen in de verzending zijn onaanvaardbaar. UDP is de betere keuze voor deze toepassingen omdat er minder netwerkoverhead vereist is. UDP verdient de voorkeur bij toepassingen, zoals streaming audio, video en Voice over IP (VoIP). Erkenningen zouden de bezorging vertragen en hertransmissies zijn ongewenst.

Als een of twee segmenten van een videostream bijvoorbeeld niet arriveren, ontstaat er een tijdelijke onderbreking in de stream. Dit kan verschijnen als vervorming in het beeld, maar is misschien niet eens merkbaar voor de gebruiker. Aan de andere kant zou het beeld in een streaming video sterk verslechteren als het bestemmingsapparaat rekening zou moeten houden met verloren gegevens en de stream zou moeten vertragen in afwachting van opnieuw verzenden. In dit geval is het beter om de best mogelijke video weer te geven met de ontvangen segmenten en af ​​te zien van betrouwbaarheid.

Internetradio is een ander voorbeeld van een applicatie die UDP gebruikt. Als een deel van het bericht verloren gaat tijdens zijn reis over het netwerk, wordt het niet opnieuw verzonden. Als een paar pakketten worden gemist, kan de luisteraar een kleine onderbreking in het geluid horen. Als TCP zou worden gebruikt en de verloren pakketten opnieuw zouden worden verzonden, zou de transmissie pauzeren om ze te ontvangen en zou de verstoring meer merkbaar zijn.

7.1.2. Introductie van TCP en UDP

7.1.2.1. Introductie van TCP

Om de verschillen tussen TCP en UDP echt te begrijpen, is het belangrijk om te begrijpen hoe elk protocol specifieke betrouwbaarheidsfuncties implementeert en hoe ze de communicatie volgen.

Transmission Control Protocol (TCP)

TCP werd aanvankelijk beschreven in RFC 793. Naast ondersteuning van de basisfuncties van gegevenssegmentatie en hermontage, biedt TCP, zoals weergegeven in de afbeelding, ook:

• Verbindingsgerichte communicatie door het opzetten van sessies
• Betrouwbare bezorging
• Geordende gegevensreconstructie
• Flow Control

Een sessie opzetten

TCP is een verbindingsgericht protocol. Een verbindingsgeoriënteerd protocol is een protocol dat onderhandelt en een permanente verbinding (of sessie) tot stand brengt tussen bron- en bestemmingsapparaten voordat verkeer wordt doorgestuurd. Het opzetten van een sessie bereidt de apparaten voor om met elkaar te communiceren. Door het opzetten van een sessie, onderhandelen de apparaten over de hoeveelheid verkeer die op een bepaald moment kan worden doorgestuurd en kunnen de communicatiegegevens tussen de twee nauw worden beheerd. De sessie wordt pas beëindigd nadat alle communicatie is voltooid.

Betrouwbare bezorging

TCP kan een methode implementeren om een ​​betrouwbare levering van de gegevens te garanderen. In netwerktermen betekent betrouwbaarheid ervoor zorgen dat elk stukje gegevens dat de bron verzendt, op de bestemming aankomt. Om vele redenen is het mogelijk dat een stukje gegevens beschadigd raakt of volledig verloren gaat, wanneer het over het netwerk wordt verzonden. TCP kan ervoor zorgen dat alle onderdelen hun bestemming bereiken door het bronapparaat verloren of beschadigde gegevens opnieuw te laten verzenden.

Bezorging in dezelfde volgorde

Omdat netwerken meerdere routes kunnen bieden die verschillende transmissiesnelheden kunnen hebben, kunnen gegevens in de verkeerde volgorde aankomen. Door de segmenten te nummeren en in volgorde te zetten, kan TCP ervoor zorgen dat deze segmenten weer in de juiste volgorde worden samengevoegd.

Flow Control

Netwerkhosts hebben beperkte bronnen, zoals geheugen of bandbreedte. Als TCP zich ervan bewust is dat deze bronnen overbelast zijn, kan het de verzendende toepassing vragen de gegevensstroom te verminderen. Dit wordt gedaan door TCP die de hoeveelheid gegevens regelt die de bron verzendt. Flow control kan het verlies van segmenten op het netwerk voorkomen en de noodzaak van heroverdracht voorkomen.

7.1.2.2. Rol van TCP

Zodra TCP een sessie tot stand heeft gebracht, kan het het gesprek binnen die sessie volgen. Omdat TCP feitelijke gesprekken kan volgen, wordt het als een stateful protocol beschouwd. Een stateful protocol is een protocol dat de status van de communicatiesessie bijhoudt. Wanneer gegevens bijvoorbeeld via TCP worden verzonden, verwacht de afzender dat de bestemming bevestigt dat het de gegevens heeft ontvangen. TCP houdt bij welke informatie het heeft verzonden en welke informatie is bevestigd. Als de gegevens niet worden bevestigd, gaat de afzender ervan uit dat de gegevens niet zijn aangekomen en verzendt deze opnieuw. De stateful sessie begint met het tot stand brengen van de sessie en eindigt wanneer de sessie wordt afgesloten met het beëindigen van de sessie.

Opmerking: het onderhouden van deze statusinformatie vereist bronnen die niet nodig zijn voor een stateless protocol, zoals UDP.

TCP brengt extra overhead met zich mee om deze functies te krijgen. Zoals weergegeven in de afbeelding, heeft elk TCP-segment 20 bytes overhead in de header die de gegevens van de toepassingslaag inkapselt. Dit is aanzienlijk meer dan een UDP-segment, dat slechts 8 bytes overhead heeft. Extra overhead omvat:

• Volgnummer (32 bits) – Wordt gebruikt voor het opnieuw samenstellen van gegevens.
• Bevestigingsnummer (32 bits) – Geeft de gegevens aan die zijn ontvangen.
• Headerlengte (4 bits) – Bekend als ʺgegevensoffsetʺ. Geeft de lengte van de TCP-segmentkop aan.
• Gereserveerd (6 bits) – Dit veld is gereserveerd voor de toekomst.
• Besturingsbits (6 bits) – Bevat bitcodes of vlaggen die het doel en de functie van het TCP-segment aangeven.
• Venstergrootte (16 bits) – Geeft het aantal segmenten aan dat tegelijkertijd kan worden geaccepteerd.
• Checksum (16 bits) – Gebruikt voor foutcontrole van de segmentkop en gegevens.
• Urgent (16 bits) – Geeft aan of gegevens urgent zijn.

Voorbeelden van toepassingen die TCP gebruiken, zijn webbrowsers, e-mail en bestandsoverdrachten.

7.1.2.3. Introductie van UDP

User Datagram Protocol (UDP)

UDP wordt beschouwd als het beste transportprotocol, beschreven in RFC 768. UDP is een lichtgewicht transportprotocol dat dezelfde gegevenssegmentatie en hermontage biedt als TCP, maar zonder TCP-betrouwbaarheid en stroomcontrole. UDP is zo’n eenvoudig protocol, dat het meestal wordt beschreven in termen van wat het niet doet in vergelijking met TCP.

Zoals weergegeven in de afbeelding, beschrijven de volgende functies UDP:

• Verbindingsloos – UDP brengt geen verbinding tot stand tussen de hosts voordat gegevens kunnen worden verzonden en ontvangen.
• Onbetrouwbare levering – UDP biedt geen services om ervoor te zorgen dat de gegevens betrouwbaar worden geleverd. Er zijn geen processen binnen UDP om de afzender gegevens die verloren of beschadigd zijn opnieuw te laten verzenden.
• Geen geordende gegevensreconstructie – Soms worden gegevens in een andere volgorde ontvangen dan ze zijn verzonden. UDP biedt geen enkel mechanisme om de gegevens in hun oorspronkelijke volgorde weer samen te voegen. De gegevens worden gewoon aan de applicatie geleverd in de volgorde waarin ze binnenkomen.
• Geen datatransportbesturing – Er zijn geen mechanismen binnen UDP om de hoeveelheid gegevens te regelen die door de bron worden verzonden om te voorkomen dat het bestemmingsapparaat wordt overweldigd. De bron stuurt de gegevens. Als bronnen op de bestemmingshost overbelast raken, schrapt de bestemmingshost waarschijnlijk gegevens die worden verzonden totdat bronnen beschikbaar komen. In tegenstelling tot TCP is er met UDP geen mechanisme voor automatische herverzending van verloren gegane gegevens.

7.1.2.4. Rol van UDP

Hoewel UDP niet de betrouwbaarheids- en flowcontrolemechanismen van TCP omvat, zoals weergegeven in de afbeelding, maakt UDP’s lage overheadgegevenslevering het een ideaal transportprotocol voor applicaties die enig gegevensverlies kunnen verdragen. De communicatiestukken in UDP worden datagrammen genoemd. Deze datagrammen worden zo goed mogelijk verzonden door het transportlaagprotocol. Enkele toepassingen die UDP gebruiken, zijn Domain Name System (DNS), videostreaming en Voice over IP (VoIP).

Een van de belangrijkste vereisten voor het leveren van live video en spraak via het netwerk is dat de gegevens snel blijven stromen. Video- en spraaktoepassingen kunnen enig gegevensverlies tolereren met minimaal of geen merkbaar effect, en zijn perfect geschikt voor UDP.

UDP is een staatloos protocol, wat betekent dat noch de klant, noch de server verplicht is om de status van de communicatiesessie bij te houden. Zoals weergegeven in de figuur, houdt UDP zich niet bezig met betrouwbaarheid of stroomregeling. Gegevens kunnen verloren gaan of in een verkeerde volgorde worden ontvangen zonder enige UDP-mechanismen om de gegevens te herstellen of opnieuw te ordenen. Als betrouwbaarheid vereist is bij het gebruik van UDP als transportprotocol, moet dit door de toepassing worden afgehandeld.

7.1.2.5. Meerdere communicaties scheiden

De transportlaag moet in staat zijn om meerdere communicaties met verschillende transportbehoeften te scheiden en te beheren. Beschouw bijvoorbeeld een gebruiker die is verbonden met een netwerk op een eindapparaat. De gebruiker ontvangt en verzendt tegelijkertijd e-mail en instant messages, bekijkt websites en voert een Voice over IP (VoIP) -telefoongesprek. Elk van deze toepassingen verzendt en ontvangt tegelijkertijd gegevens via het netwerk, ondanks verschillende betrouwbaarheidsvereisten. Bovendien worden de gegevens van het telefoongesprek niet omgeleid naar de webbrowser en wordt de tekst van een instant message niet in een e-mail weergegeven.

Voor de betrouwbaarheid eisen gebruikers dat een e-mail of webpagina volledig wordt ontvangen en volledig wordt gepresenteerd, zodat de informatie als nuttig wordt beschouwd. Kleine vertragingen bij het laden van de e-mail of webpagina zijn over het algemeen acceptabel, zolang het eindproduct in zijn geheel en correct wordt weergegeven. In dit voorbeeld beheert het netwerk het opnieuw verzenden of vervangen van ontbrekende informatie en geeft het het eindproduct pas weer als alles is ontvangen en correct is gemonteerd.

Het af en toe missen van kleine onderdelen van een telefoongesprek kan daarentegen als acceptabel worden beschouwd. Zelfs als enkele kleine delen van een paar woorden worden weggelaten, kan men de ontbrekende audio afleiden uit de context van het gesprek of de andere persoon vragen om te herhalen wat er is gezegd. Dit wordt de voorkeur gegeven boven de opgelopen vertragingen als het netwerk ontbrekende segmenten zou beheren en opnieuw zou verzenden. In dit voorbeeld beheert de gebruiker, niet het netwerk, het opnieuw verzenden of vervangen van ontbrekende informatie.

Zoals weergegeven in de afbeelding, moeten de op TCP en UDP gebaseerde services de verschillende applicaties die communiceren, bijhouden om TCP en UDP deze gelijktijdige gesprekken met verschillende vereisten te laten beheren. Om de segmenten en datagrammen voor elke toepassing te onderscheiden, hebben zowel TCP als UDP headervelden die deze toepassingen op unieke wijze kunnen identificeren. Deze unieke identificatoren zijn de poortnummers.

7.1.2.6. TCP- en UDP-poortadressering

In de koptekst van elk segment of datagram bevindt zich een bron- en bestemmingspoort. Het bronpoortnummer is het nummer voor deze communicatie die is gekoppeld aan de oorspronkelijke toepassing op de lokale host. Zoals weergegeven in de afbeelding, is het bestemmingspoortnummer het nummer voor deze communicatie die is gekoppeld aan de bestemmingstoepassing op de externe host.

Wanneer een bericht wordt afgeleverd met behulp van TCP of UDP, worden de aangevraagde protocollen en services geïdentificeerd door een poortnummer. Een poort is een numerieke identificatie binnen elk segment die wordt gebruikt om specifieke gesprekken en aangevraagde bestemmingsdiensten bij te houden. Elk bericht dat een host verzendt, bevat zowel een bron- als een bestemmingspoort.

Haven van bestemming

De client plaatst een bestemmingspoortnummer in het segment om de bestemmingsserver te vertellen welke service wordt aangevraagd. Poort 80 verwijst bijvoorbeeld naar HTTP of webservice. Wanneer een client poort 80 in de bestemmingspoort specificeert, weet de server die het bericht ontvangt dat er om webservices wordt gevraagd. Een server kan meer dan één dienst tegelijkertijd aanbieden. Een server kan bijvoorbeeld webservices aanbieden op poort 80 en tegelijkertijd een FTP-verbinding tot stand brengen op poort 21.

Bronpoort

Het bronpoortnummer wordt willekeurig gegenereerd door het verzendende apparaat om een ​​gesprek tussen twee apparaten te identificeren. Hierdoor kunnen meerdere gesprekken tegelijkertijd plaatsvinden. Met andere woorden, een apparaat kan meerdere HTTP-serviceverzoeken tegelijkertijd naar een webserver sturen. De afzonderlijke gesprekken worden bijgehouden op basis van de bronpoorten.

De bron- en bestemmingspoorten worden binnen het segment geplaatst. De segmenten worden vervolgens ingekapseld in een IP-pakket. Het IP-pakket bevat het IP-adres van de bron en bestemming. De combinatie van de bron- en bestemmings-IP-adressen en de bron- en bestemmingspoortnummers wordt een socket genoemd. De socket wordt gebruikt om de server en service te identificeren die door de client worden aangevraagd. Elke dag communiceren duizenden hosts met miljoenen verschillende servers. Die communicatie wordt geïdentificeerd door de sockets.

Het is de combinatie van het poortnummer van de transportlaag en het IP-adres van de netwerklaag van de host die op unieke wijze een bepaald toepassingsproces identificeert dat op een individueel hostapparaat wordt uitgevoerd. Deze combinatie wordt een stopcontact genoemd. Een socketpaar, bestaande uit de bron- en bestemmings-IP-adressen en poortnummers, is ook uniek en identificeert het specifieke gesprek tussen de twee hosts.

Een client-socket kan er als volgt uitzien, waarbij 1099 het bronpoortnummer vertegenwoordigt: 192.168.1.5:1099

De socket op een webserver kan zijn: 192.168.1.7:80

Samen vormen deze twee stopcontacten samen een paar stopcontacten: 192.168.1.5:1099, 192.168.1.7:80

Met het maken van sockets zijn communicatie-eindpunten bekend, zodat gegevens van een applicatie op de ene host naar een applicatie op een andere kunnen worden verplaatst. Met sockets kunnen meerdere processen die op een client worden uitgevoerd, zich van elkaar onderscheiden en kunnen meerdere verbindingen met een serverproces van elkaar worden onderscheiden.

De bronpoort van een clientverzoek wordt willekeurig gegenereerd. Dit poortnummer fungeert als een retouradres voor de aanvragende applicatie. De transportlaag houdt deze poort bij en de applicatie die het verzoek heeft geïnitieerd, zodat wanneer een antwoord wordt geretourneerd, deze kan worden doorgestuurd naar de juiste applicatie. Het poortnummer van de aanvragende applicatie wordt gebruikt als het poortnummer van de bestemming in het antwoord dat terugkomt van de server.

De Internet Assigned Numbers Authority (IANA) wijst poortnummers toe. IANA is een normalisatie-instelling die verantwoordelijk is voor het toewijzen van verschillende adresseringsnormen.

Er zijn verschillende soorten poortnummers, zoals weergegeven in afbeelding 1:

Bekende poorten (nummers 0 tot 1023) – Deze nummers zijn gereserveerd voor services en toepassingen. Ze worden vaak gebruikt voor toepassingen zoals HTTP (webserver), Internet Message Access Protocol (IMAP) / Simple Mail Transfer Protocol (SMTP) (e-mailserver) en Telnet. Door deze welbekende poorten voor servertoepassingen te definiëren, kunnen clienttoepassingen worden geprogrammeerd om een ​​verbinding met die specifieke poort en de bijbehorende service aan te vragen.
Geregistreerde poorten (nummers 1024 tot 49151) – Deze poortnummers worden toegewezen aan gebruikersprocessen of toepassingen. Deze processen zijn in de eerste plaats individuele applicaties die een gebruiker heeft gekozen om te installeren, in plaats van gewone applicaties die een bekend poortnummer zouden krijgen. Als ze niet worden gebruikt voor een serverbron, kunnen deze poorten dynamisch door een client worden geselecteerd als de bronpoort.
Dynamische of privépoorten (nummers 49152 tot 65535) – Ook bekend als kortstondige poorten, deze worden meestal dynamisch toegewezen aan clienttoepassingen wanneer de client een verbinding met een service tot stand brengt. De dynamische poort wordt meestal gebruikt om de clienttoepassing te identificeren tijdens communicatie, terwijl de client de welbekende poort gebruikt om de aangevraagde service op de server te identificeren en er verbinding mee te maken. Het is ongebruikelijk dat een client verbinding maakt met een service via een dynamische of privépoort (hoewel sommige peer-to-peer-programma’s voor het delen van bestanden deze poorten wel gebruiken).
Figuur 2 toont enkele algemeen bekende en geregistreerde poorten binnen TCP. Figuur 3 toont algemeen bekende en geregistreerde poorten binnen UDP.

Zowel TCP als UDP gebruiken

Sommige toepassingen gebruiken zowel TCP als UDP (Afbeelding 4). Door de lage overhead van UDP kan DNS bijvoorbeeld heel snel veel klantverzoeken afhandelen. Soms vereist het verzenden van de gevraagde informatie echter de betrouwbaarheid van TCP. In dit geval wordt het bekende poortnummer, 53, gebruikt door zowel TCP als UDP met deze service.

Een actuele lijst met poortnummers en de bijbehorende applicaties is te vinden op de organisatiewebsite van IANA.

Soms is het nodig om te weten welke actieve TCP-verbindingen open zijn en actief zijn op een netwerkhost. Netstat is een belangrijk netwerkhulpprogramma dat kan worden gebruikt om die verbindingen te verifiëren. Netstat geeft een overzicht van het gebruikte protocol, het lokale adres en poortnummer, het buitenlandse adres en poortnummer en de verbindingsstatus.

Onverklaarbare TCP-verbindingen kunnen een groot beveiligingsrisico vormen, omdat ze kunnen aangeven dat er iets of iemand is verbonden met de lokale host. Bovendien kunnen onnodige TCP-verbindingen waardevolle systeembronnen verbruiken, waardoor de prestaties van de host worden vertraagd. Netstat moet worden gebruikt om de open verbindingen op een host te onderzoeken wanneer de prestaties lijken te zijn aangetast.

Er zijn veel handige opties beschikbaar voor het netstat-commando. Klik op de knoppen in afbeelding 1 tot en met 5 om de verschillende informatie-uitvoer van het netstat-commando te zien.

7.1.2.7. TCP en UDP segmentatie

In een vorig hoofdstuk werd uitgelegd hoe protocol data units (PDU’s) worden gebouwd door data van een applicatie door de verschillende lagen heen te sturen om een ​​PDU te creëren die vervolgens op het medium wordt verzonden. Bij de bestemmingshost wordt dit proces omgekeerd totdat de gegevens kunnen worden doorgegeven aan de toepassing.

Sommige toepassingen verzenden grote hoeveelheden gegevens, in sommige gevallen zelfs vele gigabytes. Het zou onpraktisch zijn om al deze gegevens in één groot stuk te verzenden. Er kon geen ander netwerkverkeer worden verzonden terwijl deze gegevens werden verzonden. Het verzenden van een groot stuk gegevens kan minuten of zelfs uren duren. Bovendien, als er fouten zouden zijn, zou het volledige gegevensbestand verloren gaan of opnieuw moeten worden verzonden. Netwerkapparaten hebben geen geheugenbuffers die groot genoeg zijn om zoveel gegevens op te slaan terwijl deze worden verzonden of ontvangen. De limiet varieert afhankelijk van de netwerktechnologie en het specifieke fysieke medium dat wordt gebruikt.

Door toepassingsgegevens in segmenten op te splitsen, wordt gegarandeerd dat gegevens binnen de grenzen van de media worden verzonden en dat gegevens van verschillende toepassingen op de media kunnen worden gemultiplexed.

TCP en UDP gaan anders om met segmentatie

Zoals in de afbeelding wordt getoond, bevat elke TCP-segmentkop een volgnummer waarmee de transportlaagfuncties op de bestemmingshost de segmenten opnieuw kunnen samenstellen in de volgorde waarin ze zijn verzonden. Dit zorgt ervoor dat de bestemmingsapplicatie de gegevens heeft in de exacte vorm die de afzender heeft bedoeld.

Hoewel services die UDP gebruiken, ook de gesprekken tussen applicaties volgen; ze houden zich niet bezig met de volgorde waarin de informatie is verzonden of met het onderhouden van een verbinding. Er is geen volgnummer in de UDP-header. UDP is een eenvoudiger ontwerp en genereert minder overhead dan TCP, wat resulteert in een snellere gegevensoverdracht.

Informatie kan in een andere volgorde aankomen dan het is verzonden, omdat verschillende pakketten verschillende paden door het netwerk kunnen nemen. Een toepassing die UDP gebruikt, moet het feit tolereren dat gegevens mogelijk niet aankomen in de volgorde waarin ze zijn verzonden.

7.2. TCP en UDP

7.2.1. TCP communicatie

7.2.1.1. TCP betrouwbare bezorging

Het belangrijkste onderscheid tussen TCP en UDP is betrouwbaarheid. De betrouwbaarheid van TCP-communicatie wordt verkregen door het gebruik van verbindingsgeoriënteerde sessies. Voordat een host die TCP gebruikt gegevens naar een andere host stuurt, start TCP een proces om een ​​verbinding met de bestemming tot stand te brengen. Deze stateful verbinding maakt het mogelijk om een ​​sessie of communicatiestroom tussen de hosts te volgen. Dit proces zorgt ervoor dat elke host op de hoogte is van en voorbereid is op de communicatiestroom. Een TCP-gesprek vereist het opzetten van een sessie tussen de hosts in beide richtingen, zoals te zien is in de animatie.

Nadat een sessie tot stand is gebracht en de gegevensoverdracht begint, verzendt de bestemming bevestigingen naar de bron voor de ontvangen segmenten. Deze bevestigingen vormen de basis van betrouwbaarheid binnen de TCP-sessie. Wanneer de bron een bevestiging ontvangt, weet hij dat de gegevens met succes zijn afgeleverd en kan hij stoppen met het volgen van die gegevens. Als de bron geen bevestiging ontvangt binnen een vooraf bepaalde tijd, verzendt hij die gegevens opnieuw naar de bestemming.

Een deel van de extra overhead van het gebruik van TCP is het netwerkverkeer dat wordt gegenereerd door bevestigingen en hertransmissies. Het opzetten van sessies creëert overhead in de vorm van het uitwisselen van extra segmenten. Er is ook extra overhead op de individuele hosts die worden gecreëerd door de noodzaak om bij te houden welke segmenten wachten op bevestiging en door het proces van opnieuw verzenden.

7.2.1.2. TCP-serverprocessen

Applicatieprocessen draaien op servers. Een enkele server kan meerdere applicatieprocessen tegelijkertijd uitvoeren. Deze processen wachten totdat een cliënt de communicatie start met een verzoek om informatie of andere diensten.

Elk applicatieproces dat op de server wordt uitgevoerd, is geconfigureerd om een ​​poortnummer te gebruiken, ofwel standaard ofwel handmatig door een systeembeheerder. Een individuele server kan niet twee services toegewezen hebben aan hetzelfde poortnummer binnen dezelfde transportlaag services. Een host met een webservertoepassing en een bestandsoverdrachtstoepassing kunnen niet beide geconfigureerd zijn om dezelfde poort te gebruiken (bijvoorbeeld TCP-poort 8080). Een actieve servertoepassing die aan een specifieke poort is toegewezen, wordt als open beschouwd, wat betekent dat de transportlaag segmenten die aan die poort zijn geadresseerd accepteert en verwerkt. Elk inkomend clientverzoek gericht aan de juiste socket wordt geaccepteerd en de gegevens worden doorgegeven aan de servertoepassing. Er kunnen veel gelijktijdige poorten open zijn op een server, één voor elke actieve servertoepassing. Het is normaal dat een server meer dan één service tegelijkertijd aanbiedt, zoals een webserver en een FTP-server.

Een manier om de beveiliging op een server te verbeteren, is door de servertoegang te beperken tot alleen die poorten die zijn gekoppeld aan de services en toepassingen die toegankelijk moeten zijn voor geautoriseerde aanvragers.

Raadpleeg afbeeldingen 1 tot en met 5 om de typische toewijzing van bron- en doelpoorten bij TCP-client / serverbewerkingen te zien.

7.2.1.3. Totstandbrenging en beëindiging van TCP-verbinding

In sommige culturen, wanneer twee personen elkaar ontmoeten, begroeten ze elkaar vaak door elkaar de hand te schudden. Het schudden van handen wordt door beide partijen gezien als een signaal voor een vriendelijke begroeting. Verbindingen op het netwerk zijn vergelijkbaar. De eerste handshake vraagt ​​om synchronisatie. De tweede handshake bevestigt het initiële synchronisatieverzoek en synchroniseert de verbindingsparameters in de tegenovergestelde richting. Het derde handshake-segment is een bevestiging die wordt gebruikt om de bestemming te informeren dat beide partijen het erover eens zijn dat er een verbinding tot stand is gebracht.

Wanneer twee hosts communiceren via TCP, wordt er een verbinding tot stand gebracht voordat gegevens kunnen worden uitgewisseld. Nadat de communicatie is voltooid, worden de sessies gesloten en wordt de verbinding verbroken. De verbindings- en sessiemechanismen maken de betrouwbaarheidsfunctie van TCP mogelijk. Zie de afbeelding voor de stappen om een ​​TCP-verbinding tot stand te brengen en te beëindigen.

Gastheren volgen elk gegevenssegment binnen een sessie en wisselen informatie uit over welke gegevens worden ontvangen met behulp van de informatie in de TCP-header. TCP is een full-duplex protocol, waarbij elke verbinding twee eenrichtingscommunicatiestromen of sessies vertegenwoordigt. Om de verbinding tot stand te brengen, voeren de hosts een drievoudige handshake uit. Controlebits in de TCP-header geven de voortgang en status van de verbinding aan. De drievoudige handdruk:

• Stelt vast dat het bestemmingsapparaat aanwezig is op het netwerk
• Controleert of het bestemmingsapparaat een actieve service heeft en verzoeken accepteert op het bestemmingspoortnummer dat de initiërende client van plan is te gebruiken voor de sessie
• Informeert het bestemmingsapparaat dat de bronclient van plan is een communicatiesessie op dat poortnummer tot stand te brengen
  Bij TCP-verbindingen brengt de hostclient de verbinding tot stand met de server.

De drie stappen bij het tot stand brengen van een TCP-verbinding zijn:

• Stap 1. De initiërende cliënt vraagt ​​een cliënt-naar-server communicatiesessie aan met de server.
• Stap 2. De server bevestigt de client-naar-server-communicatiesessie en vraagt ​​een server-naar-client-communicatiesessie aan.
• Stap 3. De initiërende cliënt bevestigt de server-naar-cliënt communicatiesessie.

Klik in de afbeelding op de knoppen 1 tot en met 3 om de totstandbrenging van de TCP-verbinding te zien.

Bekijk de verschillende waarden die de twee hosts uitwisselen om het drievoudige handshake-proces te begrijpen. Binnen de TCP-segmentkop bevinden zich zes 1-bit velden die besturingsinformatie bevatten die wordt gebruikt om de TCP-processen te beheren. Die velden zijn:

• URG – Urgent pointer field significant
• ACK – Bevestigingsveld significant
• PSH – Push-functie
• RST – Reset de verbinding
• SYN – Synchroniseer volgnummers
• FIN – Geen gegevens meer van de afzender

De ACK- en SYN-velden zijn relevant voor onze analyse van de drieweg-handdruk.

7.2.1.4. Three-way TCP-handshake-analyse

Met behulp van de output van protocolanalysesoftware, zoals Wireshark-outputs, kunt u de werking van de TCP 3-way handshake onderzoeken:

Stap 1: De initiërende cliënt vraagt ​​een cliënt-server-communicatiesessie aan met de server.

Een TCP-client begint de drieweg-handshake door een segment te verzenden met de SYN-controlevlag (Synchronize Sequence Number), die een initiële waarde aangeeft in het volgnummerveld in de header. Deze initiële waarde voor het volgnummer, bekend als het initiële volgnummer (ISN), wordt willekeurig gekozen en wordt gebruikt om de gegevensstroom van de client naar de server voor deze sessie te volgen. Het ISN in de koptekst van elk segment wordt met één verhoogd voor elke byte aan gegevens die van de client naar de server wordt verzonden, terwijl het gegevensgesprek voortduurt.

Zoals weergegeven in de afbeelding, toont de uitvoer van een protocolanalysator de SYN-controlevlag en het relatieve volgnummer.

De SYN-controlevlag is ingesteld en het relatieve volgnummer is 0. Hoewel de protocolanalysator in de afbeelding de relatieve waarden voor de opeenvolging en bevestigingsnummers aangeeft, zijn de werkelijke waarden 32-bits binaire getallen. De afbeelding toont de vier bytes weergegeven in hexadecimaal.

Stap 2: De server bevestigt de client-to-server-communicatiesessie en vraagt ​​een server-to-client-communicatiesessie aan.

De TCP-server moet de ontvangst van het SYN-segment van de client bevestigen om de sessie van de client naar de server tot stand te brengen. Om dit te doen, stuurt de server een segment terug naar de cliënt met de bevestigingsvlag (ACK) die aangeeft dat het bevestigingsnummer significant is. Met deze vlag ingesteld in het segment, herkent de client dit als een bevestiging dat de server de SYN van de TCP-client heeft ontvangen.

De waarde van het bevestigingsnummerveld is gelijk aan het ISN plus 1. Dit brengt een sessie tot stand van de cliënt naar de server. De ACK-vlag blijft ingesteld voor het saldo van de sessie. Bedenk dat het gesprek tussen de client en de server in feite twee eenrichtingssessies is: een van de client naar de server en de andere van de server naar de client. In deze tweede stap van de drieweg-handshake moet de server het antwoord aan de client initiëren. Om deze sessie te starten, gebruikt de server de SYN-vlag op dezelfde manier als de client. Het stelt de SYN-controlevlag in de header in om een ​​sessie van de server naar de client tot stand te brengen. De SYN-vlag geeft aan dat de beginwaarde van het volgnummerveld in de koptekst staat. Deze waarde wordt gebruikt om de gegevensstroom in deze sessie van de server terug naar de client te volgen.

Zoals weergegeven in de afbeelding, laat de uitvoer van de protocolanalysator zien dat de ACK- en SYN-controlevlaggen zijn ingesteld en dat de relatieve volgorde en bevestigingsnummers worden weergegeven.

Stap 3: De initiërende cliënt erkent de server-naar-cliënt communicatiesessie.

Ten slotte antwoordt de TCP-client met een segment dat een ACK bevat die het antwoord is op de TCP SYN die door de server is verzonden. Er zijn geen gebruikersgegevens in dit segment. De waarde in het bevestigingsnummerveld bevat er één meer dan het ISN dat van de server is ontvangen. Nadat beide sessies tussen client en server tot stand zijn gebracht, wordt voor alle aanvullende segmenten die in deze communicatie worden uitgewisseld, de ACK-vlag ingesteld.

Zoals weergegeven in de afbeelding, toont de uitvoer van de protocolanalysator de ingestelde ACK-controlevlag en de relatieve volgorde en bevestigingsnummers.

Beveiliging kan worden toegevoegd aan het datanetwerk door:

• Het tot stand brengen van TCP-sessies weigeren
• Alleen sessies toestaan voor specifieke services
• Alleen verkeer toestaan als onderdeel van reeds bestaande sessies

Deze beveiligingsmaatregelen kunnen worden geïmplementeerd voor alle TCP-sessies of alleen voor geselecteerde sessies.

7.2.1.5. Analyse van beëindiging van TCP-sessies

Om een ​​verbinding te sluiten, moet de controlevlag Finish (FIN) worden ingesteld in de segmentkop. Om elke eenrichtings-TCP-sessie te beëindigen, wordt een tweerichtingshandshake gebruikt, bestaande uit een FIN-segment en een ACK-segment. Om één door TCP ondersteund gesprek te beëindigen, zijn daarom vier uitwisselingen nodig om beide sessies te beëindigen, zoals weergegeven in afbeelding 1.

Opmerking: in deze uitleg worden de termen client en server ter vereenvoudiging gebruikt als referentie, maar het beëindigingsproces kan worden gestart door twee hosts die een open sessie hebben:

• Stap 1: Wanneer de client geen gegevens meer heeft om in de stream te verzenden, verzendt deze een segment met de FIN-vlag ingesteld.
• Stap 2: De server stuurt een ACK om de ontvangst van de FIN te bevestigen om de sessie van client naar server te beëindigen.
• Stap 3: De server stuurt een FIN naar de client om de sessie van server naar client te beëindigen.
• Stap 4: De client antwoordt met een ACK om de FIN van de server te bevestigen.

Als de client geen gegevens meer heeft om over te dragen, wordt de FIN-vlag in de koptekst van een segment geplaatst. Vervolgens verzendt het serveruiteinde van de verbinding een normaal segment dat gegevens bevat met de ACK-vlag ingesteld met behulp van het bevestigingsnummer, waarmee wordt bevestigd dat alle bytes aan gegevens zijn ontvangen. Als alle segmenten zijn bevestigd, wordt de sessie gesloten.

De sessie in de andere richting wordt via hetzelfde proces afgesloten. De ontvanger geeft aan dat er geen gegevens meer zijn om te verzenden door de FIN-vlag in de header van een segment dat naar de bron is verzonden, in te stellen. Een retourbevestiging bevestigt dat alle bytes aan gegevens zijn ontvangen en dat die sessie op zijn beurt is gesloten.

Raadpleeg de figuren 2 en 3 om de FIN- en ACK-besturingsvlaggen te zien die zijn ingesteld in de segmentkop, waardoor een HTTP-sessie wordt afgesloten.

Het is ook mogelijk om de verbinding te beëindigen door een drieweg-handshake. Als de client geen gegevens meer heeft om te verzenden, stuurt deze een FIN naar de server. Als de server ook geen gegevens meer heeft om te verzenden, kan hij antwoorden met zowel de ingestelde FIN- als de ACK-vlaggen, waarbij twee stappen worden gecombineerd tot één. De klant antwoordt vervolgens met een ACK.

7.2.2. Betrouwbaarheid en datatransportbesturing

7.2.2.1. TCP-betrouwbaarheid – Geordende levering

Segmenten opnieuw rangschikken

Wanneer services gegevens verzenden via TCP, kunnen segmenten niet in de juiste volgorde op hun bestemming aankomen. Om het oorspronkelijke bericht door de ontvanger te laten begrijpen, worden de gegevens in deze segmenten opnieuw samengesteld in de oorspronkelijke volgorde. Om dit doel te bereiken, worden volgnummers toegewezen in de koptekst van elk pakket.

Tijdens het opzetten van een sessie wordt een initieel volgnummer (ISN) ingesteld. Dit ISN vertegenwoordigt de startwaarde voor de bytes voor deze sessie die naar de ontvangende applicatie wordt verzonden. Terwijl gegevens worden verzonden tijdens de sessie, wordt het volgnummer verhoogd met het aantal bytes dat is verzonden. Deze databyte-tracking zorgt ervoor dat elk segment uniek kan worden geïdentificeerd en erkend. Ontbrekende segmenten kunnen worden geïdentificeerd.

Segmentvolgnummers maken de betrouwbaarheid mogelijk door aan te geven hoe ontvangen segmenten opnieuw moeten worden samengesteld en gerangschikt, zoals weergegeven in de afbeelding.

Het ontvangende TCP-proces plaatst de gegevens van een segment in een ontvangende buffer. Segmenten worden in de juiste volgorde van volgnummers geplaatst en bij het opnieuw in elkaar zetten naar de applicatielaag doorgegeven. Alle segmenten die binnenkomen met niet-aaneengesloten volgnummers, worden bewaard voor latere verwerking. Wanneer de segmenten met de ontbrekende bytes arriveren, worden deze segmenten op volgorde verwerkt.

7.2.2.2. TCP-betrouwbaarheid – Bevestiging en venstergrootte

Ontvangst van segmenten bevestigen

Een van de functies van TCP is ervoor te zorgen dat elk segment zijn bestemming bereikt. De TCP-services op de bestemmingshost bevestigen de gegevens die deze door de brontoepassing hebben ontvangen.

Het volgnummer (SEQ) en het bevestigingsnummer (ACK) worden samen gebruikt om de ontvangst van de bytes aan gegevens in de verzonden segmenten te bevestigen. Het SEQ-nummer geeft het relatieve aantal bytes aan dat tijdens deze sessie is verzonden, inclusief de bytes in het huidige segment. TCP gebruikt het ACK-nummer dat naar de bron is teruggestuurd om de volgende byte aan te geven die de ontvanger verwacht te ontvangen. Dit wordt verwachtingsbevestiging genoemd.

De bron wordt geïnformeerd dat de bestemming alle bytes in deze datastroom heeft ontvangen tot, maar niet inclusief, de byte aangegeven door het ACK-nummer. De verzendende host wordt geacht een segment te verzenden dat een volgnummer gebruikt dat gelijk is aan het ACK-nummer.

Onthoud dat elke verbinding eigenlijk twee eenrichtingssessies is. SEQ- en ACK-nummers worden in beide richtingen uitgewisseld.

In het voorbeeld in de afbeelding stuurt de host aan de linkerkant gegevens naar de host aan de rechterkant. Het verzendt een segment met 10 bytes aan gegevens voor deze sessie en een volgnummer gelijk aan 1 in de koptekst.

De ontvangende host ontvangt het segment op laag 4 en stelt vast dat het volgnummer 1 is en dat het 10 bytes aan gegevens heeft. De host stuurt vervolgens een segment terug naar de host aan de linkerkant om de ontvangst van deze gegevens te bevestigen. In dit segment stelt de host het ACK-nummer in op 11 om aan te geven dat de volgende byte aan gegevens die hij verwacht te ontvangen in deze sessie byte-nummer 11 is. Wanneer de verzendende host deze bevestiging ontvangt, kan hij nu het volgende segment met gegevens verzenden voor deze sessie begint met byte nummer 11.

Als we naar dit voorbeeld kijken, zou het netwerk veel overhead hebben als de verzendende host moest wachten op bevestiging van ontvangst van elke 10 bytes. Om de overhead van deze bevestigingen te verminderen, kunnen meerdere gegevenssegmenten worden verzonden en bevestigd met een enkel TCP-bericht in de tegenovergestelde richting. Deze bevestiging bevat een ACK-nummer op basis van het totale aantal bytes dat tijdens de sessie is ontvangen. Als u bijvoorbeeld begint met een volgnummer van 2000, en als er 10 segmenten van elk 1.000 bytes worden ontvangen, wordt een ACK-nummer van 12001 teruggestuurd naar de bron.

De hoeveelheid gegevens die een bron kan verzenden voordat een bevestiging moet worden ontvangen, wordt de venstergrootte genoemd, een veld in de TCP-header dat het beheer van verloren gegevens en stroombesturing mogelijk maakt.

7.2.2.3. TCP-betrouwbaarheid – Verlies van gegevens en opnieuw verzenden

Omgaan met segmentverlies

Hoe goed een netwerk ook is ontworpen, er treedt af en toe gegevensverlies op; Daarom biedt TCP methoden om deze segmentverliezen te beheren. Een daarvan is een mechanisme om segmenten met niet-bevestigde gegevens opnieuw te verzenden.

Een bestemmingshostservice die TCP gebruikt, erkent gewoonlijk alleen gegevens voor aaneengesloten sequentiebytes. Als een of meer segmenten ontbreken, worden alleen de gegevens in de eerste aaneengesloten reeks bytes bevestigd. Als er bijvoorbeeld segmenten met volgnummers 1500 tot 3000 en 3400 tot 3500 werden ontvangen, zou het ACK-nummer 3001 zijn. Dit komt doordat er segmenten met de SEQ-nummers 3001 tot 3399 niet zijn ontvangen.

Wanneer TCP bij de bronhost na een vooraf bepaalde tijd geen bevestiging heeft ontvangen, keert het terug naar het laatst ontvangen ACK-nummer en verzendt het de gegevens vanaf dat punt opnieuw. Het doorgifteproces wordt niet gespecificeerd door de Request for Comments (RFC), maar wordt overgelaten aan de specifieke implementatie van TCP.

Voor een typische TCP-implementatie kan een host een segment verzenden, een kopie van het segment in een wachtrij voor opnieuw verzenden plaatsen en een timer starten. Wanneer de gegevensbevestiging is ontvangen, wordt het segment uit de wachtrij verwijderd. Als de bevestiging niet is ontvangen voordat de timer afloopt, wordt het segment opnieuw verzonden.

Klik op de knop Afspelen in de afbeelding om de animatie te zien die de heroverdracht van verloren segmenten laat zien.

Gastheren kunnen tegenwoordig ook een optionele functie gebruiken die selectieve bevestigingen (SACK’s) wordt genoemd. Als beide hosts SACK’s ondersteunen, is het voor de bestemming mogelijk om bytes in discontinue segmenten te erkennen en hoeft de host alleen de ontbrekende gegevens opnieuw te verzenden.

7.2.2.4. TCP Flow Control – Venstergrootte en bevestigingen

Flow Control

TCP biedt ook mechanismen voor stroombesturing. Flow control helpt de betrouwbaarheid van TCP-verzending te behouden door de snelheid van de gegevensstroom tussen bron en bestemming voor een bepaalde sessie aan te passen. Datatransportbesturing wordt bereikt door het aantal gegevenssegmenten dat in één keer wordt doorgestuurd te beperken en door ontvangstbevestigingen te vereisen voordat er meer worden verzonden.

Om stroombesturing te bereiken, is het eerste dat TCP bepaalt het aantal gegevenssegmenten dat het bestemmingsapparaat kan accepteren. De TCP-header bevat een 16-bits veld dat de venstergrootte wordt genoemd. Dit is het aantal bytes dat het bestemmingsapparaat van een TCP-sessie in één keer kan accepteren en verwerken. De initiële venstergrootte wordt overeengekomen tijdens het opstarten van de sessie via de drieweg-handshake tussen bron en bestemming. Eenmaal overeengekomen, moet het bronapparaat het aantal gegevenssegmenten dat naar het bestemmingsapparaat wordt verzonden, beperken op basis van de venstergrootte. Pas nadat het bronapparaat een bevestiging heeft ontvangen dat de datasegmenten zijn ontvangen, kan het doorgaan met het verzenden van meer data voor de sessie.

Tijdens de vertraging bij het ontvangen van de bevestiging, verzendt de afzender geen extra segmenten. In perioden waarin het netwerk overbelast is of de bronnen van de ontvangende host overbelast zijn, kan de vertraging toenemen. Naarmate deze vertraging langer wordt, neemt de effectieve overdrachtssnelheid van de gegevens voor deze sessie af. De vertraging van de gegevensoverdracht van elke sessie helpt resourceconflicten op het netwerk en het bestemmingsapparaat te verminderen wanneer er meerdere sessies worden uitgevoerd.

Zie de afbeelding voor een vereenvoudigde weergave van de venstergrootte en bevestigingen. In dit voorbeeld is de initiële venstergrootte voor een weergegeven TCP-sessie ingesteld op 3000 bytes. Wanneer de afzender 3000 bytes heeft verzonden, wacht hij op een bevestiging van deze bytes voordat hij meer segmenten in deze sessie verzendt. Nadat de afzender een bevestiging van de ontvanger heeft ontvangen, kan de afzender nog eens 3000 bytes verzenden.

TCP gebruikt venstergroottes om te proberen de transmissiesnelheid te beheren tot de maximale stroom die het netwerk en het bestemmingsapparaat kunnen ondersteunen, terwijl verlies en hertransmissies tot een minimum worden beperkt.

7.2.2.5. TCP Flow Control – Vermijden van congestie

Venstergrootte verkleinen

Een andere manier om de gegevensstroom te controleren, is door dynamische venstergroottes te gebruiken. Als de netwerkbronnen beperkt zijn, kan TCP de venstergrootte verkleinen zodat ontvangen segmenten vaker moeten worden bevestigd. Dit vertraagt ​​effectief de transmissiesnelheid omdat de bron vaker wacht tot de gegevens worden bevestigd.

De ontvangende host stuurt de waarde van de venstergrootte naar de verzendende host om het aantal bytes aan te geven dat deze wil ontvangen. Als de bestemming de communicatiesnelheid moet vertragen vanwege bijvoorbeeld een beperkt buffergeheugen, kan deze een kleinere waarde voor de venstergrootte naar de bron sturen als onderdeel van een bevestiging.

Zoals in de afbeelding wordt getoond, kan een ontvangende host met congestie reageren op de verzendende host met een segment dat een kleinere venstergrootte specificeert. In deze figuur was er een verlies van een van de segmenten. De ontvanger veranderde het vensterveld in de TCP-header van de terugkerende segmenten in dit gesprek van 3.000 naar 1.500, waardoor de afzender de venstergrootte verkleinde tot 1.500.

Na een periode van verzending zonder gegevensverlies of beperkte bronnen, begint de ontvanger het vensterveld te vergroten, wat de overhead op het netwerk vermindert, omdat er minder bevestigingen moeten worden verzonden. De venstergrootte blijft toenemen totdat er gegevens verloren gaan, waardoor de venstergrootte afneemt.

Deze dynamische toename en afname van de venstergrootte is een continu proces in TCP. In zeer efficiënte netwerken kunnen de venstergroottes erg groot worden omdat er geen gegevens verloren gaan. In netwerken waar de onderliggende infrastructuur onder druk staat, blijft de venstergrootte waarschijnlijk klein.

7.2.3. UDP communicatie

7.2.3.1. UDP lage overhead versus betrouwbaarheid

UDP Laag OveaUDP is een eenvoudig protocol dat de basisfuncties van de transportlaag biedt. Het heeft veel lagere overhead dan TCP, omdat het niet verbindingsgericht is en niet de geavanceerde mechanismen voor hertransmissie, sequencing en stroomregeling biedt die betrouwbaarheid bieden.

Dit betekent niet dat applicaties die UDP gebruiken altijd onbetrouwbaar zijn, noch dat UDP een inferieur protocol is. Het betekent simpelweg dat deze functies niet worden geleverd door het transportlaagprotocol en indien nodig elders moeten worden geïmplementeerd.

Hoewel de totale hoeveelheid UDP-verkeer op een normaal netwerk vaak relatief laag is, zijn de belangrijkste toepassingslaagprotocollen die UDP gebruiken:

• Domain Name System (DNS)
• Simple Network Management Protocol (SNMP)
• Dynamic Host Configuration Protocol (DHCP)
• Routing Information Protocol (RIP)
• Trivial File Transfer Protocol (TFTP)
• IP-telefonie of Voice over IP (VoIP)
• Online spelletjes

Sommige applicaties, zoals online games of VoIP, kunnen enig gegevensverlies tolereren. Als deze toepassingen TCP gebruiken, kunnen ze grote vertragingen oplopen terwijl TCP gegevensverlies detecteert en gegevens opnieuw verzendt. Deze vertragingen zouden schadelijker zijn voor de prestaties van de applicatie dan kleine gegevensverliezen. Sommige toepassingen, zoals DNS, proberen het verzoek gewoon opnieuw als er geen antwoord wordt ontvangen; daarom hebben ze geen TCP nodig om berichtbezorging te garanderen.

De lage overhead van UDP maakt het zeer wenselijk voor dergelijke toepassingen. Hoofd versus betrouwbaarheid

7.2.3.2, Opnieuw in elkaar zetten van UDP-datagrammen

Omdat UDP geen verbinding heeft, worden sessies pas tot stand gebracht als de communicatie plaatsvindt zoals bij TCP. UDP zou transactie-gebaseerd zijn; dat wil zeggen, wanneer een toepassing gegevens heeft om te verzenden, verzendt deze eenvoudigweg de gegevens.

Veel applicaties die UDP gebruiken, verzenden kleine hoeveelheden gegevens die in één segment passen. Sommige toepassingen verzenden echter grotere hoeveelheden gegevens die in meerdere segmenten moeten worden opgesplitst. De UDP-PDU wordt een datagram genoemd, hoewel de termen segment en datagram soms door elkaar worden gebruikt om een ​​transportlaag-PDU te beschrijven.

Wanneer meerdere datagrammen naar een bestemming worden gestuurd, kunnen ze verschillende paden volgen en in de verkeerde volgorde aankomen. UDP houdt volgnummers niet bij zoals TCP dat doet. UDP heeft geen manier om de datagrammen opnieuw te ordenen in hun verzendvolgorde, zoals weergegeven in de afbeelding.

Daarom stelt UDP de gegevens eenvoudig opnieuw samen in de volgorde waarin ze zijn ontvangen en stuurt deze door naar de toepassing. Als de gegevensvolgorde belangrijk is voor de toepassing, moet de toepassing de juiste volgorde identificeren en bepalen hoe de gegevens moeten worden verwerkt.

7.2.3.3. UDP-serverprocessen en -verzoeken

Net als op TCP gebaseerde applicaties krijgen op UDP gebaseerde servertoepassingen bekende of geregistreerde poortnummers toegewezen. Als deze toepassingen of processen op een server draaien, accepteren ze de gegevens die overeenkomen met het toegewezen poortnummer. Wanneer UDP een datagram ontvangt dat bestemd is voor een van deze poorten, stuurt het de toepassingsgegevens door naar de juiste toepassing op basis van het poortnummer.

7.2.3.4. UDP-clientprocessen

Net als bij TCP wordt client / server-communicatie geïnitieerd door een clienttoepassing die gegevens opvraagt ​​bij een serverproces. Het UDP-clientproces selecteert willekeurig een poortnummer uit het bereik van dynamische poortnummers en gebruikt dit als de bronpoort voor het gesprek. De bestemmingspoort is meestal het bekende of geregistreerde poortnummer dat aan het serverproces is toegewezen.

Willekeurige bronpoortnummers helpen ook bij de beveiliging. Als er een voorspelbaar patroon is voor de selectie van een bestemmingspoort, kan een indringer gemakkelijker toegang tot een client simuleren door te proberen verbinding te maken met het poortnummer dat hoogstwaarschijnlijk open is.

Omdat er geen sessie met UDP moet worden gemaakt, kan UDP, zodra de gegevens klaar zijn om te worden verzonden en de poorten zijn geïdentificeerd, de datagrammen vormen en deze doorgeven aan de netwerklaag om te worden geadresseerd en verzonden over het netwerk.

Nadat een client de bron- en bestemmingspoorten heeft geselecteerd, wordt hetzelfde paar poorten gebruikt in de koptekst van alle datagrammen die in de transactie worden gebruikt. Voor de gegevens die van de server naar de client terugkeren, worden de bron- en bestemmingspoortnummers in de datagramkop omgekeerd.

Blader door de figuren aan de rechterkant om details van UDP-clientprocessen te zien.

7.2.4. TCP of UDP

7.2.4.1. Toepassingen die TCP gebruiken

Veel toepassingen vereisen betrouwbaarheid en andere services die door TCP worden geleverd. Dit zijn applicaties die enige vertraging of prestatieverlies kunnen verdragen vanwege de overhead die wordt opgelegd door TCP.

Dit maakt TCP het meest geschikt voor applicaties die betrouwbaar transport nodig hebben en die enige vertraging kunnen verdragen. TCP is een goed voorbeeld van hoe de verschillende lagen van de TCP / IP-protocolsuite specifieke rollen hebben. Omdat het transportlaagprotocol TCP alle taken afhandelt die verband houden met het segmenteren van de datastroom in segmenten, betrouwbaarheid, stroomcontrole en herschikking van segmenten, hoeft de toepassing dit niet meer te beheren. De applicatie kan de datastroom eenvoudig naar de transportlaag sturen en de services van TCP gebruiken.

Zoals weergegeven in de afbeelding, zijn enkele voorbeelden van bekende toepassingen die TCP gebruiken:

• Hypertext Transfer Protocol (HTTP)
• Bestandsoverdrachtprotocol (FTP)
• Simple Mail Transfer Protocol (SMTP)
• Telnet

7.2.4.2. Applicaties die UDP gebruiken

Er zijn drie soorten applicaties die het meest geschikt zijn voor UDP:

Toepassingen die enig gegevensverlies kunnen verdragen, maar die weinig of geen vertraging vereisen
Applicaties met eenvoudige aanvraag- en antwoordtransacties
Unidirectionele communicatie waarbij betrouwbaarheid niet vereist is of kan worden afgehandeld door de applicatie
Veel video- en multimediatoepassingen, zoals VoIP en Internet Protocol Television (IPTV), gebruiken UDP. Deze toepassingen kunnen enig gegevensverlies tolereren met weinig of geen merkbaar effect. De betrouwbaarheidsmechanismen van TCP introduceren enige vertraging die merkbaar kan zijn in de kwaliteit van het ontvangen geluid of video.

Sommige applicaties zorgen zelf voor betrouwbaarheid. Deze applicaties hebben de services van TCP niet nodig en kunnen UDP beter gebruiken als het transportlaagprotocol. TFTP is een voorbeeld van dit type protocol. TFTP heeft zijn eigen mechanismen voor stroomcontrole, foutdetectie, bevestigingen en foutherstel. Het hoeft voor die services niet op TCP te vertrouwen.

Andere soorten applicaties die zeer geschikt zijn voor UDP zijn applicaties die eenvoudige verzoek- en antwoordtransacties gebruiken. Dit is waar een gastheer een verzoek stuurt en al dan niet een antwoord ontvangt. Een voorbeeld van dit type applicatie is DHCP.

DNS en SNMP zijn andere voorbeelden van eenvoudige verzoek- en antwoordtransacties die meestal via UDP worden uitgevoerd. Deze twee toepassingen kunnen echter ook via TCP worden uitgevoerd.