En guide till UDP (User Datagram Protocol)

En guide till UDP


Användardatagramprotokollet är som Hans Christian Andersens ”Ugly Duckling”. Efter decennier av att förbises och förlöjd lockade detta enkla protokoll plötsligt beundrare som transportprotokoll för de nya, glamorösa multimediaapplikationerna som möjliggjordes av bredbandshastigheter. Idag väljer alla applikationer som behöver leverera data snabbt UDP över det tidigare dominerande TCP (Transmission Control Protocol).

UDP-historia

UDP har funnits nästan lika länge som internet. Internet blev i maj 1974 när Institute of Electrical and Electronics Engineers publicerade ”Ett program för paketnätverkskommunikation" förbi Vint Cerf och Bob Khan. Konceptet behövde utvecklas och både Khan och Cerf fortsatte att förfina sina idéer medan de arbetade för den amerikanska regeringen Defense Advanced Research Projects Agency, vilket också kallas DARPA. John Postel engagerade sig och föreslog att dela upp den enda strukturen som föreslogs i Cerf och Khans ursprungliga idé. Detta skapade ett lager i koncept. Det ursprungliga överföringskontrollprogrammet som ingår i dispositionen från 1974 delades upp i överföringskontrollprotokollet i ett högre lager och Internetprotokollet i ett lägre lager (därav TCP / IP).

Postels modulära inställning gav mening när teamet började fundera på att implementera teorin. Det fanns en tydlig arbetsdelning mellan det som blev känt som Transportlager, som är platsen för överföringskontrollprotokollet och Internetlager, där Internetprotokollet finns. Cerf och Khan såg dock behovet av ett snabbspåralternativ. De utarbetade ett diagram över hur data skulle förberedas för överföring genom att överföras från ett lager till ett annat. Bearbetningsuppgifterna representerades som en rak vertikal linje, nedåt genom deras nya stapeldiagram som visar utvecklingen från applikation till TCP och vidare till IP.

När det gällde att rita i snabbspåret ville de inte behöva rita en krökt omkörningslinje som undvek att passera genom TCP. Istället ritade de en avlång form som representerade internetlagret lite bredare än blocket som representerade transportlagret. Med denna visuella justering skulle både den vanliga rutten och snabbspåren kunna gå ner genom bunten som parallella linjer. Detta trick lämnade emellertid ett gap som Postel ansåg behöva fyllas. Därför uppfanns användardatagramprotokollet. Det var precis där för att få protokollbunksdiagrammet att se balanserat ut.

Fördelarna med TCP

Protokollet för överföringskontroll tillhandahåller väsentliga tjänster för data under transport. Det säkerställer att alla paket i en ström faktiskt anländer och kontrollerar att de kommer i ordning. Dessa kontrollförfaranden som säkerställer en ordnad överföring är inte möjliga utan ett mått på samordning mellan de två sidorna. Så, TCP upprättar först ett avtal mellan de två enheterna som tänker utbyta data. Detta avtal kallas en session. Det är också själva definitionen av en "förbindelse.”UDP har inga rutiner för etablering av sessioner och det benämns därför”anslutningslös.”

Sessionen ger båda sidor av anslutningen ett referensnummer som de kan tagga på sina administrativa utbyten. Sessionen gör det också möjligt att introducera konceptet med portar. Sessions-ID är faktiskt en kombination av identifierare i TCP-huvudet. Med detta ID kunde designarna av TCP-procedurer komma med idén om en "uttag.”Portnummer tilldelas också UDP, men det protokollet kan bara använda destinations-IP och portnummer som en unik identifierare. En identifierare härledd från denna kombination skulle blockera alla andra processer som försöker komma åt samma port, även om de körde på olika datorer, så UDP skapades som ett leveransbart system utan några procedurer för att möjliggöra en tvåvägsdialog.

TCP-anslutningskoncepten utvecklades alla till en mycket sofistikerad universalmetod för att säkerställa att data som skickas mellan datorer inte blandades eller trasslade. Uttaget gjorde det möjligt att öppna flera anslutningar mellan samma två datorer samtidigt. Den idén skapade möjligheten att ha mer än en kanal som fungerar för att skicka data. Detta är ett vanligt använt förfarande som många tidiga nätverksapplikationer utnyttjade. De Filöverföringsprotokoll, använder till exempel två kanaler: en för att skicka data och en separat kanal för administrativ kommunikation. De olika portnumren för data och kontrollkanaler skapar två distinkta uttag.

