Transporti pa koneksion: UDP

Transporti pa lidhje (koneksion): UDP'

Për të motivuar diskutimin tonë për UDP, supozojmë që ju jeni i interesuar në dizajnimin e no-frills, bare-bones transport protocol. Si do të ja bëni që ta bëni këtë? Së pari ju mund të konsideroni të përdorni a vacuous transport protocol. Veçanërisht, në pjesën e dërgimit, ju mund të merrni mesazhet nga procesit i aplikacionit dhe ti kaloni ata direkt në shtresën e rrjetit; dhe në pjesën e pranimit, ju mund të merrni mesazhet që arrijnë nga rrjeti dhe ti kaloni ata direkt ne procesin e aplikacionit. Por siç kemi mësuar ne seksionin paraprak, ne kemi për të bërë pak më shumë se asgjë. Së paku, shtresa e transportit duhet të siguroj multipleksim/demultipleksim shërbime me qëllim që të kaloj të dhënat ndërmjet shtresës së rrjetit dhe the corect application-level process.

UDP, e definuar në [RFC 768], bënë përafërsiaht aq pak sa transport protocol mund të bëjë. Tutje prej funksionit të multipleksim/demultipleksim dhe disa korrigjime te vogla, nuk shton asgjë në IP. Në fakt, nëse zhvilluesi i aplikacioni zgjedhë UDP në vend të TCP, atëherë aplikacioni është pothuajse direkt duke komunikuar me IP. UDP i merr mesazhet prej procesit të aplikacionit, bashkëngjit (attach) numrin e portit të burimit dhe destinacionit për shërbimet multipleksim/demultipleksim, shton dy apo më shumë fusha, dhe e kalon pjesën rezultuese në rrjet. Rrjeti encapsulates pjesën e shtresës së rrjetit në pjesë të të dhënave IP dhe pastaj bënë përpjekjen më të mirë qe ta dërgoj atë pjesë tek pranuesi. Nëse kjo pjesë (segment) arrin tek pranuesi, UDP e përdor numrin e destinacionit që të shpërndaj segmentin e të dhënave tek the corect application-level process. Vëreni se me UDP nuk ka shtrëngim duarsh në mes dërgimit dhe pranimit te shtresës së transportit përpara dërgimit te segmentit. Për këtë arsye, UDP thuhet se është pa lidhje.

DNS është një shembull i application-layer protocol që përdor UDP. Kur aplikimi DNS dëshiron të bëjë një pyetje, ai ndërton një mesazh DNS dhe kalon mesazhin tek UDP. Duke mos kryer any handshaking with UDP entity që lëviz në destinacion dhe sistem, ana pritëse shton fusha në mesazh dhe kalon mesazhin pasues ne rrjet. Shtresa e rrjetit encapsulates segmentin në një UDP datagram dhe dërgon datagramin në një server. Aplikacioni pritës i DNS pastaj pret për përgjigje të pyetjes së tij. Në qoftë se merr ndonjë përgjigje (e mundur për shkak se rrjeti ka humbur pyetjen apo përgjigje), ose ai përpiqet që ta dërgoj pyetjen në një emër tjetër të serverit, ose ajo e njofton invoking application që nuk mund të marrë një përgjigje. Tani ju mund të pyesin pse një zhvillues i aplikacionit do të zgjedhin për të ndërtuar një aplikacion mbi UDP në vend të TCP. A nuk është TCP gjithmonë më e preferueshme, pasi që TCP ofron një shërbim të besueshëm transferimi të të dhënave, të cilin UDP nuk e bënë? Arsyeja është jo, pasi shumë aplikacione janë më mirë të përshtatura për UDP për këto arsye:

