Kada patartina naudoti UDP vietoj TCP?

Kadangi TCP garantuoja paketų pristatymą ir todėl gali būti laikomas patikimu, UDP negarantuoja nieko, o paketai gali būti prarasti. Kokie būtų privalumai perduodant duomenis naudojant UDP, o ne per TCP srautą? Kokiais atvejais UDP yra geriausias pasirinkimas ir kodėl?

Darau prielaidą, kad UDP yra greitesnis, nes jis neturi srauto kūrimo ir palaikymo pridėtinės vertės, bet ar tai būtų netinkama, jei kai kurie duomenys niekada nepasiekė savo tikslo?

252
08 июля '09 в 21:04 2009-07-08 21:04 Jeffas L paklausė liepos 8 d. 09:21 21:04 2009-07-08 21:04
@ 24 atsakymai

Tai vienas iš mano mėgstamiausių klausimų. UDP yra taip nesuprastas.

Tais atvejais, kai tikrai norite greitai gauti paprastą atsakymą į kitą serverį, UDP geriausiai veikia. Apskritai norite, kad atsakymas būtų įtrauktas į tą patį atsakymo paketą, ir esate pasiruošę įgyvendinti savo protokolą, kad būtų užtikrintas patikimumas arba išsiųstas. DNS yra puikus šio naudojimo atvejo aprašymas. Ryšio parametrų kaina yra per didelė (tačiau DNS taip pat palaiko TCP režimą).

Kitas atvejis yra, kai siunčiate duomenis, kurie gali būti prarasti, nes nauji duomenys bus pakeisti ankstesniais duomenimis. Prisimenama apie oro duomenis, srautinį vaizdo įrašą, akcijų citavimo paslaugą (nenaudojama gyvai prekybai) arba žaidimo duomenis.

Kitas atvejis yra tada, kai valdote didžiulį kiekį valstybių, ir norite išvengti TCP naudojimo, nes OS negali apdoroti daugelio sesijų. Šiandien tai retas atvejis. Tiesą sakant, dabar yra naudotojo žemės TCP kaminai, kurie gali būti naudojami taip, kad programos rašytojas galėtų kontroliuoti išteklius, reikalingus šiai TCP būsenai. Iki 2003 m. UDP buvo tikras žaidimas mieste.

Kitas daugiaadresio srauto atvejis. UDP gali būti daugialypė daugeliui kompiuterių, tuo tarpu TCP negali to padaryti.

290
08 июля '09 в 21:15 2009-07-08 21:15 atsakymas pateikiamas drudru liepos 08 d. 09:21:15 2009-07-08 21:15

Jei TCP paketas yra prarastas, jis bus iš naujo. Tai netinka toms programoms, kurios realiu laiku remiasi tam tikra tvarka tvarkomais duomenimis.

Pavyzdžiui, vaizdo transliacija ir ypač VoIP (pvz., „ Skype“ ). Tačiau šiais atvejais atsisakyta pakuotė nėra toks didelis dalykas: mūsų jausmai nėra tobuli, todėl negalime jų net nepastebėti. Štai kodėl šie tipai naudoja UDP vietoj TCP.

52
08 июля '09 в 21:08 2009-07-08 21:08 atsakymas pateikiamas Stephan202 liepos 08 '09, 21:08 2009-07-08 21:08

UDP „nesaugumas“ yra formalizmas. Perdavimas negarantuojamas. Kaip praktinis klausimas, jie beveik visada praeina. Jie tiesiog nepripažįstami ir kartojami po laiko.

Derybos dėl TCP lizdo ir bendravimas su TCP paketais yra didžiulės. Tikrai didžiulis. Nėra pastebimos UDP pridėtinės vertės.

Svarbiausia, kad jūs galite lengvai pridėti UDP su patikimu rankų pristatymu, kuris yra mažesnis nei TCP. Skaitykite: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP yra naudinga transliuojant informaciją skelbimo ir prenumeratos programoje. IIRC, TIBCO aktyviai naudoja UDP, kad praneštų apie darbuotojų keitimą.

Bet kuris kitas vienakryptis „reikšmingas įvykis“ arba „registravimas“ gali būti apdorojamas naudojant UDP paketus. Norite siųsti pranešimą, nesukuriant viso lizdo. Negalite tikėtis atsakymų iš skirtingų klausytojų.

Širdies plakimas arba aš gyvas pranešimas taip pat yra geras pasirinkimas. Vieno nebuvimas nėra krizė. Pusė tuzino trūksta (iš eilės).