Det unika ID för varje session innebar att TCP tillförde mervärde till kommunikationen mellan två datorer. I slutet av 70-talet och tidigt 80-tal hade bara stora organisationer och akademiska institutioner datorer och nätverk. Så det var mycket troligt att två organisationer behövde sina stora stordatorer för att ansluta till varandra samtidigt för olika ändamål. Medan en professor skickade en fil till en kollega vid ett annat universitet, kanske en forskare också vill öppna en Telnet-session till datorn vid samma avlägsna universitet. Tack vare TCP kunde två datorer upprätthålla flera anslutningar samtidigt och var och en av dessa sessioner kunde driva flera kanaler samtidigt. Dessa samtidiga anslutningar skulle inte vara möjliga om kommunikation endast styrdes av Internetprotokollet med dess fördelning av en IP-adress per dator. UDP, utan någon sessionmekanism, kunde inte hantera applikationer som krävde en kontaktad dator för att skicka ett svar.

Datasäkerhet

De geniala konstruktionerna av TCP möjliggjorde förbindelser mellan nätverk och internet började expandera bortom Academia till näringslivet. Skapandet av World Wide Web, som blev offentlig 1991 var bara möjligt på grund av den enkla webbplatsen med Hypertext Transfer Protocol (HTTP) kunde sitta ovanpå TCP.

Akademiker och tekniker som satte samman internet och sedan utvecklade den allmänt tillgängliga World Wide Web var blå himmel tänkare. De var upphetsade över tekniken och dess möjligheter att påskynda forskning och förbättra samspelet mellan människor över hela världen. De kunde inte redovisa det faktum att deras underbara uppfinning var en gåva till tjuvar, con artister och urban terrorister. Varken internet eller World Wide Web hade någon säkerhet alls.

Det tog konsumentledningen Netscape Corporation för att upptäcka detta problem. Netscape producerade världens ledande webbläsare och gav bort den gratis för att uppmuntra upptagningen av internet bland allmänheten. Planen fungerade och informationsutbyte och kontaktkanaler spriddes, vilket uppmuntrade fler medlemmar av allmänheten att registrera sig för internettjänster. Men brist på säkerhet innebar en hinder för kommersialiseringen av webben. Utan förmågan att locka människor att betala för onlinetjänster fanns det inget incitament för företag att investera i utvecklingen av nya applikationer, webbplatser eller onlinetjänster.

Den största hindern för att samla in betalningar via webben var dess brist på säkerhet. Några rubriker om datastöld på internetöverföringar stänger av möjligheten att göra internet kommersiellt lönsamt. dock, Netscape kom med HTTPS - en säker version av HTTP som skyddade överföringen. Den perfekta platsen i TCP / IP-stacken för dessa säkerhetsprocedurer var under TCP: s sessioner. Så, TCP blev ännu viktigare för Internet-verksamheten och det verkade ännu mer troligt att UDP aldrig skulle användas.

UDP tar fart

Trots att det funnits sedan 1980, UDP förbises helt tills bredbandstjänster blev tillgängliga i början av detta århundrade. Användardatagramprotokollet ignorerades till stor del medan webb- och andra internetapplikationer utökade med TCP: s funktionalitet.

dock, möjligheten att ha röstsamtal och videokonferenser via internet har alltid vädjat till företag. Dessa applikationer fanns före bredband, men endast för användning i snabbare privata nätverk. Med den teknik som passerar ljud och video över nätverk etablerad, de snabbare hastigheterna för bredband gav möjligheten att göra dessa applikationer tillgängliga för allmänheten blev en genomförbar idé. De tillgängliga hastigheterna över internet var dock inte riktigt bra.

Den omedelbara lösningen för att pressa tillräckligt med extra hastighet på internet var att dike alla administrativa förfaranden för TCP och vända dig till det nästan glömda UDP.

Problemen med TCP

Interaktiva applikationer skulle snarare ta itu med några av de problem som uppstår under själva överföringen. En av huvudfunktionerna i TCP som dessa applikationer verkligen inte vill ha är buffrande.

