Protocollen voor gegevensoverdracht TCP en UDP. Transportprotocollen - UDP

UDP-TOEPASSINGEN

UDP ondersteunt ook Trivial File Transfer Protocol (TFTP), Simple Network Management Protocol (SNMP) en Routing Information Protocol (RIP), naast vele andere toepassingen.
TFTP (typisch bestandsoverdrachtprotocol). Het wordt voornamelijk gebruikt voor het kopiëren en installeren van een besturingssysteem op een computer vanaf een bestandsserver,

TFTP. TFTP is een kleinere toepassing dan File Transfer Protocol (FTP). Over het algemeen wordt TFTP op netwerken gebruikt voor eenvoudige bestandsoverdracht. TFTP beschikt over een eigen mechanisme voor foutcontrole en volgnummering en daarom vereist dit protocol geen aanvullende services op de transportlaag.

SNMP (Simple Network Management Protocol) bewaakt en beheert netwerken en daaraan gekoppelde apparaten, en verzamelt informatie over de netwerkprestaties. SNMP verzendt PDU-berichten waarmee netwerkbeheersoftware apparaten op het netwerk kan controleren.

RIP (Routing Information Protocol) is een intern routeringsprotocol, wat betekent dat het binnen een organisatie wordt gebruikt, maar niet op internet.

TCP-TOEPASSINGEN

TCP ondersteunt ook FTP, Telnet en Simple Mail Transfer Protocol (SMTP), naast vele andere toepassingen.

FTP (File Transfer Protocol) is een volledig functionele toepassing die wordt gebruikt om bestanden te kopiëren met behulp van een actieve clienttoepassing op de ene computer die is gekoppeld aan een FTP-servertoepassing op een andere externe computer. Met deze applicatie kunnen bestanden worden ontvangen en verzonden.

Met Telnet kunt u terminalsessies tot stand brengen met een extern apparaat, meestal een UNIX-host, router of switch. Dit geeft de netwerkbeheerder de mogelijkheid om een ​​netwerkapparaat te beheren alsof het zich in de buurt bevindt, waarbij de seriële poort van de computer wordt gebruikt voor bediening. Het nut van Telnet is beperkt tot systemen die op tekens gebaseerde opdrachtsyntaxis gebruiken. Telnet ondersteunt geen controle over de grafische omgeving van de gebruiker.

SMTP (Simple Mail Transfer Protocol) is een protocol voor e-mailoverdracht voor internet. Het ondersteunt de overdracht van e-mailberichten tussen e-mailclients en e-mailservers.

BEKENDE HAVENS
Bekende poorten worden toegewezen door IANA en variëren van 1023 en lager. Ze worden toegewezen aan applicaties die de kern vormen van internet.

GEREGISTREERDE HAVENS
Geregistreerde poorten worden gecatalogiseerd door de IANA en variëren van 1024 tot 49151. Deze poorten worden gebruikt door gelicentieerde applicaties zoals Lotus Mail.

DYNAMISCH TOEGEWEZEN HAVENS
Dynamisch toegewezen poorten zijn genummerd van 49152 tot 65535. De nummers voor deze poorten worden dynamisch toegewezen voor de duur van een specifieke sessie.

TCP- en UDP-protocollen

TCP-transmissiecontroleprotocol

Verbindingsgerichte communicatie kan gebruik maken van betrouwbare communicatie, waarbij het Layer 4-protocol bevestigingen verzendt wanneer gegevens zijn ontvangen en om hertransmissie vraagt ​​als gegevens niet zijn ontvangen of beschadigd zijn. Het TCP-protocol maakt gebruik van precies zo'n betrouwbare communicatie. TCP wordt gebruikt in toepassingsprotocollen zoals HTTP, FTP, SMTP en Telnet.

Het TCP-protocol vereist dat er een verbinding wordt geopend voordat een bericht kan worden verzonden. De serverapplicatie moet doen wat er wordt aangeroepen passief geopend om een ​​verbinding tot stand te brengen met een bekend poortnummer, en in plaats van de oproep naar het netwerk te sturen, wacht de server op binnenkomende verzoeken. De clienttoepassing moet dit doen actief geopend door de serverapplicatie een synchronisatievolgnummer (SYN) te sturen dat de verbinding identificeert. De clienttoepassing kan een dynamisch poortnummer gebruiken als lokale poort.

De server moet een bevestiging (ACK) naar de client sturen, samen met een servervolgnummer (SYN). De client antwoordt op zijn beurt met ACK en de verbinding wordt tot stand gebracht.

