TCP ja UDP portide erinevused ja millal neid kasutada

Võrgustike maailma süvenedes tekib varem või hiljem tüüpiline küsimus: Millised on TCP ja UDP portide tegelikud erinevused? ja millal on kõige parem ühte või teist kasutada. Kuigi esmapilgul näeme ainult pordi numbreid (80, 443, 3389, 53…), on allpool kaks väga erinevat viisi andmete edastamiseks interneti kaudu, mis mõjutavad kiirust. usaldusväärsust ja isegi turvateenistuses.

Selles artiklis käsitleme seda rahulikult. Kuidas TCP ja UDP toimivad, millist rolli mängivad pordid ja milliseid protokolle kumbki kasutab.kuidas need mõjutavad igapäevaseid asju, nagu sirvimine, võrgumängude mängimine, videokõnede tegemine või kaugtöölaua kaudu ühenduse loomine, ja millist mõju need avaldavad jõudlusele, küberjulgeolek ja tulemüüri konfiguratsioon.

TCP ja UDP: kaks erinevat viisi andmete edastamiseks

Enne sadamate arutamist on oluline mõista, et TCP (Transmission Control Protocol) ja UDP (User Datagram Protocol) on transpordikihi protokollid. TCP/IP mudeli osad ja need määratlevad allika ja sihtkoha vahelise suhtluse stiili.

TCP on ühendusepõhine protokollEnne andmete saatmist loob see saatja ja vastuvõtja vahel loogilise kanali, kasutades tuntud "kolmepoolset käepigistust" (SYN, SYN-ACK, ACK). Seejärel nummerdab see segmendid, tagab nende saabumise õiges järjekorras, tuvastab vead, taotleb uuesti saatmist ja kohandab edastuskiirust vastavalt võrgu ja vastuvõtja võimsusele.

UDP seevastu on ühenduseta protokollPuudub asutamisfaas; saatja lihtsalt saadab datagrammid sihtkohta ilma kinnitust või jälgimist ootamata. See ei telli pakette, ei garanteeri kohaletoimetamist ega rakenda voo- ega ummikute kontrollimehhanisme. Vastutasuks vähendab see oluliselt üldkulusid ja latentsust.

Selle põhjal on suur praktiline erinevus selles, et TCP seab esikohale andmete usaldusväärsuse ja järjepidevuseKuigi UDP keskendub kiirusele ja lihtsuseleleppides sellega, et osa infost võib teel kaduma minna.

Mis täpselt on TCP või UDP port?

Port, nii TCP-s kui ka UDP-s, on lihtsalt arv vahemikus 0 kuni 65535, mis määrab, millise teenuse või rakenduseni andmevoog peaks jõudma seadme sees. Koos IP-aadressiga moodustab see kuulsa "socketi" (IP:port), mida rakendused kasutavad liikluse kuulamiseks ja saatmiseks.

Kui me räägime "TCP-pordist" või "UDP-pordist", siis me ei räägi erinevatest numbritest, vaid pigem sama pordinumbriga seotud erinevat tüüpi transportNäiteks alates teatud versioonidest eksisteerivad DNS-i puhul samaaegselt 53/TCP ja 53/UDP või RDP puhul 3389/TCP ja 3389/UDP.

Numeratsioon on korraldatud järgmiselt: kolm auastet TCP ja UDP ühised selgelt eristatud kasutusviisid:

• Tuntud pordid (0-1023): IANA poolt reserveeritud standardteenustele nagu HTTP (80/TCP), HTTPS (443/TCP), FTP (21/TCP), SSH (22/TCP), DNS (53/TCP ja 53/UDP) jne.
• Registreeritud pordid (1024-49151): määratud kindlatele rakendustele, näiteks 3306/TCP MySQL-i jaoks või 1194/UDP paljudes OpenVPN-i juurutustes.
• Dünaamilised või privaatpordid (49152-65535): klientide poolt ajutiselt kasutatavad lühiajaliste seansside jaoks; operatsioonisüsteem määrab need lennult.