TCP ser till att paketen anländer i följd. Om ett paket saknas i strömmen, den mottagande TCP-implementeringen skickar en begäran till det sändande TCP-programmet om att skicka igen det specifika paketet. Under tiden kan det paketet komma sent. TCP använder ett glidande ramsystem för att bearbeta anlända paket och om ett segment är sent eller förlorat kommer den bilden fastnat. Den tillfälliga lagringen av ett antal ramar i minnet är det som kallas buffring. TCP väntar tills den kan fylla det tomma spåret med det paket som har det saknade sekvensnumret. När det gäller internettelefoni skulle en sådan åtgärd leda till att linjen tystnar. Vid videoströmning skulle väntan på ett saknat paket få videospelaren att frysa.

Interaktiva applikationer har inga rutiner för att arbeta kring TCP-buffring. Det huvudsakliga bakom stapelskikten är att högre lager ber om en tjänst och lämnar den till det undre lagret för att tillhandahålla den. Det finns ingen signal om att en applikation kan skicka till Transport Layer.

Om ett paket går förlorat i en digital telefonsamtal kommer uppringarna att uppleva en kort tystnad, men applikationen på båda sidor kommer bara att gå vidare och fortsätta att skicka och ta emot följande paket. När ett saknat paket kunde återhämtas skulle den interaktiva konversationen redan ha gått vidare så det är ingen mening att försöka injicera det tillbaka i strömmen; det är bara bättre att skriva av förlusten och fortsätta. På liknande sätt skulle ett förlorat paket bara betyda ett kort hopp i en direkt videoström och tittarna skulle mycket snarare att videon fortsatte att gå framåt än att hålla upp tomten under ett millisekund bildrutor.

Du har förmodligen sett en videospelare pausa och lägga över meddelandet "buffrande”Över bilden. Det finns vanligtvis också en räknare som visar procentandelen buffert som har slutförts. Denna buffring sker om anslutningens överföringshastighet är långsammare än bildhastigheten för videouppspelningen. Den avgörande punkten med det meddelandet är dock att det visar att buffringen hanteras av spelaren och inte av transportprotokollet.

Samarbetsprotokoll

Även om den interaktiva applikationen inte ville ha förseningar orsakade av TCP, ville de ha en del av det protokollets funktionalitet. De ville ha mer än UDP kunde ge. Så andra protokoll uppfanns för att fylla i delar av TCP: s kapacitet.

Session Initiation Protocol

SIP (Session Initiation Protocol) uppfanns för Voice over IP (VoIP) -applikationer. Internet-telefoni ville inte ha buffring av TCP, men de behövde emulera de traditionella rutinerna för uppringning av telefoner - ringa, ring, upptagen, plocka upp och avsluta samtalet. SIP hanterar emellertid inte hela sessionen, den tar bara hand om anslutningsskapande och nedbrytningsfunktioner för TCP. Varje samtal som går över internet använder SIP. Så mycket att "SIP" nästan har blivit en utbytbar term med "VoIP.”

Att driva rösttrafik över snabba digitala anslutningar i bulk kallas "SIP-trunking.”Att byta ett samtal från internet till en vanlig fasttelefon kallas”SIP-uppsägning.”Den digitala telefoniindustrin använder SIP för att identifiera sin teknik, men grunden för all sin verksamhet är UDP.

Transportprotokollet i realtid

Trots beslutet om att TCP var för mycket av en omkostnad för interaktiv trafik och borde dras, kommunikationsingenjörer återvände till TCP: s anläggningar och de önskade att de kunde ha dem med UDP. Real-Time Transport Protocol (RTP) kompenserar för mycket av det brist på funktionalitet som upplevs vid användning av UDP.

En viktig funktion i dessa tilläggsprotokoll som gör UDP relevant för mediaströmning är att de tillåter att några av de processer som traditionellt hanteras av TCP skjuts upp till applikationen. RTP hanterar vissa av TCP: s trafikhanteringsfunktioner, men inte alla.

RTP kan ordna om från sekvenspaket och notera förlorade paket. Sekvenseringsfunktionen behöver emellertid inte implementeras och är omöjlig att implementera utan buffring vid transportlagret.

RTP-kontrollprotokollet

RTP samarbetar alltid med RTCP, vilket är RTP-kontrollprotokollet. RTPC emulerar vissa av TCP: s sessionhanteringsfunktioner, utom protokollets vägledande princip är att inte intrång i strömmen och inte bromsa medieöverföringen; så dess aktiviteter är sällsynta. Protokollet samlar in prestandadata, inklusive paketförlust, och överföringshastighetsinformation. Den mottagande spelaren kan använda denna information för att bestämma sig för att byta till en lägre videoupplösning eller till en annan videokodningsstandard.