Hierna kan het proces van het verzenden en ontvangen van berichten beginnen. Wanneer een bericht wordt ontvangen, wordt als antwoord altijd een ACK-bericht verzonden. Als de time-out verstrijkt voordat de afzender de ACK ontvangt, wordt het bericht in de wachtrij geplaatst voor hertransmissie.

De TCP-headervelden worden weergegeven in de volgende tabel:

TCP-header
Veld Lengte Beschrijving
Bronpoort 2 bytes Bronpoortnummer
Haven van bestemming 2 bytes Poortnummer van bestemming
Serienummer 4 bytes Het volgnummer wordt gegenereerd door de bron en gebruikt door de bestemming om pakketten opnieuw te ordenen om het originele bericht te creëren en een bevestiging naar de bron te sturen.
Bevestigingsnummer 4 bytes Als de ACK-bit van het Control-veld is ingesteld, bevat dit veld het volgende verwachte volgnummer.
Gegevenscompensatie 4 bits Informatie over het begin van een datapakket.
Reserveren 6 bits Gereserveerd voor toekomstig gebruik.
Controle 6 bits De besturingsbits bevatten vlaggen die aangeven of de bevestigingsvelden (ACK), urgentievelden (URG), of de verbinding moet worden gereset (RST), of het synchronisatieserienummer (SYN) is verzonden, enz. geldig zijn.
Venstergrootte 2 bytes Dit veld specificeert de grootte van de ontvangstbuffer. Via bevestigingsberichten kan de ontvanger de afzender informeren over de maximale hoeveelheid gegevens die hij kan verzenden.
Controlesom 2 bytes Koptekst en gegevenscontrolesom; het bepaalt of het pakket beschadigd is.
Urgentie-indicator 2 bytes In dit veld ontvangt het doelapparaat informatie over de urgentie van de gegevens.
Opties variabel Optionele waarden die indien nodig worden opgegeven.
Toevoeging variabel Er worden voldoende nullen aan het opvulveld toegevoegd, zodat de header eindigt op een 32-bits grens.

TCP is een complex en tijdrovend protocol vanwege het mechanisme voor het tot stand brengen van verbindingen, maar het zorgt voor een gegarandeerde pakketaflevering zonder dat we deze functionaliteit in het applicatieprotocol hoeven op te nemen.

Het TCP-protocol heeft ingebouwde betrouwbare leveringsmogelijkheden. Indien het bericht niet correct wordt verzonden, ontvangen wij een foutmelding. Het TCP-protocol is gedefinieerd in RFC 793.

UDP - Gebruikersdatagramprotocol

In tegenstelling tot TCP is UDP een zeer snel protocol omdat het het minimale mechanisme definieert dat nodig is voor gegevensoverdracht. Natuurlijk heeft het enkele nadelen. Berichten komen in willekeurige volgorde aan, en het bericht dat het eerst wordt verzonden, wordt mogelijk als laatste ontvangen. De bezorging van UDP-berichten is helemaal niet gegarandeerd, het bericht kan verloren gaan en er kunnen twee exemplaren van hetzelfde bericht worden ontvangen. Het laatste geval doet zich voor als er twee verschillende routes worden gebruikt om berichten naar één adres te sturen.

UDP vereist geen opening van een verbinding en gegevens kunnen worden verzonden zodra deze zijn voorbereid. UDP verzendt geen bevestigingsberichten, waardoor gegevens kunnen worden ontvangen of verloren kunnen gaan. Als bij het gebruik van UDP een betrouwbare gegevensoverdracht vereist is, moet deze in een protocol op een hoger niveau worden geïmplementeerd.

Dus wat zijn de voordelen van UDP, waarom zou zo’n onbetrouwbaar protocol nodig zijn? Om de reden voor het gebruik van UDP te begrijpen, moet u onderscheid maken tussen unidirectionele transmissie, broadcast-transmissie en multicast-transmissie.

Unicast-bericht verzonden van het ene knooppunt naar slechts één ander knooppunt. Dit wordt ook wel point-to-point-communicatie genoemd. Het TCP-protocol ondersteunt alleen unidirectionele communicatie. Als een server met meerdere clients moet communiceren via TCP, moet elke client een verbinding tot stand brengen, omdat berichten alleen naar afzonderlijke hosts kunnen worden verzonden.

Uitzending betekent dat het bericht naar alle knooppunten in het netwerk wordt verzonden. Groepsdistributie (multicast) is een tussenmechanisme: berichten worden naar geselecteerde groepen knooppunten verzonden.

UDP kan worden gebruikt voor unidirectionele communicatie wanneer snelle transmissie vereist is, zoals voor het leveren van multimediagegevens, maar de belangrijkste voordelen van UDP hebben betrekking op uitzending en multicasting.