Tänu sellele korraldusele saab üks server Kuula korraga mitmes teenuses (veeb, e-post, andmebaas, VPN…) ilma andmevoogude segaminiminekuta, kuna igaüks neist hõivab oma pordi.

TCP põhijooned: usaldusväärsus ennekõike

TCP on loodud nii, et andmed saabuvad terviklikena, vigadeta ja samas järjekorras, nagu need saadetiisegi IP-võrgu kaudu, mis on oma olemuselt "parim võimalik" ega garanteeri midagi.

Selle saavutamiseks kasutab TCP mitu üsna keerukat mehhanismi:

• Segmentide nummerdamine ja ACKIgal segmendil on järjekorranumber ja vastuvõtja saadab kinnituse (ACK). Valikuliste ACK-de abil saab korraga mitu segmenti valideerida.
• KontrollimiselKõik segmendid kannavad kontrollsummat andmete rikkumise tuvastamiseks; kui see ebaõnnestub, siis segment visatakse ära ja seda taotletakse uuesti.
• TaimeridKui teatud aja möödudes ei ole segmendilt ACK-i saadud, eeldab saatja kadumist ja saadab selle automaatselt uuesti.
• DuplikaatfilterKui sama segment saabub kaks korda, tuvastab TCP duplikaadi numeratsiooni järgi ja loobub sellest.

Lisaks rakendab TCP voolu juhtimine libiseva akna põhimõttel: vastuvõtja teatab, mitu baitu ta saab oma puhvris salvestada ja saatja ei saa seda piiri ületada enne, kui ta saab uusi ACK-sid, mis akent "libistavad".

Paralleelselt sisaldab TCP a ummikute kontroll oma aknaga (ummikuaknaga), mis püüab vältida võrgu ülekoormust. Kui see tuvastab pakettide kadumise (mis viitab võrgu ummikule ruuter), vähendab tempot; kui tee on vaba, suurendab see seda kontrollitult uuesti (aeglane start, ummikute vältimine ja stabiilse faasi faasid).

koos aeg on ilmunud üha arenenumad ummikute algoritmid, nagu Tahoe ja Reno oma algusaegadel, Vegas, CUBIC (väga kasutatav Linux) või BBR, mille on kujundanud Google et saadaolevat ribalaiust paremini ära kasutada ilma võrku üle koormamata.

Teine oluline eelis on see TCP on täisdupleks ja võimaldab multipleksimistAndmeid saab sama kanali kaudu samaaegselt saata ja vastu võtta ning host saab samaaegselt hoida avatud mitut sokliühendust erinevate sihtkohtade või teenustega.

TCP päis, MSS ja ülekoormus

Igal TCP segmendil on päis, mis vähemalt hõivab 20 baiti (rohkem valikuid, kui on saadaval)Selles leiame:

• Päritolu- ja sihtsadam (Lähtesadam, sihtsadam).
• Järjekorranumber y kinnitusnumber (ACK).
• Lipud näiteks SYN, ACK, FIN, RST, URG jne.
• Vastuvõtuakna suurusvoolu reguleerimiseks ülioluline.
• Kontrollimisel ja võimalikud valikud (näiteks akna skaleerimine).

Segmendi maksimaalse suuruse määrab MSS (maksimaalne segmendi suurus), mis on määratletud transpordi tasandil. Tavaliselt arvutatakse see järgmiselt: MSS = MTU − IP päis − TCP päisTüüpilises Etherneti võrgus (MTU 1500) ja minimaalsete päistega räägime umbes 1460 baidist kasulikest andmetest.

Kuigi see suhteliselt suur päis suurendab üldkulu, võimaldab see TCP-l integreerida kõik need kontrollmehhanismid mis annab sellele kõrge usaldusväärsuse taseme.

TCP-ühenduste loomine ja sulgemine: 3-poolne käepigistus ja END

TCP-ga andmevahetuse alustamiseks peate kõigepealt Looge loogiline ühendus kliendi ja serveri vahelKlassikaline protsess on kolmepoolne käepigistus:

