Verschillen tussen TCP- en UDP-poorten en wanneer u elke poort moet gebruiken

Wanneer we ons verdiepen in de wereld van netwerken, komt vroeg of laat de typische vraag naar boven: Wat zijn de echte verschillen tussen TCP- en UDP-poorten? en wanneer het het beste is om de ene of de andere te gebruiken. Hoewel we op het eerste gezicht alleen poortnummers zien (80, 443, 3389, 53...), zijn er daaronder twee zeer verschillende manieren om data over het internet te verplaatsen die de snelheid beïnvloeden. betrouwbaarheid en zelfs op het gebied van beveiliging.

In dit artikel zullen we het rustig uiteenzetten Hoe TCP en UDP werken, welke rol poorten spelen en welke protocollen ze gebruiken.hoe ze van invloed zijn op alledaagse dingen zoals browsen, online games spelen, videogesprekken voeren of verbinding maken via een extern bureaublad, en welke gevolgen ze hebben op het gebied van prestaties, cybersecurity en firewallconfiguratie.

TCP en UDP: twee verschillende manieren om data te transporteren

Voordat we het over havens hebben, is het belangrijk om te begrijpen dat TCP (Transmission Control Protocol) en UDP (User Datagram Protocol) zijn transportlaagprotocollen van het TCP/IP-model en definiëren de stijl van communicatie tussen bron en bestemming.

TCP is een verbindingsgericht protocolVoordat gegevens worden verzonden, wordt een logisch kanaal tussen zender en ontvanger tot stand gebracht met behulp van de bekende "drieweg-handshake" (SYN, SYN-ACK, ACK). Vervolgens worden de segmenten genummerd, wordt gecontroleerd of ze in de juiste volgorde aankomen, worden fouten gedetecteerd, worden hertransmissies aangevraagd en wordt de transmissiesnelheid aangepast aan de netwerk- en ontvangercapaciteit.

UDP is daarentegen een verbindingsloos protocolEr is geen oprichtingsfase; de ​​verzender stuurt simpelweg datagrammen naar de bestemming zonder te wachten op bevestiging of tracking. Het ordent de pakketten niet, garandeert de levering niet en past geen mechanismen voor datastroom- of congestiecontrole toe. In ruil daarvoor worden de overhead en latentie aanzienlijk verminderd.

Op basis hiervan is het grote praktische verschil dat TCP geeft prioriteit aan de betrouwbaarheid en consistentie van gegevensTerwijl UDP richt zich op snelheid en eenvoudaccepteren dat er onderweg wat informatie verloren kan gaan.

Wat is precies een TCP- of UDP-poort?

Een poort, zowel in TCP als UDP, is eenvoudigweg een getal van 0 tot 65535 dat aangeeft welke service of applicatie een gegevensstroom moet bereiken binnen een apparaat. Samen met het IP-adres vormt het de bekende "socket" (IP:poort) die applicaties gebruiken om naar verkeer te luisteren en dit te versturen.

Als we het over "TCP-poort" of "UDP-poort" hebben, hebben we het niet over verschillende nummers, maar eerder verschillende soorten transport gekoppeld aan hetzelfde havennummerZo bestaan ​​53/TCP en 53/UDP naast elkaar voor DNS, of 3389/TCP en 3389/UDP voor RDP vanaf bepaalde versies.

De nummering is georganiseerd in drie rangen met duidelijk onderscheiden toepassingen die TCP en UDP gemeen hebben:

• Bekende poorten (0-1023): gereserveerd door IANA voor standaarddiensten zoals HTTP (80/TCP), HTTPS (443/TCP), FTP (21/TCP), SSH (22/TCP), DNS (53/TCP en 53/UDP), enz.
• Geregistreerde poorten (1024-49151): toegewezen aan specifieke toepassingen, zoals 3306/TCP voor MySQL of 1194/UDP in veel OpenVPN-implementaties.
• Dynamische of privépoorten (49152-65535): worden tijdelijk gebruikt door clients voor kortdurende sessies. Ze worden direct toegewezen door het besturingssysteem.