Op het niveau van de datalink en het netwerkprotocol TCP/IP-pakket, die betrekking hebben op het basismechanisme voor het overbrengen van gegevensblokken tussen landen en tussen netwerken, vormen de basis TCP/IP. Ze gebruiken de protocolstack, maar worden niet rechtstreeks gebruikt in applicaties die op het protocol draaien TCP/IP. In dit artikel bekijken we twee protocollen die door applicaties worden gebruikt: User Datagram Protocol (UDP) en Transmission Control Protocol (TCP).

Gebruikersdatagramprotocol
User Datagram Protocol is een heel eenvoudig protocol. Leuk vinden IP, het is een betrouwbaar verbindingsloos protocol. U hoeft geen verbinding met de host tot stand te brengen om er gegevens mee uit te wisselen via UDP, en er is geen mechanisme om de verzonden gegevens te garanderen.
Blok gegevens verzonden met behulp van UDP een datagram genoemd. UDP voegt vier 16-bit headervelden (8 bytes) toe aan de verzonden gegevens. Deze velden zijn: lengteveld, controlesomveld en bron- en bestemmingspoortnummer. "Poort" vertegenwoordigt in deze context de software van de poort, niet de hardwarepoort.
Het poortnummerconcept is voor beide hetzelfde UDP en TCP. Poortnummers bepalen welke protocolmodule gegevens doorstuurt (of ontvangt). De meeste protocollen hebben standaardpoorten die hiervoor vaak worden gebruikt. Het Telnet-protocol gebruikt bijvoorbeeld doorgaans poort 23. Simple Mail Transfer Protocol (SMTP) gebruikt poort 25. Door standaardpoortnummers te gebruiken, kunnen clients met de server communiceren zonder eerst te beslissen welke poort ze moeten gebruiken.
Poort- en protocolnummer in het headerveld IP dupliceren elkaar tot op zekere hoogte, hoewel de protocolvelden niet beschikbaar zijn voor protocollen op een hoger niveau. IP gebruikt het protocolveld om te bepalen waar gegevens naartoe moeten worden verzonden UDP of TCP modules. UDP of TCP gebruik het poortnummer om te bepalen welk applicatielaagprotocol gegevens moet ontvangen.
Ondanks, UDP is niet waterdicht, het is nog steeds een geschikte keuze voor veel toepassingen. Het wordt gebruikt door realtime toepassingen zoals het streamen van audio en video, waarbij als gegevens verloren gaan, het beter is om het zonder te doen dan om het opnieuw te verzenden. Het wordt ook gebruikt door protocollen zoals Simple Network Management Protocol (SNMP).
Uitzending
UDP Geschikt voor het uitzenden van informatie omdat er geen open verbindingsverbinding voor nodig is. De doelen van een uitgezonden bericht worden bepaald door de afzender, naar het opgegeven bestemmings-IP-adres. UDP datagrammen met een bestemmings-IP-adres zijn allemaal binair (255.255.255.255) en worden door elke host op het lokale netwerk ontvangen. Let op het woord lokaal: datagrammen met een dergelijk adres worden door de router op internet niet geaccepteerd.
Transmissies kunnen naar specifieke netwerken worden gestuurd. UDP-datagrammen vanaf de host- en subnetdelen van het als binaire IP-adres ingestelde IP-adres worden uitgezonden naar alle hosts op alle subnetten van het netwerk die overeenkomen met het zuivere deel van het IP-adres. Als alleen de ontvangende kant (met andere woorden: alle bits die nul zijn in het subnetmasker) is ingesteld op binair, dan is de uitzending beperkt tot alle hosts in het subnet die overeenkomen met de rest van het adres.
Multicast wordt gebruikt om gegevens te verzenden tussen een groep hosts die de wens hebben geuit om deze te ontvangen. Multicast UDP het datagram heeft een bestemmingsadres waarin de eerste vier bits 1110 zijn, wat adressen oplevert in het bereik 224.xxx tot 239.xxx. De resterende bits van het adres worden gebruikt om de multicastgroep aan te duiden. Het lijkt meer op een radio- of tv-zender. Zo wordt bijvoorbeeld 224.0.1.1 gebruikt voor het NTP-protocol. Als TCP/IP toepassingen een multicast-bericht willen ontvangen, moeten ze lid worden van de juiste multicast-groep, wat gebeurt door het adres van de groep door te geven aan de protocolstack.
Omroepen filteren in wezen de uitzending. Multicaster houdt geen rekening met individuele berichten voor elke host die lid wordt van de groep. In plaats daarvan worden berichten uitgezonden en beslissen de stuurprogramma's op elke host of ze deze negeren of de inhoud doorgeven aan de protocolstack.
Dit betekent dat multicast-berichten over het hele internet moeten worden uitgezonden, omdat de multicaster niet weet welke hosts de berichten willen ontvangen. Gelukkig is dit niet nodig. IP gebruikt een protocol genaamd Internet Group Management Protocol (IGMP) om routers te vertellen welke hosts multicast-groepsberichten willen ontvangen, zodat berichten alleen worden verzonden waar ze nodig zijn.
Transmissiecontroleprotocol
Transmission Control Protocol is een transportlaagprotocol en wordt gebruikt door de meeste internettoepassingen zoals Telnet, FTP en HTTP. Dit is een verbindingsgericht protocol. Dit betekent dat twee computers (de ene een client en de andere een server) een verbinding tussen hen tot stand moeten brengen voordat gegevens tussen hen kunnen worden overgedragen.
TCP biedt betrouwbaarheid. Applicatie die gebruikt TCP weet dat hij gegevens verzendt die hij aan de andere kant heeft ontvangen, en dat hij deze correct heeft ontvangen. TCP gebruikt controlesommen op zowel headers als gegevens. Bij het ontvangen van gegevens, TCP stuurt een bevestiging terug naar de afzender. Als de afzender binnen een bepaalde periode geen bevestiging ontvangt, worden de gegevens opnieuw verzonden.
TCP omvat mechanismen om ervoor te zorgen dat gegevens in omgekeerde volgorde aankomen in de volgorde waarin ze zijn verzonden. Het implementeert ook stroomcontrole, zodat de afzender de ontvanger van de gegevens niet kan overweldigen.
TCP verzendt gegevens met behulp van IP in blokken die segmenten worden genoemd. De lengte van het segment wordt bepaald door het protocol. Naast de IP-header bestaat elk segment uit 20 bytes header. Rubriek TCP begint met een 16-bits bron- en bestemmingspoortnummerveld. Leuk vinden UDP Deze velden definiëren het applicatieniveau dat gericht is op het ontvangen van gegevens. Het IP-adres en het poortnummer identificeren samen op unieke wijze de services die worden uitgevoerd voor de host en het paar dat bekend staat als de socket.
Het volgende in de header is een 32-bits volgnummer. Dit getal specificeert de positie in de datastroom die de eerste byte aan data in het segment moet innemen. Serienummer TCP zorgt ervoor dat de datastroom in de juiste volgorde wordt gehouden, hoewel segmenten uit een reeks kunnen worden afgeleid.
Het volgende veld is een 32-bits veld dat wordt gebruikt om aan de afzender door te geven dat de gegevens correct zijn ontvangen. Als ACK een vlag is, wat meestal het geval is, bevat dit veld de positie van de volgende byte aan gegevens die de zender van het segment verwacht te ontvangen.
IN TCP het is niet nodig dat elk datasegment wordt herkend. De waarde in het bevestigingsveld wordt geïnterpreteerd als ‘alle gegevens tot nu toe OK ontvangen’. Dit bespaart bandbreedte wanneer alle gegevens in één richting worden gerouteerd, waardoor de behoefte aan segmentherkenning wordt verminderd. Als gegevens gelijktijdig in beide richtingen worden verzonden, zoals bij full-duplexcommunicatie, zijn aan postzegels geen kosten verbonden, aangezien een gegevenssegment in de ene richting een bevestiging kan bevatten voor gegevens die in de andere richting zijn verzonden.
Het volgende in de header is een 16-bits veld met de headerlengte en vlaggen. TCP headers kunnen extra velden bevatten, dus de lengte kan variëren van 20 tot 60 bytes. Vlaggen: URG, ACK (die we al noemden), PSH, RST, SYN en FIN. We zullen later naar enkele andere vlaggen kijken.
De header bevat een veld met de naam venstergrootte, dat het aantal bytes aangeeft dat de ontvanger kan ontvangen. Er is ook een 16-bits controlesom die zowel de header als de gegevens omvat. Ten slotte (vóór aanvullende gegevens) is er een veld dat de “urgentie-indicator” wordt genoemd. Wanneer de URG-vlag is ingesteld, wordt deze waarde geïnterpreteerd als een volgnummerverschuiving. Het identificeert het begin van gegevens in een stroom die dringend moet worden verwerkt. Deze gegevens worden vaak "buiten de groep"-gegevens genoemd. Een voorbeeld van het gebruik ervan is wanneer de gebruiker op de pauzetoets drukt om het verlaten van het programma te onderbreken tijdens een Telnet-sessie.