1. Klient saadab segmendi, millel on lipp SYN ja esialgne järjekorranumber.
2. Server vastab SYN-ACK, märkides ära oma järjekorranumbri ja kinnitades kliendi oma.
3. Klient saadab viimase segmendi koos ACK Sealt edasi saavad mõlemad pooled hakata andmeid kahesuunaliselt saatma.

See järjekorranumbrite läbirääkimine raskendab ründajal väljastpoolt juba loodud TCP-ühenduse hõlbus võltsimineKui see aga asub keskel (MitM), saab see ikkagi liiklust manipuleerida.

Seansi lõpetamiseks saadab üks osapooltest segmendi, millel on FINTeine pool vastab ACK-ga ja saadab tavaliselt ka oma FIN-i, mis tuleb kinnitada. Mõnel juhul võib jääda "poolavatud" ühendus, kus üks pool on ühenduse sulgenud, kuid teine ​​jätkab andmete saatmist.

TCP-ga seotud rünnakud ja haavatavused

Just selle seose tõttu, TCP on vastuvõtlik SYN-i üleujutuse teenusetõkestamise rünnakuteleRündaja saadab suure hulga võltsitud SYN-segmente, jättes serverile palju poolikuid ühendusi, mis tarbivad ressursse.

Selliste rünnakute leevendamiseks rakendatakse tavaliselt järgmisi meetmeid: piira samaaegsete ühenduste arvu (globaalne või IP-aadressi järgi), filtreeri usaldusväärsete aadressivahemike järgi või kasutada selliseid tehnikaid nagu SYN-küpsised, mis lükkavad ressursside tegelikku reserveerimist edasi kuni usaldusväärse kinnituse saamiseni.

Teine klassikaline rünnak on TCP järjekorranumbri ennustamineKui ründaja suudab ära arvata, milliseid väärtusi seaduslik host kasutab, saab ta sisestada võltspakette, mis näivad olevat osa ühendusest. Selle saavutamiseks kuulavad nad tavaliselt kõigepealt pealt kahe usaldusväärse arvuti vahelist liiklust, hindavad numbrimustrit ja mõnikord käivitavad tegeliku hosti vastu teenusetõkestamise rünnakuid, et seda "vaigistada", samal ajal kui nad selle seanssi võltsivad.

Kui ühendus on loodud, saab ründaja sisestage suvalisi andmeidSee võib viia seansi lõppemiseni või ootamatu käitumiseni sihtrakenduses. Vanemad, parandamata süsteemid ja seadmed on nende tehnikate jaoks sageli lihtsaimad sihtmärgid.

Mis on UDP ja miks see nii kiire on?

UDP loodi teistsuguse filosoofiaga: saata datagramme võimalikult väikese üldkulugajättes peaaegu kogu kontrolli ülemistele kihtidele. See ei loo eelühendust, ümberjärjesta, edasta uuesti ega reguleeri edastuskiirust.

Saatja saadab lihtsalt UDP datagramme. sihtporti, eeldades, et vastuvõtjal on avatud kuulamispesa. Kui esineb ummikuid, kui vastuvõtja on aeglasem või kui ruuter otsustab pakette ära jätta, ei tee UDP selle parandamiseks mitte midagi.

Selle peatsiplaat on väga väike, ainult 8 baiti, nelja põhiväljaga:

• Päritolu sadam.
• Sihtkoha sadam.
• Datagrammi pikkus.
• Kontrollimisel (päise ja andmete jaoks).

Tänu sellele lihtsusele, Suurem osa paketist on pühendatud kasulikule koormusele.See parandab oluliselt tõhusust, eriti reaalajas suhtluses ja keskkondades, kus latentsuse minimeerimine on prioriteet.

Kuna aga puudub vooluhulga või ummikute kontroll, kui saatja on palju kiirem kui vastuvõtja või võrkDatagrammid hakkavad kaduma ja vastutus selle kadumise eest langeb täielikult rakendusele.