Dankzij deze organisatie kan één enkele server Luister tegelijkertijd naar meerdere diensten (web, e-mail, database, VPN…) zonder dat de gegevensstromen door elkaar raken, omdat ze allemaal een eigen poort gebruiken.

Belangrijkste kenmerken van TCP: betrouwbaarheid boven alles

TCP is zo ontworpen dat de gegevens komen compleet, zonder fouten en in dezelfde volgorde aan als waarin ze zijn verzondenzelfs via een IP-netwerk dat per definitie 'best effort' is en geen enkele garantie biedt.

Om dit te bereiken gebruikt TCP verschillende vrij geavanceerde mechanismen:

• Segmentnummering en ACKElk segment heeft een volgnummer en de ontvanger stuurt bevestigingen (ACK's). U kunt selectieve ACK's gebruiken om meerdere segmenten tegelijk te valideren.
• Checksums: alle segmenten hebben een controlesom om gegevenscorruptie te detecteren. Als de controlesom mislukt, wordt het segment verwijderd en opnieuw aangevraagd.
• timersAls er een bepaalde tijd verstrijkt zonder dat er een ACK van een segment wordt ontvangen, gaat de verzender ervan uit dat er een verlies is en verzendt hij het segment automatisch opnieuw.
• DuplicaatfilterAls hetzelfde segment twee keer binnenkomt, detecteert TCP het duplicaat op basis van de nummering en verwijdert het.

Bovendien implementeert TCP stroom controle gebaseerd op een glijdend venster: de ontvanger kondigt aan hoeveel bytes hij in zijn buffer kan opslaan en de verzender kan deze limiet niet overschrijden totdat hij nieuwe ACK's ontvangt die het venster "schuiven".

Parallel daaraan omvat TCP een congestiecontrole met een eigen venster (congestievenster), dat probeert te voorkomen dat het netwerk verzadigd raakt. Als het pakketverlies detecteert (een indicatie voor congestie in een router), verlaagt het tempo; zodra de weg weer vrij is, verhoogt het het tempo weer op een gecontroleerde manier (langzaam begin, filevermijding en stabiele fasefasen).

met de tijd zijn verschenen steeds geavanceerdere congestie-algoritmen, zoals Tahoe en Reno in hun begindagen, Vegas, CUBIC (veel gebruikt in Linux) of BBR, ontworpen door Google om de beschikbare bandbreedte beter te benutten zonder het netwerk te overbelasten.

Een ander belangrijk voordeel is dat TCP is full-duplex en maakt multiplexing mogelijkGegevens kunnen tegelijkertijd via hetzelfde kanaal worden verzonden en ontvangen. Bovendien kan een host meerdere open sockets naar verschillende bestemmingen of services tegelijkertijd in stand houden.

TCP-header, MSS en overbelasting

Elk TCP-segment draagt ​​een header die minimaal 10 seconden in beslag neemt. 20 bytes (meer opties indien beschikbaar)Daarin vinden we:

• Haven van herkomst en bestemming (Bronpoort, Bestemmingspoort).
• Volgnummer y bevestigingsnummer (ACK).
• Vlaggen zoals SYN, ACK, FIN, RST, URG, enz.
• Grootte van het ontvangstvenstervan vitaal belang voor de stroomregeling.
• Checksums en mogelijke opties (bijvoorbeeld vensterschaling).

De maximale segmentgrootte wordt bepaald door de MSS (maximale segmentgrootte), gedefinieerd op transportniveau. Het wordt meestal als volgt berekend: MSS = MTU − IP-header − TCP-headerIn een typisch Ethernet-netwerk (MTU 1500) en minimale headers hebben we het over 1460 bytes aan bruikbare gegevens.

Hoewel deze relatief grote header de overhead verhoogt, maakt het TCP mogelijk integreer al die controlemechanismen waardoor het een hoge mate van betrouwbaarheid heeft.

TCP-verbindingen tot stand brengen en sluiten: 3-weg handshake en END

Om gegevens met TCP te kunnen uitwisselen, moet u eerst: Een logische verbinding tot stand brengen tussen client en serverHet klassieke proces is de 3-way handshake:

1. De client stuurt een segment met de vlag SYN en een initieel volgnummer.
2. De server reageert met SYN-ACK, waarbij zij hun eigen volgnummer vermelden en dat van de klant bevestigen.
3. De klant stuurt een laatste segment met ACK Vanaf daar kunnen beide partijen bidirectioneel gegevens versturen.

Deze onderhandeling van volgnummers maakt het voor een aanvaller van buitenaf moeilijk om eenvoudig een reeds bestaande TCP-verbinding vervalsenAls het zich echter in het midden (MitM) bevindt, kan het nog steeds het verkeer manipuleren.

Om de sessie af te sluiten, stuurt een van de partijen een segment met ENDDe andere kant reageert met een ACK en stuurt meestal ook een eigen FIN, die bevestigd moet worden. In sommige gevallen kan een "halfopen" verbinding blijven bestaan, waarbij de ene kant de verbinding heeft gesloten, maar de andere kant gegevens blijft verzenden.

TCP-gerelateerde aanvallen en kwetsbaarheden

Juist vanwege die verbinding, TCP is vatbaar voor SYN-flood denial-of-service-aanvallenDe aanvaller verstuurt een groot aantal valse SYN-segmenten, waardoor de server achterblijft met veel halfopen verbindingen die bronnen verbruiken.

Om deze aanvallen te beperken, worden doorgaans de volgende maatregelen toegepast: het aantal gelijktijdige verbindingen beperken (mondiaal of via IP), filteren op vertrouwde adresbereiken of gebruik technieken zoals SYN-cookies, waardoor de daadwerkelijke reservering van hulpbronnen wordt uitgesteld totdat er een betrouwbare bevestiging is verkregen.

Een andere klassieke aanval is de TCP-sequentienummervoorspellingAls een aanvaller de waarden kan raden die een legitieme host gebruikt, kan hij neppakketten injecteren die deel lijken uit te maken van de verbinding. Om dit te bereiken, luisteren ze meestal eerst naar het verkeer tussen twee vertrouwde computers, schatten ze het nummeringspatroon en voeren ze soms denial-of-service-aanvallen uit op de echte host om deze te "stilleggen" terwijl ze de sessie vervalsen.

Zodra de verbinding tot stand is gebracht, kan de aanvaller: willekeurige gegevens injecterenDit kan leiden tot sessiebeëindiging of onverwacht gedrag in de doelapplicatie. Oudere, niet-gepatchte systemen en apparaten zijn vaak de gemakkelijkste doelwitten voor deze technieken.

Wat is UDP en waarom is het zo snel?

UDP is ontworpen met een andere filosofie: datagrammen verzenden met zo min mogelijk overheadwaardoor vrijwel alle controle aan de hogere lagen wordt overgelaten. Er wordt geen voorverbinding tot stand gebracht, de volgorde ervan wordt niet gewijzigd, er wordt niet opnieuw verzonden en de transmissiesnelheid wordt niet gereguleerd.

De verzender verzendt eenvoudigweg UDP-datagrammen naar de bestemmingspoort, ervan uitgaande dat de ontvanger een open socket heeft die luistert. Als er congestie is, als de ontvanger langzamer is of als een router besluit pakketten te laten vallen, doet UDP absoluut niets om dit te corrigeren.

Het hoofdeinde is erg klein, alleen 8 bytes, met vier basisvelden:

• Haven van herkomst.
• haven van bestemming.
• Datagramlengte.
• Checksums (voor header en data).

Dankzij deze eenvoud, Het grootste deel van het pakket is gericht op payload.Dit verbetert de efficiëntie aanzienlijk, vooral bij realtimecommunicatie en in omgevingen waarin het minimaliseren van latentie een prioriteit is.

Omdat er echter geen controle is op de doorstroming of op de congestie, als een zender veel sneller is dan de ontvanger of het netwerkEr zal datagrammen verloren gaan en de verantwoordelijkheid voor het beheer van dat verlies ligt volledig bij de applicatie.

Praktische voor- en nadelen van TCP en UDP

Kortom, we kunnen zeggen dat TCP is langzamer maar zeer betrouwbaarEn UDP is sneller maar minder betrouwbaarLaten we dit eens toepassen op echte use cases.

TCP is de ideale optie wanneer de integriteit van gegevens cruciaal is: e-mail, internet browsen, bestandsoverdracht, beheer op afstand, databanken… In al deze gevallen heeft het geen zin om corrupte of onvolledige informatie te ontvangen, zelfs als het ons een paar milliseconden langer kost.

UDP blinkt uit in omgevingen waar onmiddellijkheid de prioriteit is, zoals juegos onlineVoIP, videogesprekken, live streaming, DNS, DHCP… Hier is het beter om een ​​pakketje te verliezen en de video even te laten pixeleren, in plaats van de weergave te stoppen en te wachten op een heruitzending.

Wat betreft dataverbruik, TCP heeft ook meer overhead dan UDP.De headers zijn groter en genereren extra verkeer via bevestigingen en heruitzendingen. In praktijktests met VPN Er is geconstateerd dat OpenVPN over TCP meerdere procentpunten meer data kan verbruiken dan over UDP voor dezelfde bruikbare informatie.

Wat de pure veiligheid betreft, is geen van beide protocollen ontworpen om zelfstandig te encrypteren of te authenticeren, hoewel De TCP-structuur maakt het injecteren van kwaadaardig verkeer iets moeilijker Dankzij sequentietracking en ACK's. In de praktijk vertrouwen TCP en UDP, wanneer we TLS, VPN's of versleutelde tunnels gebruiken, op hogere lagen om de content te beschermen.

Tenslotte UDP maakt multicasting en broadcasting mogelijk Dit maakt het vanzelfsprekend makkelijker om dezelfde stroom naar meerdere ontvangers tegelijk te sturen (videoconferenties, streaming naar meerdere clients, detectieprotocollen), iets wat TCP, omdat het strikt point-to-point is, niet kan.

Hoe TCP en UDP in VPN's passen

VPN-diensten vertrouwen op TCP of UDP om de versleutelde tunnel tussen client en server te creëren. In de praktijk De meeste moderne VPN-protocollen geven de voorkeur aan UDP omdat het de latentie vermindert en scenario's met matig pakketverlies beter ondersteunt.

In OpenVPN kunt u bijvoorbeeld kiezen tussen TCP- of UDP-tunnelBij gebruik van UDP wordt een groot deel van de betrouwbaarheid gedelegeerd aan de toepassingen in de tunnel (meestal weer TCP, zoals HTTP/HTTPS). Zo wordt een dubbele laag foutcontrole vermeden die alleen maar voor vertraging zou zorgen.

Dit betekent dat een OpenVPN-tunnel over UDP Er kunnen wat pakketten verloren gaan, maar als HTTP-verkeer (dat TCP gebruikt) binnen de verbinding plaatsvindt, zal het die interne TCP zijn die om hertransmissie vraagt ​​wanneer dat nodig is. Het praktische resultaat is een veilige verbinding, betrouwbaar op applicatieniveau, maar veel sneller op transportniveau.

WireGuard gaat nog een stap verder en Er wordt uitsluitend UDP gebruikt als transportmechanisme.Alle complexiteit wordt verplaatst naar de eigen cryptografische en besturingslogica, waardoor de installatietijd minimaal is en er zeer snelle roaming mogelijk is wanneer we van netwerk wisselen (bijvoorbeeld van Wi-Fi naar 4G), zonder dat we het VPN merken.

In omgevingen waar firewalls zeer restrictief zijn met UDP (sommige bedrijfsnetwerken) worden veel VPN's echter gedwongen om Overstappen op TCP om filters en proxy's te omzeilen, ten koste van een iets hogere latentie.

TCP versus UDP op het web en de evolutie naar QUIC

Vandaag de dag, HTTP en HTTPS vertrouwen bijna altijd op TCPKlassieke HTTP gebruikt normaal gesproken poort 80/TCP en HTTPS gebruikt 443/TCP, met toevoeging van TLS om de communicatie te versleutelen.

Tot HTTP/2 was het beeld helder: De hele website draaide via TCP, met zijn betrouwbaarheidsvoordelen, maar brengt ook bepaalde problemen met zich mee, zoals latentie en headerblokkering in verbindingen met een hoog verlies.

HTTP/3 verschijnt op het toneel QUIC, een transportprotocol gebouwd op UDP Het integreert functies van TCP (congestiecontrole, foutcorrectie, stroomvolgorde) en TLS (versleuteling vereist). QUIC maakt het mogelijk om meerdere onafhankelijke stromen over dezelfde verbinding te multiplexen, waardoor de impact van pakketverlies op een bepaald deel van de communicatie wordt verminderd.

Dankzij dat, HTTP/3 over QUIC biedt doorgaans snellere laadtijden, vooral in mobiele netwerken of verbindingen met veel jitter. Bovendien worden door het gebruik van UDP bepaalde knelpunten in bestaande infrastructuur die uitsluitend voor TCP is ontworpen, beter overwonnen.

TCP- en UDP-poorten in real-world services: voorbeelden en tabel

De combinatie van transporttype en poortnummer definieert welk applicatielaagprotocol wordt gebruiktEnkele veelvoorkomende voorbeelden:

• 80 / TCPHTTP (onversleuteld web).
• 443 / TCP: HTTPS (web versleuteld met TLS).
• 21/TCP en 20/TCPFTP (besturing en gegevens).
• 22 / TCP: SSH en SFTP.
• 25/TCP, 587/TCPSMTP voor het verzenden van e-mail.
• 110/TCP, 995/TCP: POP3 en POP3S.
• 143/TCP, 993/TCP: IMAP en IMAPS.
• 53/UDP en 53/TCP: DNS (snelle query's via UDP, zoneoverdrachten via TCP).
• 67/UDP en 68/UDPDHCP-client/server.
• 123/UDPNTP, tijdsynchronisatie.
• 161/UDP:SNMP.
• 445 / TCPMicrosoft SMB/CIFS voor het delen van bestanden.
• 554/TCP/UDP: RTSP voor streamcontrole.
• 631/TCP/UDP: IPP (netwerkprinten).

De volledige lijst van bekende en geregistreerde havens is zeer uitgebreid, maar dient om aan te tonen dat TCP domineert meestal in kritische en transactiegerichte toepassingenTerwijl UDP-regels in detectie-, streaming- of lichtgewicht besturingsprotocollen..

RDP: TCP, UDP of beide?

El Extern bureaubladprotocol (RDP) Met de service van Microsoft kunt u verbinding maken met een andere computer alsof u achter het scherm zit. Intern wordt een gecomprimeerde bureaubladafbeelding van de externe host naar de client verzonden en worden toetsenbord- en muisinvoer in de tegenovergestelde richting ontvangen.

Traditioneel heeft RDP gebruik gemaakt van de poort 3389/TCP als primair transport, waarbij de betrouwbaarheid van TCP wordt benut om ervoor te zorgen dat elke schermupdate, klik en besturingspakket correct en in de juiste volgorde aankomt.

Sinds RDP 8.0 kan het protocol ook 3389/UDP om de prestaties te optimaliserenNormaal gesproken zal de client eerst proberen een UDP-kanaal in te stellen (vanwege de lagere latentie en hogere bandbreedte) en als dit vanwege netwerkbeperkingen niet mogelijk is, zal hij terugvallen op het klassieke TCP-kanaal.

Deze hybride aanpak maakt RDP mogelijk het grootste deel van de grafische gegevens via UDP verzendenWaar het verlies van een paar frames nauwelijks merkbaar is, en TCP indien nodig kan worden gereserveerd voor strikt kritieke informatie. In netwerken met hoge latentie of signaalverlies kan de prestatieverbetering aanzienlijk zijn.

Hoe TCP- en UDP-poorten voor RDP op Windows openen

Om een ​​RDP-sessie van buitenaf te laten werken, moet de firewall van de host binnenkomend verkeer op poort 3389 toestaanZowel TCP als UDP zijn nodig als we willen profiteren van moderne optimalisaties; als er problemen zijn, is het raadzaam om de netwerkbeleid dat RDP blokkeert.

En Windows, basisopstelling van de Firewall van Windows Defender bestaande uit:

1. Enter Configuratiescherm > Systeem en beveiliging > Windows Defender Firewall en open de geavanceerde instellingen.
2. Maak een nieuwe inkomende regel van het type "Poort", selecteer TCP en geef 3389 op als de specifieke lokale poort.
3. Selecteer 'Verbinding toestaan', pas dit toe op de benodigde profielen (domein, privé, openbaar) en geef een beschrijvende naam, bijvoorbeeld 'RDP TCP 3389'.
4. Herhaal het proces om UDP op dezelfde poort 3389, met een andere naam, bijvoorbeeld "RDP UDP 3389".
5. Controleer of beide regels zijn ingeschakeld en test de verbinding vanaf een externe client.

Op het gebied van veiligheid is het, naast het openen van poorten, van cruciaal belang Gebruik sterke wachtwoorden, Activeren Netwerkniveau-authenticatie (NLA) om ervoor te zorgen dat alleen gevalideerde gebruikers zich kunnen aanmelden bij de grafische sessie, om te beperken welke accounts toestemming hebben voor externe toegang en om het systeem altijd up-to-date te houden om kwetsbaarheden in de RDP-service te voorkomen.

TCP-poorten: beveiliging, risico's en best practices

Elke TCP-poort die aan het internet wordt blootgesteld, wordt een mogelijke aanvalsvectorAanvallers scannen automatisch volledige IP-reeksen op zoek naar open poorten (met behulp van hulpmiddelen als Nmap). Zodra ze zijn gedetecteerd, testen ze op bekende kwetsbaarheden of brute-force-aanvallen.

Zeer gevoelige diensten zoals SSH (22/TCP), RDP (3389/TCP), SMB (445/TCP) of databases Dit zijn prioritaire doelen, omdat een storing daar directe toegang tot het interne netwerk of kritieke gegevens kan opleveren.

Om het aanvalsoppervlak te verkleinen, is het raadzaam het principe van minimale privileges in havens: open alleen de strikt noodzakelijke items, beperk de toegang via IP of VPN indien mogelijk en sluit of filter alles wat niet wordt gebruikt.

Het is ook een goed idee het netwerk in zones segmenteren (gebruikers-LAN, server-DMZ, beheernetwerk, enz.) en gebruik interne firewallregels om kritieke services te isoleren. Op deze manier wordt het, zelfs als een aanvaller één machine hackt, moeilijker om zich lateraal naar andere gevoelige systemen te verplaatsen.

Het gebruik van monitoring- en loggingtools Hiermee kunnen afwijkende patronen in poorten worden gedetecteerd (scans, massaal mislukte pogingen, verbindingen uit onbekende landen) en kunnen waarschuwingen worden geactiveerd voordat het incident escaleert.

Ten slotte is het raadzaam om: periodieke havenaudits Gebruik externe en interne scanners en documenteer welke service op elke scanner luistert. Dit helpt bij het identificeren van verouderde applicaties, vergeten services of gevaarlijke standaardinstellingen die uitgeschakeld moeten worden.

Prestatieverschillen tussen TCP- en UDP-poorten

Als we het verkeer dat via TCP-poorten en UDP gaat vergelijken, meten we eigenlijk alleen maar: het gedrag van beide transportprotocollen onder verschillende netwerkomstandigheden.

TCP heeft, met zijn fout- en congestiecontrole, de neiging om vertragen wanneer het verlies of verzadiging detecteertprioriteit geven aan het correct aankomen van alles in plaats van aan het snel aankomen. In overbelaste netwerken of met een hoge latentie kan dit leiden tot langere laadtijden of downloads minder wendbaar.

UDP laat zich niet tegenhouden door congestie: Als het pad overbelast is, laten routers simpelweg pakketten vallenOmdat er geen automatische doorgifte is, verloopt de communicatie vloeiend, maar er zijn wel informatielacunes die de applicatie zelf moet beheren (bijvoorbeeld via buffering of eigen foutcorrectie).

Bij testen met VPN's en grote geografische afstanden is waargenomen dat OpenVPN via UDP is meestal aanzienlijk sneller dan via TCPHet verschil wordt groter naarmate de netwerkomstandigheden verslechteren. Dit komt zowel door de kleinere header als door het ontbreken van continue ACK's en hertransmissies.

Er is ook een impact op de dataverbruikDoor zwaardere headers en extra controleberichten gebruikt TCP meer bandbreedte voor elke bruikbare MB die wordt verzonden. Op mobiele verbindingen met gigabytelimieten kan dit aan het einde van de maand een verschil maken.

Andere transportprotocollen dan TCP en UDP

Hoewel in de praktijk bijna al het internet met TCP en UDP als basisEr zijn andere transportprotocollen die voor specifieke gebruiksgevallen zijn ontworpen.

Een van hen is SCTP (Stream Control Transmission Protocol)Het combineert de kenmerken van TCP en UDP: het biedt betrouwbare en geordende transmissie, maar staat meerdere onafhankelijke stromen binnen dezelfde verbinding toe. Het wordt veel gebruikt in geavanceerde telecommunicatie en VoIP-signalering, waar de latentie wordt verminderd in vergelijking met traditioneel TCP.

Een andere is DCCP (Datagram Congestion Control Protocol), die de offline stijl van UDP behoudt, maar geïntegreerde congestiecontroleontworpen voor realtime multimedia waarbij het verliezen van pakketten beter is dan het introduceren van te veel latentie.

Is ook RDP (Betrouwbaar Data Protocol), met een focus op militaire en wetenschappelijke omgevingen, en, zoals reeds vermeld, QUIC, dat afhankelijk is van UDP, maar betrouwbaarheid, multiplexing en encryptie in één laag implementeert en de basis vormt van HTTP/3.

Ondanks de technische voordelen is de realiteit dat De massale acceptatie van nieuwe protocollen is ingewikkeld: het volledige ecosysteem van routers, firewalls, besturingssystemen Applicaties zijn geoptimaliseerd voor TCP en UDP, en het veranderen van die basis vereist inspanning, kosten en risico's. Bovendien blokkeren veel firewalls standaard zeldzame protocollen, terwijl TCP 80/443-verkeer en een aanzienlijke hoeveelheid UDP vrijwel altijd worden toegestaan.

Goed begrijpen Hoe TCP- en UDP-poorten werken, welke services afhankelijk zijn van elk van deze poorten en welke gevolgen ze hebben voor de prestaties en beveiliging. Hierdoor kunnen we verstandige beslissingen nemen: wanneer het de moeite waard is om snelheid op te offeren om betrouwbaarheid te vergroten, wanneer het voordelig is om UDP te gebruiken om de latentie te verminderen, welke poorten we moeten openen of sluiten in een firewall en welke parameters we moeten aanpassen in een VPN of server om ervoor te zorgen dat ons netwerk soepel functioneert en zo min mogelijk wordt gehinderd door aanvallen.