Finer application-level control mbi atë se çfar të dhëna janë dërguar dhe kur. Me UDP, pasi procesi i aplikacioni kalon të dhënat në UDP, UDP do ti paketoj të dhënat përbrenda segmentit të UDP dhe menjëherë e kalon segmentin ne rrjet. TCP, në anën tjetër, ka një congestion-control mechanism që ul shpejtësinë e shtresës së transportit të dërguesit TCP kur një apo më shumë linçe mes burimit dhe destinacionit të pritësit tejmbushen. TCP gjithashtu do të dërgojë përsëri një segment derisa segmenti të pranohet nga pranuesi, pavarësisht sa shumë kohë merr. Pasi që aplikimi në kohë reale shpesh kërkon minimumin e sasisë së dërgesës, nuk dëshiron që ta shtyjë tepër transmisionin e segmentit, dhe mund të toleroj disa humbje të të dhënave, shërbimet e modelit TCP nuk janë veçanërisht të harmonizuara me nevojat e aplikacioneve. Siç është diskutuar më poshtë, këto aplikacione mund të përdorin UDP dhe ta implementojnë, si pjesë e aplikacionit, çdo funksion shtesë qe është i nevojshëm përtej UDP’s no-frills segment-delivery servile.

No connection establishment. Siç do të diskutojmë më vonë , TCP përdor a there-way handshake para se të filloj të transferoj të dhëna. UDP vetëm hedhin tutje pa ndonjë paralajmërim paraprak. Në këtë mënyrë UDP nuk paraqet ndonjë shtyrje të vendosjes së lidhjes. Ndoshta kjo është arsyeja kryesore pse DNS lëvizë mbi UDP përkundër TCP sepse DNS do të ishte shumë më e ngadalshme nëse do lëvizte nëpër TCP. HTTP përdor TCP në vend të UDP, pasi që siguria është kritike për Web faqet me tekst të shkruar.Në HTTP vendosje të lidhjes TCP shtyrja është një kontribues i rëndësishëm e lidhur me vonesën e shkarkimit të Web dokumenteve.

Gjendje pa lidhje (koneksion). TCP mirëmban gjendje e lidhjes ne sistemet e fundit. Kjo gjendje e lidhjes përfshin zbutësit e pranimit dhe dërgimit, parametrat e kontrollit të ngjeshjes, dhe numrin e parametrave dhe sekuencës se pranimit. kjo gjendje është e nevojshme për të implementuar sigurinë e TCP për transferimin e të dhënave dhe siguron kontrollin e ngjeshjes të të dhënave. UDP, nga ana tjetër, nuk mirëmban gjendjen e lidhjes dhe nuk ndjek ndonjë nga parametrat. Për këtë arsye, një server i tërhequr te një aplikacion i veçantë mund të mbështes më shumë klientë aktiv kur aplikacioni lëviz mbi UDP në vend të TCP.

Small packet header overhead. Segmenti i TCP posedon 20 bite të lartë në çdo segment, ndërsa UDP ka vetëm 8 bite të lartë.

Siç ne presim, e-mail, kontakt në largësi, Webi, dhe fajllat për transfer kalojnë mbi TCP-të gjitha këto aplikacione kanë nevojë për të dhënat e besueshme e TCP shërbimeve të transferimit. Megjithatë, shumë aplikacione të rëndësishme lëvizin me UDP në vend të TCP. UDP përdoret për RIP tabelën e informatave të reja-updates. Meqë ‘updates’ e RIP dërgohen periodikisht (çdo pesë minuta) ‘updates’ do të zëvendësohen më ‘updates’ më të reja, për të bërë humbjen e këtyre ‘updates’ të papërdorur. UDP gjithashtu përdoret për të mbajtur rrjetin, menagjimin e të dhënave. UDP është më e preferuar se TCP në këtë rast, pasi që aplikacioni i menagjimit të rrjetit shpesh duhet të lëviz kur rrjeti është në gjendje kaotike (stresuese)-pikërisht kur besohet, transferi i kontrollit të ngjeshjes së të dhënave është i vështir për tu arritur. Gjithashtu, siç e përmendëm më parë, DSP lëviz mbi UDP, kështu që shmangja e krijimit të lidhjes shtyhet.