UDP maakt gebruik van een eenvoudig transmissiemodel, zonder impliciete handshakes, om de betrouwbaarheid, ordening en integriteit van gegevens te garanderen. UDP biedt dus een onbetrouwbare service en datagrammen kunnen in de verkeerde volgorde aankomen, worden gedupliceerd of spoorloos verdwijnen. UDP impliceert dat foutcontrole en -correctie niet nodig zijn of door de applicatie moeten worden uitgevoerd. Tijdgevoelige toepassingen maken vaak gebruik van UDP omdat het de voorkeur verdient pakketten te laten vallen in plaats van te wachten op vertraagde pakketten, wat misschien niet mogelijk is in realtimesystemen. Als het nodig is om fouten op de netwerkinterfacelaag te corrigeren, kan de applicatie TCP of SCTP gebruiken die voor dit doel is ontworpen.

De aard van UDP als staatloos protocol is ook nuttig voor servers die reageren op kleine verzoeken van een groot aantal clients, zoals DNS en streaming mediatoepassingen zoals IPTV, Voice over IP, IP-tunnelingprotocollen en veel online games.

Servicepoorten

UDP biedt geen garanties voor de bezorging van berichten aan het protocol op de bovenste laag en slaat de status van verzonden berichten niet op. Om deze reden wordt UDP ook wel het Unreliable Datagram Protocol genoemd.