TCP ja UDP praktilised eelised ja puudused

Lühidalt öeldes võiksime öelda, et TCP on aeglasem, aga väga usaldusväärne, Ja UDP on kiirem, aga vähem usaldusväärneTaandagem see reaalsete kasutusjuhtudeni.

TCP on ideaalne valik, kui andmete terviklikkus on kriitilise tähtsusega: e-post, veebibrauser, failiedastus, kaughaldus, andmebaasid... Kõigil neil juhtudel pole mõtet saada rikutud või mittetäielikku teavet, isegi kui see võtab meil paar millisekundit kauem aega.

UDP särab keskkondades, kus esmatähtis on kohesus, näiteks juegos InternetisVoIP, videokõned, otseülekanne, DNS, DHCP... Siin on eelistatav kaotada pakett ja lasta videol hetkeks pikseldada, selle asemel, et peatada taasesitus ja oodata uuesti edastamist.

Andmete tarbimise osas TCP-l on ka rohkem üldkulusid kui UDP-l.Selle päised on suuremad ja genereerivad kinnituste ja uuesti saatmise kaudu lisaliiklust. Reaalsetes testides koos VPN On täheldatud, et OpenVPN suudab TCP kaudu sama kasuliku teabe saamiseks tarbida mitu protsendipunkti rohkem andmeid kui UDP kaudu.

Puht turvalisuse mõttes pole kumbki protokoll loodud iseseisvaks krüpteerimiseks ega autentimiseks, kuigi TCP struktuur muudab pahatahtliku liikluse süstimise veidi keerulisemaks. Tänu järjestuse jälgimisele ja ACK-idele. Praktikas tuginevad nii TCP kui ka UDP TLS-i, VPN-ide või krüpteeritud tunnelite kasutamisel sisu kaitsmiseks kõrgematele kihtidele.

Lõpuks UDP võimaldab multisaadet ja ringhäälingut loomulikult, mis lihtsustab sama voo saatmist korraga paljudele vastuvõtjatele (videokonverentsid, voogedastus mitmele kliendile, avastusprotokollid), mida TCP, olles rangelt punkt-punkti protokoll, teha ei saa.

Kuidas TCP ja UDP VPN-idesse sobivad

VPN-teenused tuginevad kliendi ja serveri vahelise krüpteeritud tunneli loomiseks TCP-le või UDP-le. Praktikas Enamik tänapäevaseid VPN-protokolle eelistab UDP-d sest see vähendab latentsust ja toetab paremini mõõduka pakettakao stsenaariume.

Näiteks OpenVPN-is saate valida järgmiste vahel: TCP või UDP tunnelUDP kasutamisel delegeeritakse suur osa usaldusväärsusest tunnelis asuvatele rakendustele (tavaliselt jälle TCP, näiteks HTTP/HTTPS), vältides topeltveakontrolli kihti, mis ainult lisaks viivitust.

See tähendab seda OpenVPN tunnel UDP kaudu See võib küll mõned paketid kaotada, aga kui HTTP-liiklus (mis kasutab TCP-d) liigub seespool, siis on just see sisemine TCP see, mis vajadusel uuesti edastamist taotleb. Praktiline tulemus on turvaline ühendus, mis on rakenduse tasandil usaldusväärne, aga transpordi tasandil palju kiirem.

WireGuard läheb sammu edasi ja See kasutab transpordivahendina ainult UDP-d.Kogu keerukus on viidud oma krüptograafilisse ja juhtimisloogikasse, saavutades minimaalse seadistusaja ja väga kiire rändluse võrgu vahetamisel (näiteks WiFi-lt 4G-le) ilma, et VPN oleks märgatav.

Keskkondades, kus tulemüürid on UDP suhtes väga piiravad (mõned ettevõttevõrgud), on paljud VPN-id sunnitud Filtrite ja puhverserverite möödahiilimiseks TCP-protokolli langemine, latentsuse veidi suurenemise hinnaga.