Që të dyja TCP dhe UDP janë përdorur sot me aplikacione multimedial, si telefoni ,internetit, videot për konferenca reale, dhe audio. Ne sapo përmendëm që të gjitha këto aplikacione mund të tolerojnë një sasi të vogël të humbjes, kështu që transferimi i besueshëm nuk është absolutisht kritik për suksesin e aplikacionit. Për më tepër, aplikacionet në kohë, si telefoni ,internetit dhe video konferenca, reagojnë shumë dobët tek kontrolli i ngjeshjes së TCP. Për këto arsye, zhvilluesit e multimedial mund të zgjedhin ti drejtojnë aplikacionet e tyre në UDP në vend të TCP. Megjithatë, TCP është duke e rritur përdorshmërin e saj për transport të medias. Për shembull, [Sripanidkulchai 2004] deklaroi se gati 75% e kërkesës online përdorin TCP. Ku humbjet janë të vogla, dhe disa bllokime për trafikun UDP për shkaqe të sigurisë, TCP bëhet një protokoll aplikacion atraktiv për media transport.

Edhe pse, në ditët e sotme, rrjedhja e aplikacioneve të multimediale mbi UDP është bërë e diskutueshme. Siç përmendëm më herët, UDP nuk ka kontroll të ngjeshjes. Por kontrolli i ngjeshjes është i nevojshëm për parandalimin e ndonjë rrjeti që të hyjë në gjendjen e ngjeshur në të cilën shumë pak punë bëhet. Nëse të gjithë do të fillonin një video me kapacitet të lartë pa përdorur kontrollin e ngjeshjes, aty do të kishte tejmbushje dhe shumë pak UDP to të kalojë nëpër burim-destinacion. Për më tepër, sa më e madhe shkalla e humbjeve prej UDP të pakontrolluar (të cilat, siç do të shohim, e humbin normën e tyre në përballje më ngjeshje) në mënyrë drastike do të shkaktoj zvogëlimin e tyre. Kështu që, mungesa e UDP kontrollit të ngjeshjes mund të rezultojë në humbje të madhe të normës mes dërguesit UDP dhe pranuesit, dhe grumbullimit të sesionit TCP-një problem serioz potencial [Floyd 1999]. Shumë studiues kanë propozuar një mekanizëm të ri për të gjitha burimet, duke përfshirë UDP, qe të interpretojnë kontroll adaptim të ngjeshjes [Mahdavi 1997; Floyd 2000; Koher 2006: RFC 4340]. Para se të diskutojmë strukturën e segmentit të UDP, ne përmendëm se është e mundur për një aplikacion të ketë një transfero të besueshëm kur përdorin UDP. Kjo mund të bëhet nëse besueshmëria është e ndërtuar në aplikacion vetë (për shembull, duke shtuar mekanizmin e njohjes dhe ritransmetimit, të tilla që do ti studiojmë ne seksionin tjetër). Por kjo nuk është një detyrë ë parëndësishme që do të mbajë një zhvillues të aplikacionit të zënë duke rregulluar për një kohë të gjatë. Megjithatë, ndërtimi i besueshmërisë direkt në aplikacion lejon aplikacionin që ‘ta ketë tortën e vet dhe ta hajë atë gjithashtu.’ Kjo është, operacionet e aplikacionit mund të komunikojnë besueshmërish pa subjekt të kërkuar nga transmisioni-normat të ngarkuara nga mekanizmi i kontrollit të ngjeshjes.

Struktura e Segmentit UDP

Të dhënat e aplikacionit marrin fushim e segmentit të UDP. Për shembull, për DNS, fusha e të dhënave përmban ose një pyetje mesazh ose një mesazh të përgjigjes. Për a streaming video aplikacion, shembujt audio mbushin fushën e të dhënave. UDP header ka vetëm katër fusha, secila e përbërë nga dy bite. Siç është diskutuar në seksionin paraprak, numri port lejon pritësin ta kaloj aplikacionin e të dhënave te procesi korrekt duke lëvizur në fund të sistemit të destinacionit (kjo është, që të performoj funksionin demultisplexing ). Checksum përdoret nga ana pranuese që të kontrolloj nëse janë identifikuar gabime në segment. Në të vërtet, checksum llogaritet mbi disa fusha të IP header përveç segmentit UDP. Por ne e injorojmë këtë detaj në mënyrë që të shohim pyllin përmes pemëve. Ne do të diskutojmë llogaritjen e checksum më poshtë. Gjatësia e fushës specifikon gjatësinë e segmentit të UDP, doke përfshirë the header, në bite.

UDP Checksum