49
08 июля '09 в 21:08 2009-07-08 21:08 atsakymą pateikė S.Lott liepos 08'09 , 21:08 2009-07-08 21:08

Dirbu su produktu, kuris palaiko tiek UDP (IP), tiek TCP / IP ryšį tarp kliento ir serverio. Jis buvo pradėtas nuo IPX prieš 15 metų, o IP parama buvo pridėta prieš 13 metų. Prieš 3 ar 4 metus pridėjome TCP / IP palaikymą. Laukinis atspėjimas: UDP ir TCP kodo santykis tikriausiai yra maždaug 80/20. Produktas yra duomenų bazės serveris, todėl patikimumas yra labai svarbus. Mes turime spręsti visas problemas, kurias kelia UDP (paketų praradimas, paketų dubliavimasis, paketų užsakymas ir kt.), Jau paminėtas kituose atsakymuose. Retai kyla problemų, tačiau kartais jos kyla ir todėl turi būti sprendžiamos. UDP palaikymo pranašumas yra tai, kad mes galime šiek tiek pritaikyti jį savo naudojimui ir pagerinti jo našumą.

Kiekvienas tinklas bus kitoks, tačiau UDP ryšio protokolas mums paprastai yra šiek tiek greitesnis. Skeptiškas skaitytojas teisingai iškels klausimą, ar mes padarėme viską teisingai. Be to, ką galite tikėtis iš dviejų skaitmenų vaikino? Tačiau aš tiesiog išbandiau smalsumą. Bandymas perskaito 1 mln. Įrašų (pasirinkite * iš kartais). Nustatau, kiek įrašų norite grąžinti su kiekvienu atskiru kliento prašymu 1, 10 ir 100 (trys bandymai atliekami su kiekvienu protokolu). Serveris buvo tik du skrydžiai per 100 megabitų vietinį tinklą. Skaičiai sutampa su tuo, ką kiti rado praeityje (daugeliu atvejų UDP yra 5% greičiau). Bendras milisekundžių skaičius šiam konkrečiam bandymui buvo toks:

  • 1 įrašas
    • IP: 390,760 ms
    • TCP: 416.903 ms
  • 10 įrašų
    • IP: 91,707 ms
    • TCP: 95,662 ms
  • 100 įrašų
    • IP: 29,664 ms
    • TCP: 30.968 ms

Bendras perduotų duomenų kiekis IP ir TCP buvo maždaug toks pat. Turime papildomą pridėtinę vertę su UDP ryšiais, nes mes turime tuos pačius dalykus, kuriuos gausite „nemokamai“ su TCP / IP (kontrolinės sumos, sekos numeriai ir tt). Pavyzdžiui, Wireshark parodė, kad kito įrašų rinkinio užklausa buvo 80 baitų su UDP ir 84 baitais su TCP.

24
09 июля '09 в 1:06 2009-07-09 01:06 Mark Wilkins atsakymas liepos 9 d. 09 d. 1:06 am. 2009-07-09 01:06

UDP yra nesusijęs protokolas ir yra naudojamas tokiose programose kaip SNMP (Simple Network Management Protocol), DNS (domeno vardų sistema), kur duomenų paketai yra neveiksmingi, nepatikimi ir netrukdomi, ir nedelsiant perduodamas duomenų paketas ...

Kadangi UDP nereikalauja ryšio, prieš tokias programas kaip DNS, kur reikia išvengti ryšio, UDP yra geriau nei TCP.

Naudojamas SNMP, nes tinklo valdymas dažnai yra būtinas norint atlikti tinklo veikimą, ty kai sunku perduoti patikimą duomenų perkrovą.

nudžiugina

15
08 июля '09 в 21:10 2009-07-08 21:10 atsakymą pateikė „ Arnkrishn“ liepos 8 d. 09:21 21:10 2009-07-08 21:10