TCP vs UDP veebis ja areng QUIC suunas

Tänapäeval HTTP ja HTTPS tuginevad peaaegu alati TCP-leKlassikaline HTTP kasutab tavaliselt porti 80/TCP ja HTTPS kasutab porti 443/TCP, lisades side krüptimiseks TLS-i.

Kuni HTTP/2-ni oli pilt selge: Kogu veebisait töötas TCP protokolli kaudu, millel on küll usaldusväärsuse eelised, kuid mis aga toovad endaga kaasa teatud latentsuse ja päise blokeerimise probleemid suure kadudega ühendustes.

HTTP/3 siseneb sündmuskohale QUIC, UDP-le loodud transpordiprotokoll See integreerib TCP funktsioone (ülekoormuse kontroll, veaparandus, voogude järjestamine) ja TLS-i (krüpteerimine on vajalik). QUIC võimaldab mitme sõltumatu voo multipleksimist sama ühenduse kaudu, vähendades pakettide kadumise mõju kommunikatsiooni mis tahes osale.

Tänu sellele HTTP/3 üle QUIC pakub tavaliselt kiiremat laadimisaega, eriti mobiilsidevõrgud või suure jitteriga ühendusi. Lisaks aitab UDP kasutamine paremini ületada teatud kitsaskohti ainult TCP jaoks loodud pärandinfrastruktuuris.

TCP ja UDP pordid reaalsetes teenustes: näited ja tabel

Transpordi tüübi ja pordi numbri kombinatsioon määrab millist rakenduskihi protokolli kasutatakseMõned väga levinud näited:

• 80 / TCPHTTP (krüpteerimata veeb).
• 443 / TCPHTTPS (veebi krüptimine TLS-iga).
• 21/TCP ja 20/TCPFTP (kontroll ja andmed).
• 22 / TCPSSH ja SFTP.
• 25/TCP, 587/TCPSMTP e-kirjade saatmiseks.
• 110/TCP, 995/TCPPOP3 ja POP3S.
• 143/TCP, 993/TCPIMAP ja IMAPS.
• 53/UDP ja 53/TCPDNS (kiired päringud UDP kaudu, tsoonide edastus TCP kaudu).
• 67/UDP ja 68/UDPDHCP klient/server.
• 123/UDPNTP, aja sünkroniseerimine.
• 161/UDPSNMP.
• 445 / TCPMicrosoft SMB/CIFS failide jagamiseks.
• 554/TCP/UDPRTSP voogedastuse juhtimiseks.
• 631/TCP/UDPIPP (võrguprintimine).

Tuntud ja registreeritud sadamate täielik nimekiri on väga ulatuslik, kuid see näitab, et TCP domineerib tavaliselt kriitilistes ja tehingutele orienteeritud rakendustesKuigi UDP reeglid avastus-, voogesitus- või kergekaalulistes juhtimisprotokollides..

RDP: TCP, UDP või mõlemad?

El Kaugtöölaua protokoll (RDP) Microsofti teenus võimaldab teil luua ühenduse teise arvutiga nii, nagu istuksite selle ekraani ees. Sisemiselt saadab see kaugmasinast kliendile tihendatud töölaua pildi ja võtab klaviatuuri ja hiire sisendi vastu vastassuunas.

Traditsiooniliselt on RDP kasutanud port 3389/TCP peamise transpordivahendina, kasutades ära TCP usaldusväärsust, et tagada iga ekraanivärskenduse, klõpsu ja juhtpaketi korrektne ja õiges järjekorras saabumine.

Alates RDP 8.0-st saab protokolli kasutada ka 3389/UDP jõudluse optimeerimiseksTavaliselt proovib klient kõigepealt luua UDP-kanali (selle madalama latentsuse ja suurema ribalaiuse tõttu) ning kui see pole võrgupiirangute tõttu võimalik, pöördub tagasi klassikalise TCP-kanali poole.