Om du använder en video- och ljudapplikation är det nästan säkert att både RTP och RTCP är inblandade. Där är en "interfoliering”Alternativ i definitionen av RTSP (se nedan) som skulle flytta RTP-sändningar till TCP. Detta är emellertid ett ovanligt förslag som aldrig har genomförts bortom labbet. Utan den specifikationen bedrivs all RTP- och RTCP-verksamhet av UDP.

Protokoll för realtidströmning

RTSP (Real Time Streaming Protocol) är nästan alltid involverat i video- och ljuduppspelning eller inspelningsprogram. Detta protokoll innehåller kontrollknappar på din spelare och inspelare. Dessa är paus, spela in / spela, spola framåt och spola tillbaka. Märkligt nog, även om RTSP kan köra över UDP, transporteras det vanligtvis över TCP, även om det samarbetar med en UDP-stödd video- eller ljudström.

UDP-applikationer

Ett antal lätta nätverk som stöder applikationer använder UDP utan några andra protokoll som utgör en simulering av TCP-funktioner. Dessa funktioner är nästan uteslutande endast avsedda för användning i privata nätverk eftersom de inte innehåller några autentiseringsförfaranden eller överföringskryptering.

Om du hanterar ett nätverk kommer du att känna till Network Time Protocol (NTP), de Domain Name System (DNS), de Dynamic Host Configuration Protocol (DHCP), och den Trivial File Transfer Protocol (TFTP). Alla dessa administrationstjänster kör över UDP. Utöver dessa privata nätverksapplikationer är det mycket svårt att hitta någon applikation som bara körs över UDP.

UDP vs TCP

En jämförelse av UDP-huvudstrukturen och TCP-huvudstrukturen visar dig UDP: s begränsningar.

UDP-huvudstruktur

UDP-huvudet har bara fyra fält. Av dessa fyra, Källa Port fältet är valfritt och kan lämnas tomt. I IPv4, kontrollsumma fältet är också valfritt, även om det är obligatoriskt för IPv6-implementationer. Detta innebär att när det gäller IPv4-sändningar behöver UDP-huvudet bara ha två informationer i sig.

TCP-rubriken kan ta med mycket mer information.

TCP-huvudstruktur

Som du kan se från illustrationen har TCP-pakethuvudet en serie med nio flaggor som anpassar rubrikens betydelse. Eventet har ett "brådskande" fält. Detta ger TCP-systemet mycket mer flexibilitet än UDP och det visar att mycket mer tid investerades i procedurerna för TCP och strukturen i dess pakethuvud än vad som spenderades på att utveckla UDP.

Det faktum att TCP-huvudet måste inkludera källporten gör det möjligt att skapa ett mer unikt uttag, skapa ett session-ID från källans och destinations-IP-adresserna och käll- och destinationsportnumren. Med UDP, eftersom det inte har procedurer för att skapa en session, varje meddelande behandlas som en färdig uppgift, och protokollet försöker inte stränga paket ihop. Därför måste applikationer som använder USP hantera den kontinuiteten själva.

Säkerhet för UDP

De anslutningsorienterade metoderna för TCP gör säkerheten mycket enklare att implementera i det protokollet i UDP. Det finns emellertid krypteringsstandarder tillgängliga för UDP. Det huvudsakliga alternativet som direkt syftar till säkerhets UDP är Datagram Transport Layer Security protocol eller DTLS.

Lyckligtvis, DTLS finns tillgängligt i ett antal gratis, öppen källkodsbibliotek, så du behöver inte kamma igenom protokolldefinitionen och skriva ditt öppna program för att implementera det. OpenSSL, som är ett bibliotek med öppen källkod, är den vanligaste källan för en implementering av Transport Layer Security, som är det mest implementerade säkerhetssystemet för TCP. Detta bibliotek också inkluderar en DTLS-implementering, så du borde kunna möta säkra UDP-alternativ i samma applikationer som erbjuder säkra TCP-anslutningar.