Čia jau yra daug gerų atsakymų, bet norėčiau pridėti vieną labai svarbų veiksnį ir santrauką. UDP gali pasiekti daug didesnį pralaidumą tinkama konfigūracija, nes nenaudoja perkrovos kontrolės. TCP perkrovos valdymas yra labai svarbus. . Ji kontroliuoja ryšio greitį ir pralaidumą, kad sumažintų tinklo perkrovą, bandant įvertinti dabartinį ryšio pajėgumą. Net kai paketai siunčiami labai patikimais ryšiais, pavyzdžiui, pagrindiniame tinkle, maršrutizatoriai turi ribotus buferius. Šie buferiai yra pripildyti jų pajėgumais, o tada paketai nuleidžiami, o TCP praneša apie sumažėjimą dėl gauto patvirtinimo trūkumo ir sumažina ryšio greitį, kad būtų galima įvertinti pajėgumą. TCP taip pat naudoja kažką vadinamą lėtą pradžią, tačiau dažnių juostos plotis (iš tikrųjų perkrovos >

Kadangi UDP nenaudoja perkrovos kontrolės, jis gali būti greitesnis ir lėtesnis, nes nesiekia maksimaliai padidinti buferių iki kritimo taško, tai yra, UDP paketai praleidžia mažiau laiko buferiams ir greičiau eina greičiau su mažesniu vėlavimu. Kadangi UDP nenaudoja perkrovos valdymo, tačiau TCP tai daro, ji gali pašalinti dažnių juostos plotį iš TCP, o tai reiškia UDP srautus.

UDP vis dar yra pažeidžiamas perkrovos ir paketų lašų atžvilgiu, todėl jūsų paraiška turėtų būti pasirengusi tvarkyti šiuos mažesnius nuostolius kiek įmanoma mažiau, tikriausiai naudojant retransliavimo ar klaidų taisymo kodus.

Todėl UDP gali:

  • Suteikti didesnį dažnių juostos plotį nei TCP, kol tinklo sumažėjimo greitis neviršys ribų, kurias gali taikyti programa.
  • Paketų pristatymas yra greitesnis nei TCP su mažiau latentiniu laiku.
  • Nustatykite ryšius greičiau, nes nėra jokio pradinio ryšio konfigūruoti ryšį.
  • Persiųskite daugiaadresių paketus, o TCP turi naudoti kelis ryšius.
  • Perduoti fiksuoto dydžio paketus, o TCP perduoda duomenis segmentuose. Jei siunčiate 300 baitų UDP paketą, kitame gale gausite 300 baitų. Naudodami TCP, galite siųsti 300 baitų siuntimo lizdą, tačiau imtuvas nuskaito tik 100 baitų, ir jūs turite kažkaip sužinoti, kad 200 maršrutų yra daugiau. Tai svarbu, jei jūsų programa siunčia fiksuoto dydžio pranešimus, o ne baitų srautą.

Taigi, UDP gali būti naudojamas visų tipų programoms, kurios gali būti TCP, jei taip pat įgyvendinate teisingą retransliavimo mechanizmą. UDP gali būti labai greitas, mažas latentinis laikotarpis, nepriklausomas nuo ryšio perkrovos, perduoda fiksuoto dydžio datagramas, ir gali būti naudojamas daugiaadresiui.

12
27 дек. Atsakymą pateikė Andy 27 d. 2015-12-27 00:10 '15 - 0:10 2015-12-27 00:10

UDP turi mažesnę pridėtinę vertę ir yra naudinga, pavyzdžiui, transliuoja realaus laiko duomenis, pvz., Garso ar vaizdo įrašus, arba kai tai yra normalu, jei duomenys prarandami.

12
08 июля '09 в 21:07 2009-07-08 21:07 atsakymą pateikė Dana Holt liepos 08 d. 09: 21: 07 2009-07-08 21:07

Vienas iš geriausių atsakymų, kuriuos žinau šiam klausimui, kyla iš vartotojo „zAy0LfpBZLC8mAC“ „Hacker News“ . Šis atsakymas yra toks geras, kad aš tiesiog cituoju jį taip.

TCP yra eilės antraštės užraktas, nes jis garantuoja pilną ir tvarkingą pristatymą, todėl, kai paketas praranda kelią, jis turi laukti, kol trūkstamas paketas bus retransliuojamas, o UDP siunčia paketus, kai jie atvyksta, įskaitant dublikatus ir be jokių garantijų kad paketas bus visiškai pasiekiamas arba kokia tvarka jie bus pristatyti (tai iš esmės yra IP su prievadų numeriais ir (neprivaloma) naudingosios apkrovos kontroline suma), tačiau tai yra įprasta telefonijai, pavyzdžiui, kai ji paprastai nesvarbu Kai nėra keleto milisekundžių garso, tačiau vėlavimas yra labai erzina, todėl nerimaujate persiųsti, tiesiog paliekate bet kokius dublikatus, rūšiuoti pakeistus paketus į kelis šimtus milisekundžių nervų buferio, o jei paketai nerodomi laiku ar apskritai, jie tiesiog praleidžiami gali būti interpoliuojamas, kai to palaiko kodekas.

Be to, pagrindinė TCP dalis yra srauto kontrolė, kad įsitikintumėte, jog jūs gaunate kuo daugiau, bet be tinklo perkrovos (tai yra nereikalinga, nes perkrautas tinklas sumažins jūsų paketus, o tai reiškia, kad turite atlikti pakartotinius siuntimus, todėl pralaidumas), UDP neturi nieko, kas būtų naudinga tokioms programoms kaip telefonija, nes telefonijai su šiuo kodeku reikia tam tikro dažnių juostos pločio, jūs negalite „sulėtinti“ ir papildomų pralaidumas taip pat nespartina skambučio.

Be nuolatinių ir mažų latentinių programų, UDP yra prasminga labai mažiems sandoriams, pvz., DNS užklausoms, paprasčiausiai todėl, kad jie neturi TCP ryšio ir išlaidų, nustatytų tiek latentiniu, tiek pralaidumo požiūriu. pralaidumo. Jei jūsų prašymas yra mažesnis už tipišką MTU, o galbūt ir atsakymas, galite tai padaryti viena atvirkštine kryptimi, nereikalaudami jokios būsenos serveryje ir srauto valdymo, taip pat tvarkos ir visko, kas neįmanoma naudinga.

Ir tada jūs galite naudoti UDP, kad galėtumėte sukurti savo TCP pakeitimus, žinoma, tačiau tai tikriausiai nėra gera idėja be gilaus tinklo dinamikos supratimo, šiuolaikiniai TCP algoritmai yra gana sudėtingi.

Be to, manau, kad reikėtų paminėti, kad yra daugiau nei UDP ir TCP, pavyzdžiui, SCTP ir DCCP. Šiuo metu vienintelė problema yra ta, kad (IPv4) internetas yra pilnas NAT šliuzų, todėl neįmanoma naudoti kitų nei UDP ir TCP protokolų galutinių vartotojų programose.

12
09 марта '14 в 11:22 2014-03-09 11:22 atsakymas duotas ShitalShah kovo 9 d. 14 val. 11:22 2014-03-09 11:22

UDP turi mažesnę pridėtinę vertę, kaip jau minėta, tai yra naudinga transliuoti tokius dalykus kaip vaizdo ir garso įrašai, kur geriau tik prarasti paketą ir tada bandyti siųsti ir pasivyti.

Nėra jokių TCP pristatymo garantijų, tiesiog reikia pasakyti, ar lizdas yra atjungtas, ar dažniausiai, jei duomenys nėra gauti. Priešingu atveju jis ten patenka, kai jis ten patenka.

Didžioji problema, kurią žmonės pamiršo, yra tai, kad „udp“ yra pagrįstas paketais, o „tcp“ yra pagrįsta sraute, nėra jokių garantijų, kad siunčiamas „tcp“ paketas yra paketas, kuris rodomas kitame gale, galite jį suskaidyti į daugelį paketų, kiek maršrutizatorių ir kaminų jie nori. Taigi, jūsų programinė įranga turi papildomas pridėtines išlaidas baitams grąžinti į tinkamus duomenų fragmentus, kuriems gali prireikti pakankamai pridėtinių. UDP gali būti neveiksmingas, taigi jums reikės suskirstyti paketus arba naudoti kitą mechanizmą, jei norite. Bet jei jūs gaunate šį udp paketą, jis ateina su visais tais pačiais baitais ta pačia tvarka, kuria jis lieka, be jokių pakeitimų. Taigi terminas „udp-package“ yra prasmingas, tačiau TCP paketas nėra būtinas. TCP turi savo pakartotinio bandymo ir užsakymo mechanizmą, kuris yra paslėptas nuo jūsų paraiškos, galite ją išradinėti su UDP, kad pritaikytumėte ją prie savo poreikių.

Abiejuose galuose UDP yra daug lengviau rašyti kodą, daugiausia todėl, kad nereikia kurti ir palaikyti taškų nuo taško. Mano klausimas paprastai yra, kur yra situacijos, kuriose norite TCP pridėtinės? O jei sutinkate su sparčiaisiais klavišais, pavyzdžiui, jei gaunate TCP paketą, „paketas“ yra visas paketas, kuris buvo išsiųstas, ar tai jums geriau? (tikriausiai išmeskite du paketus, jei nerimaujate patikrinti ilgį / turinį)

8
08 июля '09 в 21:30 2009-07-08 21:30 atsakymas pateikiamas senas_timeris liepos 08 '09, 21:30, 2009-07-08 21:30

Vaizdo transliacija yra puikus UDP naudojimo pavyzdys.

6
08 июля '09 в 21:05 2009-07-08 21:05 Atsakymą pateikė Daniel A. White liepos 08'09, 21:05 2009-07-08 21:05

Vaizdo žaidimų tinklų kūrimas beveik visada atliekamas per UDP.

Greitis yra nepaprastai svarbus, ir iš tikrųjų tai nesvarbu, ar atnaujinimai praleidžiami, nes kiekviename atnaujinime yra visa dabartinė žaidėjo matoma būsena.

3
08 июля '09 в 21:16 2009-07-08 21:16 atsakymas pateiktas 17 iš 26 liepos 08 d. 21:16 2009-07-08 21:16

Kai kuriais atvejais kiti nustatė, kad garantuotas paketų atvykimas nėra svarbus, todėl UDP naudojimas yra gerai. Yra ir kitų atvejų, kai UDP yra geriau nei TCP.

Vienas unikalus atvejis, kai norite naudoti UDP vietoj TCP, yra TCP tuneliavimas per kitą protokolą (pvz., Tuneliai, virtualūs tinklai ir tt). Jei tuneliuojate TCP per TCP, kiekviena perkrovos kontrolė trukdo viena kitai. Todėl dažniausiai pirmenybė teikiama TCP per UDP (arba kitą be pilietybės protokolą). Žr. „TechRepublic“ straipsnį: TCP per TCP apžvalga: TCP tunelių poveikis galutiniam ir baigiamam srautui ir vėlavimui .

3
08 июля '09 в 21:41 2009-07-08 21:41 atsakė Brianui M. Huntui liepos 08'09, 21:41 2009-07-08 21:41

Pagrindinis klausimas buvo susijęs su „kokiomis situacijomis UDP būtų geriausias pasirinkimas pagal„ tcp “

Yra daug puikių atsakymų, tačiau nėra oficialaus objektyvaus transporto neapibrėžtumo poveikio TCP veikimui vertinimo.

Su dideliu mobiliųjų programų augimu ir su jais susijusiomis „atsitiktinai prijungtomis“ arba „atsitiktinai atjungtomis“ paradigmomis yra tam tikrų situacijų, kai TCP viršutinė dalis bando palaikyti ryšį, kai sunku rasti UDP ir jos „orientuotus“ ryšius. pranešime ".

Dabar neturiu matematikos / studijų / numerių, bet sukūriau programas, kurios patikimesniu būdu naudoja ACK / NAK ir UDP pranešimų numeravimą, nei galima pasiekti naudojant TCP, kai ryšys buvo blogas ir blogas senas TCP Šį kartą praleidau, o mano kliento pinigai tiesiog bando prisijungti. Jūs gaunate jį daugelio Vakarų šalių regioninėse ir kaimo vietovėse ...

3
21 дек. Rob Von Nesselrode atsakymas, pateiktas gruodžio 21 d. 2011-12-21 12:23 '11 12:23 PM 2011-12-21 12:23

UDP gali būti naudojamas, kai programa daugiau rūpinasi „realaus laiko“ duomenimis, o ne tiksliai kopijuoja duomenis. Pavyzdžiui, „VOIP“ gali naudoti UDP, o programa bus nerimaujama dėl paketų pertvarkymo, tačiau VOIP pabaigoje kiekvienas atskiras paketas nereikalingas, tačiau, dar svarbiau, reikalingas nuolatinis daugelio jų srautas. Galbūt jūs „nesugeba“ balsuoti čia, bet pagrindinis tikslas yra, kad gautumėte pranešimą, o ne, kad jis būtų visiškai atkurtas iš kitos pusės. UDP taip pat naudojamas tais atvejais, kai ryšio kūrimo ir sinchronizavimo su TCP išlaidos yra didesnės už naudingąją apkrovą. DNS užklausos yra puikus pavyzdys. Vienas paketas, vienas paketas atgal, už kiekvieną užklausą. Если использовать TCP, это будет намного более интенсивным. Если вы не вернете ответ DNS, просто повторите попытку.

2
Atsakymas yra RC. 08 июля '09 в 21:12 2009-07-08 21:12