Voordat de controlesom wordt berekend, wordt het UDP-bericht aan het einde opgevuld met nul bits tot een lengte die een veelvoud is van 16 bits (de pseudo-header en extra nulbits worden niet met het bericht verzonden). Controlesomveld in de UDP-header tijdens controlesomberekening verstuurd berichten worden als nul geaccepteerd.

Om de controlesom te berekenen, worden de pseudo-header en het UDP-bericht in woorden gesplitst (1 woord = 2 bytes (octetten) = 16 bits). Vervolgens wordt het bitsgewijze complement van de som van alle woorden met bitsgewijze complement berekend. Het resultaat wordt naar het overeenkomstige veld in de UDP-header geschreven.

Er is een controlesomwaarde van nul gereserveerd, wat betekent dat het datagram geen controlesom heeft. Als de berekende controlesom gelijk is aan nul, wordt het veld gevuld met binaire eenheden.

Wanneer een bericht wordt ontvangen, berekent de ontvanger de controlesom opnieuw (rekening houdend met het controlesomveld), en als het resultaat een binair getal van zestien eenheden is (dat wil zeggen 0xffff), wordt aangenomen dat de controlesom is geconvergeerd. Als de som niet klopt (de gegevens zijn beschadigd tijdens de verzending), wordt het datagram vernietigd.

Voorbeeld van een controlesomberekening

Laten we bijvoorbeeld de controlesom van verschillende 16-bits woorden berekenen: 0x398a, 0xf802, 0x14b2, 0xc281. Vind hun som met bitsgewijze complement.
0x398a + 0xf802 = 0x1318c → 0x318d
0x318d + 0x14b2 = 0x0463f → 0x463f
0x463f + 0xc281 = 0x108c0 → 0x08c1
Nu vinden we het bitsgewijze complement van het resulterende resultaat:

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e of anders - 0xffff − 0x08c1 = 0xf73e . Dit is de gewenste controlesom.

Bij het berekenen van de checksum wordt opnieuw een pseudo-header gebruikt, die een echte IPv6-header simuleert:

Beetjes 0 – 7 8 – 15 16 – 23 24 – 31
0 Bron adres
32
64
96
128 Adres van de ontvanger
160
192
224
256 UDP-lengte
288 Nullen Volgende titel
320 Bronpoort Bestemmingshaven
352 Lengte Controlesom
384+
Gegevens

Het bronadres is hetzelfde als in de IPv6-header. Ontvangeradres - eindontvanger; als het IPv6-pakket geen Routing-header bevat, dan is dit het bestemmingsadres van de IPv6-header, anders is dit op het startknooppunt het adres van het laatste element van de routing-header, en op het ontvangende knooppunt, het bestemmingsadres uit de IPv6-header. De Next Header-waarde is gelijk aan de protocolwaarde - 17 voor UDP. UDP-lengte - de lengte van de UDP-header en gegevens.

Betrouwbaarheid en oplossingen voor overbelastingsproblemen

Vanwege het gebrek aan betrouwbaarheid moeten UDP-applicaties voorbereid zijn op enig verlies, fouten en duplicatie. Sommigen van hen (bijvoorbeeld TFTP) kunnen optioneel elementaire betrouwbaarheidsmechanismen op applicatieniveau toevoegen.