Ett annat alternativ för UDP-användare är att förlita sig på ett säkerhetssystem som utformades för att fungera på Internet Layer. Detta är IPSec, eller Internetprotokollsäkerhet. Eftersom IPSec fungerar under transportlagret kan det inte fungera med portar och det faktum att UDP inte kan upprätthålla en session spelar ingen roll när IPSec är engagerad - Protokoll för IP-lager kan inte skapa sessioner heller. Som ett lägre skikt, IPSec kan stödja alla Transport Layer-protokoll, inklusive UDP.

IPSec inkluderar autentiseringsmetoder och krypterar också paket för att skydda dem från att wiretappa snoopers. IT erbjuder lika mycket säkerhet som den populära TLS, men är mindre spridd implementerad. IPSec använder Internet Key Exchange (IKEv2) -systemet för att ställa in autentisering, så ganska ofta faktureras IPSec som IKEv2. IKEv2-metodiken använder Diffie-Hellman viktiga utbytesförfaranden, vilket är exakt samma system som TLS använder för HTTPS-säkerhetssäkerhetsmetodik.

Kerberos och Kerberized Internet Negotiation of Keys (KINK) är två delar av ett säkerhetssystem som vanligtvis kallas Kerberos. I Kerberos-sessionens upprättningsförfaranden används ett system med "biljetter" som liknar TLS-metoden för att använda "certifikat." Längst ner i bunten understöds Kerberos av IPSec. Det eponymous Kerberos-lagret sitter ovanpå UDP och använder UDP-uttag för att underlätta kommunikation. Så detta är ett UDP-vänligt säkerhetssystem. En spännande anläggning för Kerberos är att det ger dig möjligheten att använda AES-kryptering för att skydda dina UDP-överföringar. AES är förmodligen den säkraste kodaren i vanlig användning idag och det är den rekommenderade säkerhetsmetoden för världens bästa VPN-sekretessskyddssystem.

Trots de uppenbara svårigheterna med att förhandla om krypteringsnycklar i en miljö som inte ger någon anslutningshantering, erbjuder UDP säkerhetsalternativ. Så när du implementerar en UDP-baserad applikation, släpp inte uppgiften att säkra dina överföringar.

Framtiden för UDP

Rena UDP-baserade applikationer som inte involverar sidoprotokoll för att härma TCP är sällsynta och de kommer troligen att bli ännu sällsynta. De lätta nätverksverktygen som använder UDP trivs i säkra lokala nätverk. Men när säkerhetshoten från nya nolldagarsattacker växer varje vecka, verkar begreppet att ha osäkra protokoll som hanterar de avgörande tjänsterna för konfigurationshantering och adressering vara dumt tillfredsställande.

När nätverk flyttar sin tjänst till molnet kommer tjänsterna för UDP-baserade TFTP och DHCP att börja ersättas av säkrare alternativ. Den enkla lösningen av surfapplikationer över HTTPS för att ge dem säkerhet utan extra programmeringsinsatser lutar framtiden mot TCP, som bär HTTPS och remsor möjligheter bort från UDP-listan över kompetenser.

UDP-nischen för att stödja mediasändningar kommer troligtvis att bestå. Det har redan föreslagits många konkurrerande transportsystem för stöd för interaktiva applikationer, men ingen av dem har slagit UDP från sin position som första valet för VoIP och videoströmning. Denna lista över rivaler inkluderar:

Det pålitliga användardatagramprotokollet (RUDP), som har Cisco- och Microsoft-implementationer.

Strömkontrollöverföringsprotokollet (SCTP), vilket utan framgång föreslogs som en ersättning för UDP / RTP / RTCP-kombinationen, men aldrig riktigt började.

Denna fula ankungen som kallas UDP upptäcktes som en svan tack vare de magiska transformativa krafterna i bredband och interaktiva applikationer. Denna revitaliserade stjärna fortsätter att glida utan problem över internetets vatten.

Vilka överföringsmetoder använder du? Ser du UDP: s ful ankungen som en svan? Skriv om dina upplevelser i avsnittet Kommentarer nedan.

Relaterad:
Ultimate guide till TCP / IP
Vad är TCPdump?
SolarWinds TFTP-servergranskning
TFTPD32 TFTP-servergranskning

Bilder:
Header of UDP av Devarshi på engelska Wikibooks licensierade under CC BY-SA 2.5
TCP-paketlayout med bitskala av Quliyevferman via Wikimedia Commons. Licensierad enligt CC BY-SA 4.0

Brayan Jackson
Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me

Add a Comment

Your email address will not be published. Required fields are marked *

73 + = 82