See hübriidlähenemine võimaldab RDP-l Saatke suurem osa graafilistest andmetest UDP kaudukus mõne kaadri kadu on vaevumärgatav ja TCP-d saab vajadusel reserveerida rangelt kriitilise teabe jaoks. Suure latentsuse või signaali kadumisega võrkudes võib jõudluse paranemine olla väga märkimisväärne.

Kuidas avada Windowsi RDP jaoks TCP- ja UDP-porte

Väljastpoolt tuleva RDP-seansi toimimiseks peab hosti tulemüür toimima lubada sissetulevat liiklust pordil 3389Nii TCP kui ka UDP on vajalikud, kui tahame ära kasutada tänapäevaseid optimeerimisi; probleemide korral on soovitatav üle vaadata võrgupoliitikad, mis blokeerivad RDP-d.

En Windowson põhiseadistus tulemüürilt Windows Defender koosneb:

1. Sisene Juhtpaneel > Süsteem ja turvalisus > Windows Defenderi tulemüür ja avage täpsemad seaded.
2. Looma uus sissetuleva pordi reegel tüübiga "Port", valige TCP ja määrake kohalikuks pordiks 3389.
3. Valige "Luba ühendus", rakendage vajalikele profiilidele (domeen, privaatne, avalik) ja andke kirjeldav nimi, näiteks "RDP TCP 3389".
4. Korda protsessi, et UDP samal pordil 3389, teise nimega, näiteks "RDP UDP 3389".
5. Veenduge, et mõlemad reeglid on lubatud ja testige ühendust kaugkliendiga.

Turvalisuse seisukohast on lisaks sadamate avamisele oluline ka Kasutage tugevaid paroole, Aktiveeri Võrgu tasemel autentimine (NLA) tagamaks, et graafilisse seanssi saavad sisse logida ainult valideeritud kasutajad, piirata kaugjuurdepääsu luba omavate kontode arvu ja hoida süsteem alati ajakohasena, et vältida RDP-teenuse haavatavusi.

TCP-pordid: turvalisus, riskid ja parimad tavad

Iga internetiga avatud TCP-port muutub võimalik rünnakuvektorRündajad automatiseerivad tervete IP-vahemike skannimist, otsides avatud porte (kasutades selliseid tööriistu nagu Nmap) ja pärast avastamist testivad teadaolevaid haavatavusi või jõhkraid rünnakuid.

Väga tundlikud teenused, näiteks SSH (22/TCP), RDP (3389/TCP), SMB (445/TCP) või andmebaasid Need on prioriteetsed sihtmärgid, kuna rike seal võib anda otsese juurdepääsu sisevõrgule või kriitilistele andmetele.

Rünnakupinna vähendamiseks on soovitatav rakendada põhimõtet minimaalne õigus sadamatesAva ainult need, mis on hädavajalikud, piira juurdepääsu IP või VPN-i kaudu, kui võimalik, ning sulge või filtreeri kõik, mida ei kasutata.

See on ka hea mõte jagage võrk tsoonideks (kasutaja kohtvõrk, serveri demilitariseeritud tsoon, haldusvõrk jne) ja kasutage kriitiliste teenuste isoleerimiseks sisemisi tulemüürireegleid. Nii on isegi kui ründaja ühe masina ohtu seab, tal raskem liikuda edasi teiste tundlike süsteemide juurde.

Kasutamine jälgimis- ja logimisvahendid See võimaldab tuvastada anomaalseid mustreid sadamates (skanneeringud, massilised ebaõnnestunud katsed, ühendused ebatavalistest riikidest) ja käivitada hoiatusi enne intsidendi eskaleerumist.

Lõpuks on soovitatav läbi viia perioodilised sadamaauditid Kasutage väliseid ja sisemisi skannereid ning dokumenteerige, milline teenus neid kuulab. See aitab tuvastada aegunud rakendusi, unustatud teenuseid või ohtlikke vaikesätteid, mis tuleks keelata.

TCP ja UDP portide jõudluse erinevused