Maar vaker wel dan niet worden dergelijke mechanismen niet gebruikt door UDP-applicaties en interfereren ze er zelfs mee. Streaming media, realtime multiplayer-gaming en VoIP zijn voorbeelden van toepassingen die vaak gebruik maken van het UDP-protocol. In deze specifieke toepassingen is pakketverlies meestal geen groot probleem. Als de applicatie een hoge mate van betrouwbaarheid vereist, kan een ander protocol (TCP) of wiscodes worden gebruikt.

Een groter potentieel probleem is dat, in tegenstelling tot TCP, op UDP gebaseerde applicaties niet noodzakelijkerwijs over goede mechanismen voor congestiecontrole en -vermijding beschikken. Congestiegevoelige UDP-applicaties die een aanzienlijk deel van de beschikbare bandbreedte verbruiken, kunnen de internetstabiliteit in gevaar brengen.

Netwerkmechanismen zijn ontworpen om de potentiële effecten van congestie tijdens ongecontroleerde, snelle belastingen te minimaliseren. Netwerkelementen zoals routers die gebruik maken van pakketwachtrijen en drop-technieken zijn vaak de enige beschikbare tools om overmatig UDP-verkeer te vertragen. DCCP (Datagram Congestion Control Protocol) is ontworpen als een gedeeltelijke oplossing voor dit potentiële probleem door mechanismen aan de eindhost toe te voegen om congestie voor snelle UDP-streams zoals streaming media te monitoren.

Toepassingen

Talrijke belangrijke internettoepassingen maken gebruik van UDP, waaronder DNS (waarbij verzoeken snel moeten zijn en uit slechts één verzoek moeten bestaan, gevolgd door één antwoordpakket), Simple Network Management Protocol (SNMP), Routing Information Protocol (RIP), Dynamic Host Configuration (DHCP) .

Spraak- en videoverkeer wordt doorgaans uitgevoerd via UDP. Protocollen voor live video- en audiostreaming zijn ontworpen om willekeurige pakketverliezen op te vangen, zodat de kwaliteit slechts licht verslechtert in plaats van grote vertragingen te veroorzaken wanneer de verloren pakketten opnieuw worden verzonden. Omdat zowel TCP als UDP op hetzelfde netwerk werken, hebben veel bedrijven gemerkt dat de recente toename van het UDP-verkeer als gevolg van deze real-time applicaties de prestaties van TCP-applicaties zoals database- of boekhoudsystemen belemmert. Omdat zowel zakelijke als realtime applicaties belangrijk zijn voor bedrijven, wordt het ontwikkelen van kwaliteitsoplossingen voor problemen door sommigen als een topprioriteit gezien.

Vergelijking van UDP en TCP

TCP is een verbindingsgericht protocol, wat betekent dat er een "handshake" nodig is om een ​​verbinding tussen twee hosts tot stand te brengen. Zodra de verbinding tot stand is gebracht, kunnen gebruikers gegevens in beide richtingen verzenden.

  • Betrouwbaarheid- TCP beheert berichtbevestiging, hertransmissie en time-out. Er worden talloze pogingen ondernomen om de boodschap over te brengen. Als het onderweg verloren gaat, zal de server het verloren onderdeel opnieuw opvragen. Met TCP zijn er geen ontbrekende gegevens of (in het geval van meerdere time-outs) verbroken verbindingen.
  • Ordelijkheid- als er twee berichten achter elkaar worden verzonden, zal het eerste bericht als eerste de ontvangende applicatie bereiken. Als stukjes gegevens in de verkeerde volgorde aankomen, stuurt TCP de gegevens die niet in de juiste volgorde staan ​​naar een buffer totdat alle gegevens kunnen worden geordend en naar de applicatie kunnen worden verzonden.
  • Zwaarte- TCP heeft drie pakketten nodig om een ​​socketverbinding tot stand te brengen voordat gegevens worden verzonden. TCP bewaakt de betrouwbaarheid en congestie.
  • Inrijgen- de gegevens worden gelezen als een stroom bytes, er worden geen speciale aanduidingen voor berichtgrenzen of segmenten verzonden.