UDP checksum na njofton për diktimin e gabimeve. Kjo është, checksum përdoret për për të treguar nëse bitet përbrenda segmentit kanë ndryshuar (për shembull, nga zhurmat ne linçe, ose gjer ruajtjes ne linjë) gjatë lëvizjes nga burimi tek destinacioni. UDP në anën e dërguesit performon komplimentin e pare të shumës të të gjithë 16 bitëve në segment, me ndonjë tejmbushje llogaritur gjatë mbledhjes duke u mbyllur. Rezultati vendoset në fushën e checksum të segmentit UDP. Këtu është një shembull i thjesht i checksum llogaritjes. Mund të gjeni detaje rreth

Zbatimit efikas të llogaritjes në RFC 1071 dhe ti performoni mbi të dhëna të vërteta [Stone 1998; Stone 2000]. Si shembull, supozojmë që kemi fjalët 16 bitëshe pasuese:

0110011001100000

0101010101010101

1000111100001100

Shuma e dy fjalëve 16 bitëshe të para është

0110011001100000

0101010101010101

1011101110110101

Duke shtuar fjalën e tretë te shuma më lartë na jep

1011101110110101

1000111100001100

0100101011000010

Vëreni se mbledhja e fundit tejmbushur, e cila ishte e mbyllur. komplementi i parë është bërë duke i kthyer të gjithë zerot në njëshe dhe njëshet në zero. Kështu që komplementi i parë i mbledhjes 0100101011000010 është 1011010100111101, e cila bëhet checksum. Tek pranuesi, të katër fjalët 16 bitëshe mblidhen, duke përfshirë checksum. Nëse asnjë gabim nuk gjendet ne paket, atëherë është e qartë se shuma tek pranuesi do të jetë 1111111111111111. Nëse njëri nga bitët është zero, atëherë ne e dimë se gabimet janë identifikuar ne paket.

Ju mund te mendoni se pse UDP ofron checksum në vend të parë, si shumë protokolle të shtresave të linçeve (duke përfshirë protokollin e njohur Ethernet) që gjithashtu ofrojnë kontroll të gabimeve. Arsyeja është se nuk ka garanci se të gjitha linçet mes burimit dhe destinacionit ofrojnë kontroll të gabimeve; që i bie, njëri nga linçet mund të përdor shtresën e linkut që nuk ofron kontroll të gabimeve. Për më tepër, edhe nëse segmentet janë transferuar me saktësi përmes linkut, është e mundur që gabime në bite mund të paraqiten kur segmenti ruhet në memorie të linjës. Duke pas parasysh që as besueshmëria link me link e as diktimi i gabimeve në memorie nuk janë të garantuara, UDP duhet të ofroj kontroll të gabimeve në shtresë, on an end-end basis, nëse end-end shërbimi i transferit të të dhënave ofron kontroll të gabimeve. Ky është një shembull i festimit të end-end principle në sistemin e dizajnimit [Saltzer 1984], meqë një funksion i caktuar (zbulimi i gabimeve, në këtë rast) duhet të implementohet në end-end basis: “funksionet e vendosura në nivelet e ulëta mund të jen të tepërt ose me rëndësi të vogël kur krahasohen me çmimin e ofrimit të tyre në nivele më të larta.”

Meqë IP supozohet të lëviz mbi çdo shtresë-2 protoco, është e përdorshme për shtresën e transportit që të ofrojë kontroll të gabimeve në masë të sigurt. Megjithëse UDP ofron kontroll të gabimeve, nuk bënë asgjë që të rimarr prej një gabimi. Disa implementë të UDP vetëm e hedhin segmentit e dëmtuar; të tjerat e kalojnë segmentit e dëmtuar në aplikacionin me paralajmërim.

Kjo përfundon diskutimin tonë për UDP. Së shpejti do të shohim se TCP ofron transfero të të dhënave të sigurt te aplikacionet e tij si dhe shërbimeve tjera që UDP nuk i ofron. Natyrisht, TCP është më komplekse se UDP. Para se të diskutojmë TCP, sidoqoftë, do të jetë e dobishme që të lëvizim prapa dhe fillimisht të diskutojmë parimet themelore të transferimit të besueshëm të të dhënave.