Kui võrdleme TCP ja UDP portide kaudu liikuvat liiklust, siis tegelikult mõõdame järgmist: mõlema transpordiprotokolli käitumine erinevates tingimustes võrgutingimused.

TCP oma vea- ja ummikute kontrolliga kipub aeglustub, kui see tuvastab kadumise või küllastuseseades prioriteediks, et kõik jõuaks kohale õigesti, mitte kiiresti. Ülekoormatud võrkudes või suure latentsusega võrkudes võib see tähendada pikemaid laadimisaegu või descargas vähem väle.

UDP ei lase ummikute tõttu end peatada: Kui tee on ülekoormatud, siis ruuterid lihtsalt loobuvad pakettidest.Kuna automaatset edastamist ei toimu, jääb suhtlus sujuvaks, kuid esineb infolünki, millega rakendus peab tegelema (näiteks puhverdamise või oma veaparanduse abil).

VPN-ide ja suurte geograafiliste vahemaade testides on täheldatud, et OpenVPN UDP kaudu on tavaliselt oluliselt kiirem kui TCP kauduErinevus muutub märgatavamaks võrgutingimuste halvenedes. See on tingitud nii väiksemast päisest kui ka pidevate ACK-de ja korduseksaadete puudumisest.

Samuti on mõju andmete tarbimineTänu mahukamatele päistele ja täiendavatele juhtsõnumitele kasutab TCP iga kasuliku edastatud megabaidi kohta rohkem ribalaiust. Gigabaidise piiranguga mobiilsideühenduste puhul võib see kuu lõpus olulist rolli mängida.

Muud transpordiprotokollid peale TCP ja UDP

Kuigi praktikas töötab peaaegu kogu internet TCP ja UDP baasinaOn ka teisi transpordiprotokolle, mis on loodud konkreetsete kasutusjuhtude jaoks.

Üks neist on SCTP (voo juhtimise edastusprotokoll)See ühendab TCP ja UDP omadused: pakub usaldusväärset ja korrastatud edastust, kuid lubab sama ühenduse piires mitut sõltumatut voogu. Seda kasutatakse laialdaselt täiustatud telekommunikatsioon ja VoIP-signaalimine, kus see vähendab latentsust võrreldes traditsioonilise TCP-ga.

Veel üks on DCCP (Datagrammi ülekoormuse juhtimise protokoll), mis säilitab UDP võrguühenduseta stiili, aga sisaldab integreeritud ummikute kontrollloodud reaalajas multimeedia jaoks, kus pakettide kaotamine on eelistatavam kui liiga suure latentsuse tekitamine.

Samuti RDP (usaldusväärne andmeprotokoll), keskendudes sõjalisele ja teaduskeskkonnale ning nagu juba mainitud, QUIC, mis tugineb UDP-le, kuid rakendab usaldusväärsust, multipleksimist ja krüpteerimist ühes kihis, olles HTTP/3 aluseks.

Vaatamata tehnilistele eelistele on tegelikkus selline, et Uute protokollide massiline kasutuselevõtt on keeruline: kogu ruuterite, tulemüüride ökosüsteem, operatsioonisüsteemide Rakendused on optimeeritud TCP ja UDP jaoks ning selle aluse muutmine on pingutust, kulusid ja riske nõudev. Lisaks blokeerivad paljud tulemüürid vaikimisi haruldasi protokolle, samas kui TCP 80/443 liiklus ja märkimisväärne hulk UDP-d on peaaegu alati lubatud.

Mõistan hästi Kuidas TCP ja UDP pordid töötavad, millised teenused neist sõltuvad ja kuidas need mõjutavad jõudlust ja turvalisust. See võimaldab meil teha mõistlikke otsuseid: millal tasub töökindluse suurendamiseks kiirust ohverdada, millal on kasulik kasutada UDP-d latentsuse vähendamiseks, milliseid porte tulemüüris avada või sulgeda või milliseid parameetreid VPN-is või serveris kohandada, et tagada meie võrgu sujuv töö ja võimalikult vaba kaitse rünnakute eest.