UDP is een eenvoudiger, op berichten gebaseerd, verbindingsloos protocol. Dit soort protocollen brengt geen speciale verbinding tot stand tussen twee hosts. Communicatie wordt bereikt door informatie in één richting door te geven van een bron naar een ontvanger, zonder de gereedheid of staat van de ontvanger te controleren. Het belangrijkste voordeel van UDP ten opzichte van TCP ligt echter in Voice over Internet Protocol (VoIP)-toepassingen, waarbij elke handdruk een goede spraakcommunicatie zou verhinderen. Bij VoIP wordt van eindgebruikers verwacht dat zij in realtime de noodzakelijke bevestiging van de berichtontvangst geven.

  • Onbetrouwbaar- wanneer een bericht wordt verzonden, is het niet bekend of het de bestemming zal bereiken - het kan onderweg verloren gaan. Er bestaan ​​geen concepten als bevestiging, hertransmissie, time-out.
  • Stoornis- als twee berichten naar dezelfde ontvanger worden verzonden, kan de volgorde waarin ze het doel bereiken niet worden voorspeld.
  • Lichtheid- geen bestelling van berichten, geen volgen van verbindingen, enz. Het is een kleine transportlaag ontworpen in IP.
  • Datagrammen- pakketten worden afzonderlijk verzonden en alleen gecontroleerd op integriteit als ze aankomen. Pakketten hebben bepaalde grenzen die na ontvangst worden gerespecteerd, wat betekent dat een leesoperatie op de ontvangende socket het bericht zal produceren zoals het oorspronkelijk werd verzonden.
  • Geen overbelastingscontrole- UDP zelf vermijdt geen congestie. Het is mogelijk dat toepassingen met een hoge bandbreedte de congestie doen afnemen, tenzij zij controles op toepassingsniveau implementeren.

RFC-koppelingen

  • RFC 768 – Gebruikersdatagramprotocol
  • RFC 2460 – Internetprotocolspecificatie versie 6 (IPv6)
  • RFC 2675 - IPv6-jumbogrammen
  • RFC 4113 – Managementinformatiebasis voor de UDP
  • RFC 5405 – Unicast UDP-gebruiksrichtlijnen voor applicatieontwerpers

Zie ook

Koppelingen

  • Kurose, JF; Ross, KW (2010). Computernetwerken: een top-downbenadering (5e ed.). Boston, MA: Pearson Onderwijs. ISBN 978-0-13-136548-3.
  • Forouzan, BA (2000). TCP/IP: Protocolsuite, 1e druk. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
  • [e-mailadres beveiligd]. "UDP-protocoloverzicht". IPv6.com. Ontvangen op 17 augustus 2011.
  • Clark, MP (2003). Datanetwerken IP en internet, 1e druk. West Sussex, Engeland: John Wiley & Sons Ltd.
  • Postel, J. (augustus 1980). RFC 768: Gebruikersdatagramprotocol. Taskforce internettechniek. Opgehaald van http://tools.ietf.org/html/rfc768
  • Deering S. & Hinden R. (december 1998). RFC 2460: Internet Protocol, versie 6 (IPv6) specificatie. Taskforce internettechniek. Opgehaald van http://tools.ietf.org/html/rfc2460
  • ‘De impact van UDP op datatoepassingen’. netwerkperformancedaily.com. Ontvangen op 17 augustus 2011.
  • D. Komer. Internetwerken via TCP/IP. Hoofdstuk 11. UDP-protocol.

UDP (User Datagram Protocol) is een transportprotocol voor verbindingsloze gegevensoverdracht via IP-netwerken. Het is een van de eenvoudigste transportlaagprotocollen van het OSI-model. Het IP-ID is 0x11.

UDP wordt doorgaans gebruikt in toepassingen zoals videostreaming en computerspellen, waar pakketverlies acceptabel is en het opnieuw proberen van een verzoek moeilijk of ongerechtvaardigd is, of in challenge-response-toepassingen (zoals DNS-query's) waarbij het tot stand brengen van een verbinding meer bronnen vergt dan opnieuw verzenden. In feite komen UDP-functies neer op multiplex- en demultiplexbewerkingen, evenals eenvoudige foutcontrole in gegevens. Bij gebruik van UDP communiceert de applicatie dus vrijwel rechtstreeks met het IP-netwerklaagprotocol.

UDP ontvangt berichten van de applicatielaag, voegt bron- en bestemmingspoortvelden toe voor demultiplexing door de ontvanger, evenals twee andere speciale velden, en geeft het resulterende segment door aan de netwerklaag. De netwerklaag verpakt het segment in een datagram en stuurt dit “indien mogelijk” door naar de bestemmingshost. Als laatstgenoemde het segment succesvol ontvangt, stuurt UDP de segmentgegevens door naar het gewenste proces met behulp van het bestemmingspoortnummerveld. Daarom wordt gezegd dat UDP verbindingsloze gegevensoverdracht mogelijk maakt.

Een voorbeeld van een applicatielaagprotocol dat gebruikmaakt van UDP-protocolservices is DNS. Wanneer een DNS-applicatie een query genereert, wordt er een DNS-bericht gemaakt en doorgegeven aan het UDP-protocol.


Vergelijking van UDP- en TCP-protocollen.

Als een toepassing bevestiging van de bezorging van berichten vereist, wordt het protocol gebruikt TCP. TCP verdeelt het bericht in kleinere stukjes, segmenten genoemd. Deze segmenten worden opeenvolgend genummerd en doorgegeven aan het IP-protocol, dat vervolgens de pakketten samenstelt. TCP houdt het aantal segmenten bij dat door een bepaalde toepassing naar een bepaalde host wordt verzonden. Als de afzender binnen een bepaalde periode geen bevestiging ontvangt, behandelt TCP deze segmenten als zwevend en verzendt deze opnieuw. Alleen het verloren gedeelte van het bericht wordt opnieuw verzonden, niet het hele bericht.

Het TCP-protocol op het ontvangende knooppunt is verantwoordelijk voor het opnieuw samenstellen van de berichtsegmenten en het verzenden ervan naar de juiste toepassing.

FTP en HTTP zijn voorbeelden van toepassingen die TCP gebruiken om gegevens te leveren.

Protocol UDP voert een niet-gegarandeerde gegevenslevering uit en vraagt ​​geen bevestiging van de ontvanger. UDP is het voorkeursprotocol voor het streamen van audio, video en voice over Internet Protocol (VoIP). Het bevestigen van de bezorging vertraagt ​​het gegevensoverdrachtproces alleen maar en een nieuwe bezorging is niet aan te raden. Een voorbeeld van het gebruik van het UDP-protocol is internetradio.


ARP-protocol. Sollicitatie.

ARP(Engels) Adresresolutieprotocol- adresbepalingsprotocol) is een protocol op laag niveau dat wordt gebruikt in computernetwerken en is ontworpen om het linklaagadres te bepalen op basis van een bekend netwerklaagadres. Dit protocol is het meest wijdverspreid geworden vanwege de alomtegenwoordigheid van IP-netwerken die bovenop Ethernet zijn gebouwd, aangezien in bijna 100% van de gevallen ARP met deze combinatie wordt gebruikt. De protocolbeschrijving werd in november 1982 gepubliceerd in RFC 826. ARP is ontworpen voor het verzenden van IP-pakketten via een Ethernet-segment. Tegelijkertijd kan het algemene principe dat voor ARP wordt voorgesteld ook voor andere soorten netwerken worden gebruikt.

Er bestaan ​​de volgende typen ARP-berichten: ARP-verzoek en ARP-antwoord. Het verzendende systeem gebruikt een ARP-verzoek om het fysieke adres van het ontvangende systeem op te vragen. Het antwoord (het fysieke adres van de bestemmingshost) komt in de vorm van een ARP-antwoord.

Voordat een netwerklaagpakket over een Ethernet-segment wordt verzonden, controleert de netwerkstack de ARP-cache om te zien of de vereiste informatie over de bestemmingshost daarin al is geregistreerd. Als er geen dergelijke vermelding in de ARP-cache aanwezig is, wordt een ARP-broadcastverzoek gedaan. Deze vraag naar apparaten op het netwerk heeft de volgende betekenis: "Kent iemand het fysieke adres van het apparaat met het volgende IP-adres?" Wanneer de ontvanger met dit IP-adres dit pakket ontvangt, zal hij moeten antwoorden: “Ja, dit is mijn IP-adres. Mijn fysieke adres is: …” De afzender zal dan zijn ARP-cache bijwerken en de informatie naar de ontvanger kunnen verzenden.

ARP-cachegegevens kunnen statisch of dynamisch zijn. Het hierboven gegeven voorbeeld beschrijft een dynamische cache-invoer. U kunt ook statische vermeldingen in de ARP-tabel aanmaken.

ARP is oorspronkelijk niet alleen ontwikkeld voor het IP-protocol, maar wordt nu vooral gebruikt om IP- en MAC-adressen in kaart te brengen.

Werkingsprincipe

Een knooppunt dat een IP-adres aan een lokaal adres moet toewijzen, genereert een ARP-verzoek, voegt dit in een link-layer protocolframe in, geeft een bekend IP-adres aan, en zendt het verzoek uit.

Alle hosts op het lokale netwerk ontvangen een ARP-verzoek en vergelijken het daar opgegeven IP-adres met hun eigen adres.

Als ze overeenkomen, genereert het knooppunt een ARP-antwoord, waarin het zijn IP-adres en zijn lokale adres aangeeft en het al gericht verzendt, aangezien de afzender in het ARP-verzoek zijn lokale adres aangeeft.