Kiedy należy używać UDP zamiast TCP? [zamknięte]

Jeśli pakiet TCP zostanie utracony, będzie to Nie jest to przydatne w przypadku aplikacji, które polegają na przetwarzaniu danych w określonej kolejności w czasie rzeczywistym.

"zawodność" UDP jest formalizmem. Transmisja nie jest absolutnie gwarantowana. W praktyce prawie zawsze przechodzą. Po prostu nie są potwierdzane i sprawdzane ponownie po pewnym czasie.

Koszty w negocjacjach dla gniazda TCP i handshakingu pakietów TCP są ogromne. Naprawdę ogromny. Nie ma znaczącego UDP nad głową.

Co najważniejsze, możesz z łatwością uzupełnić UDP o pewne niezawodne potrząsanie ręką, które jest mniej kosztowne niż TCP. Czytaj to: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP jest przydatny do nadawania informacji w rodzaju publish-subscribe aplikacji. IIRC, TIBCO intensywnie wykorzystuje UDP do powiadamiania o zmianie stanu.

Każdy inny rodzaj jednokierunkowej "znaczącej aktywności" lub "logowania" może być dobrze obsługiwany za pomocą pakietów UDP. Chcesz wysłać powiadomienie bez konstruowania całego gniazda. Nie oczekujesz żadnej odpowiedzi od różnych słuchaczy.

Systemowe komunikaty" heartbeat "lub" I 'm alive" są również dobrym wyborem. Brak jednego to nie kryzys. Brakuje pół tuzina (z rzędu) jest.

Pracuję nad produktem, który obsługuje zarówno komunikację UDP (IP), jak i TCP/IP pomiędzy Klientem a serwerem. Zaczęło się od IPX ponad 15 lat temu z obsługą IP dodaną 13 lat temu. Dodaliśmy obsługę TCP / IP 3 lub 4 lata temu. Wild guess coming up: stosunek kodu UDP do TCP wynosi prawdopodobnie około 80/20. Produkt jest serwerem bazy danych, więc niezawodność ma kluczowe znaczenie. Musimy zająć się wszystkimi problemami narzuconymi przez UDP (utrata pakietów, podwojenie pakietów, kolejność pakietów itp.) już wymienione w innych odpowiedzi. Rzadko zdarzają się problemy, ale czasami występują i dlatego trzeba sobie z nimi poradzić. Zaletą obsługi UDP jest to, że jesteśmy w stanie dostosować go nieco do własnego użytku i poprawić nieco większą wydajność.

Każda sieć będzie inna, ale protokół komunikacyjny UDP jest dla nas nieco szybszy. Sceptyczny czytelnik słusznie zapyta, czy wszystko wdrożyliśmy poprawnie. Plus, czego można oczekiwać od faceta z cyfrą 2 rep? Niemniej jednak, właśnie przeprowadziłem test z ciekawości. Test odczytał 1 milion rekordów (select * from sometable). Ustawiłem liczbę rekordów do zwrotu przy każdym indywidualnym żądaniu klienta na 1, 10, a następnie 100 (trzy biegi testowe z każdym protokołem). Serwer był tylko dwa przeskoki dalej przez 100Mbit LAN. Liczby zdawały się zgadzać z tym, co inni odkryli w przeszłości (UDP jest o 5% szybszy w większości sytuacji). Łączne czasy w milisekundach były następujące dla tego konkretnego test:

1. 1 rekord
   • IP: 390.760 ms
   • TCP: 416,903 ms
2. 10 rekordów
   • IP: 91,707 ms
   • TCP: 95 662 ms
3. 100 rekordów
   • IP: 29,664 ms
   • TCP: 30 968 ms

Całkowita ilość przesłanych danych była mniej więcej taka sama zarówno dla IP, jak i TCP. Mamy dodatkowe koszty z komunikacji UDP, ponieważ mamy niektóre z tych samych rzeczy, które można dostać za "darmo" z TCP / IP (sumy kontrolne, numery sekwencji, itp.). Na przykład Wireshark pokazał, że żądanie kolejnego zestawu rekordów wynosi 80 bajtów z UDP i 84 bajty z TCP.

Jest już wiele dobrych odpowiedzi tutaj, ale chciałbym dodać jeden Bardzo ważny czynnik, a także podsumowanie. UDP może osiągnąć znacznie wyższą przepustowość przy prawidłowym dostrojeniu, ponieważ nie wykorzystuje kontroli zatorów . Kontrola zatorów w TCP jest BARDZO BARDZO Ważne. Kontroluje szybkość i przepustowość połączenia w celu zminimalizowania przeciążenia sieci poprzez próbę oszacowania aktualnej przepustowości połączenia. Nawet gdy pakiety przesyłane są przez bardzo niezawodne łącza, np. w sieci rdzeniowej routery mają bufory o ograniczonej wielkości. Bufory te wypełniają się do swojej pojemności i pakiety są następnie upuszczane, a TCP zauważa ten spadek poprzez brak odebranego potwierdzenia, tym samym ograniczając prędkość połączenia do oszacowania pojemności. TCP wykorzystuje również coś, co nazywa się slow start, ale przepustowość (w rzeczywistości okno zatorów) jest powoli zwiększana, dopóki pakiety nie zostaną upuszczone i jest następnie obniża się i powoli zwiększa ponownie, aż pakiety zostaną upuszczone itp. Powoduje to wahania przepustowości TCP. Widać to wyraźnie po pobraniu dużego pliku.

Ponieważ UDP nie używa kontroli zatorów, może być zarówno szybszy, jak i mniej opóźniony, ponieważ nie będzie dążył do maksymalizacji buforów aż do punktu zrzutu, tzn. pakiety UDP spędzają mniej czasu w buforach i docierają tam szybciej z mniejszym opóźnieniem. Ponieważ UDP nie stosuje kontroli zatorów, ale TCP czy, może odebrać TCP pojemność, która daje przepływy UDP.

UDP jest nadal podatny na zatory i spadki pakietów, więc Twoja aplikacja musi być przygotowana do radzenia sobie z tymi komplikacjami w jakiś sposób, prawdopodobnie za pomocą retransmisji lub kodów korygujących błędy.

Wynik jest taki, że UDP Może:

• Osiągnij wyższą przepustowość niż TCP, o ile szybkość upuszczania sieci mieści się w granicach, które aplikacja może obsłużyć.
• dostarczaj Pakiety szybciej niż TCP z mniejszym opóźnieniem.
• Konfiguruj połączenia szybciej, ponieważ nie ma wstępnego uścisku dłoni, aby skonfigurować połączenie
• transmituje Pakiety multicast, podczas gdy TCP musi używać wielu połączeń.
• transmituje Pakiety o stałym rozmiarze, podczas gdy TCP przesyła dane w segmentach. Jeśli przesyłasz pakiet UDP zawierający 300 bajtów, otrzymasz 300 bajtów na drugim końcu. Z TCP, można karmić Gniazdo wysyłające 300 bajtów, ale odbiornik odczytuje tylko 100 bajtów, i trzeba się jakoś dowiedzieć, że w drodze jest jeszcze 200 bajtów. Jest to ważne, jeśli aplikacja przesyła wiadomości o stałym rozmiarze, a nie strumień bajtów.

Podsumowując, UDP może być używany dla każdego typu aplikacji, które może TCP, o ile zaimplementujesz również odpowiedni mechanizm retransmisji. UDP może być bardzo szybki, ma mniejsze opóźnienie, nie ma wpływu na przeciążenie na zasadzie połączenia, przesyła dane o stałych rozmiarach i może być używany do multicastingu.

UDP ma mniej narzutu i jest dobry do robienia rzeczy takich jak strumieniowanie danych w czasie rzeczywistym, takich jak audio lub wideo, lub w każdym przypadku, gdy jest ok, jeśli dane są utracone.

UDP jest protokołem bezpołączeniowym i jest używany w protokołach takich jak SNMP i DNS , w których pakiety danych przybywające w kolejności są akceptowalne i natychmiastowa transmisja pakietów danych ma znaczenie.

Jest on używany w SNMP, ponieważ zarządzanie siecią musi być często wykonywane, gdy sieć jest w stresie, tj. gdy niezawodny, kontrolowany przeciążeniem transfer danych jest trudny do osiągnięcia.

Jest używany w DNS, ponieważ nie wiąże się z ustanowieniem połączenia, a tym samym Unikanie opóźnień w nawiązywaniu połączenia.

Cheers

Jedna z najlepszych odpowiedzi jakie znam na to pytanie pochodzi od użytkownika zAy0LfpBZLC8mAC w Hacker News . Ta odpowiedź jest tak dobra, że zacytuję ją tak, jak jest.

TCP ma blokowanie head-of-queue, ponieważ gwarantuje pełne i uporządkowane dostawy, więc gdy paczka zgubi się w tranzycie, musi czekać na retransmit brakującego pakietu, natomiast UDP dostarcza pakiety do aplikacji, w tym duplikatów i bez żadnych gwarancja, że a pakiet dociera w całości lub w jakiej kolejności przybywa (to naprawdę jest w zasadzie IP z numerami portów i (opcjonalnie) ładunkiem dodana suma kontrolna), ale jest to w porządku np. dla telefonii, gdzie zwykle po prostu nie ma znaczenia, gdy kilka milisekund dźwięku jest brakuje, ale opóźnienie jest bardzo irytujące, więc nie zawracaj sobie głowy retransmity, po prostu upuszczasz duplikaty, sortujesz zmienione pakiety na odpowiedniej kolejności dla kilkuset milisekund bufora jittera oraz jeśli pakiety nie wyświetlają się się w czasie lub w ogóle, są po prostu pomijane, możliwa interpolacja tam, gdzie jest obsługiwana przez kodek.

Ponadto, główną częścią TCP jest kontrola przepływu, aby upewnić się, że otrzymasz jako dużo througput, jak to możliwe, ale bez przeciążania sieci (co jest trochę zbędny, ponieważ przeciążona sieć upuści twoje pakiety, czyli trzeba by zrobić retransmity, co szkodzi przepustowości), UDP nie ma nic z tego - co ma sens w zastosowaniach takich jak Telefonia, jako Telefonia z danym kodekiem wymaga pewnej ilości przepustowość, nie można "spowolnić", a dodatkowa przepustowość również to nie przyspiesza połączenia.

Oprócz aplikacji w czasie rzeczywistym/o niskim opóźnieniu, UDP ma sens dla naprawdę małych transakcji, takich jak DNS lookups, po prostu dlatego, że nie posiada połączenia TCP i, zarówno pod względem latencji, jak i wykorzystania przepustowości. Jeśli żądanie jest mniejsze niż typowy MTU i repsonse prawdopodobnie jest, możesz również zrobić to w jednej podróży w obie strony, bez konieczności utrzymywania jakiegokolwiek stanu na serwerze, i kontrola przepływu als zamawianie i wszystko to prawdopodobnie nie jest szczególnie przydatny do takich zastosowań.

I wtedy możesz użyć UDP do zbudowania własnych zamienników TCP, z oczywiście, ale to chyba nie jest dobry pomysł bez jakiegoś głębokiego rozumienia dynamiki sieci, nowoczesne algorytmy TCP są dość wyrafinowane.

Również, myślę, że należy wspomnieć, że jest więcej niż UDP i TCP, takich jak SCTP i DCCP. Obecnie jedynym problemem jest to, że (IPv4) internet jest pełen bram NAT, które uniemożliwiają używaj protokołów innych niż UDP i TCP w aplikacjach użytkowników końcowych.

Streaming wideo jest doskonałym przykładem korzystania z UDP.

UDP ma niższy narzut, jak już wspomniano, jest dobry do przesyłania strumieniowego rzeczy takich jak wideo i audio, gdzie lepiej jest po prostu stracić pakiet, a następnie spróbować ponownie wysłać i nadrobić zaległości.

Nie ma gwarancji na dostawę TCP, po prostu powinieneś być poinformowany, czy gniazdo jest odłączone lub zasadniczo, jeśli dane nie dotrą. W przeciwnym razie dotrze tam, kiedy dotrze.

Wielką rzeczą, o której ludzie zapominają, jest to, że udp jest oparty na pakietach, a tcp jest oparty na bytestream, nie ma gwarancja, że "pakiet tcp", który wysłałeś jest pakietem, który pojawia się na drugim końcu, może być podzielony na tyle pakietów, ile żądają routery i stosy. Więc twoje oprogramowanie ma dodatkowy narzut parsowania bajtów z powrotem do użytecznych fragmentów danych, które mogą zająć sporo narzutu. UDP może być nie w porządku, więc musisz numerować pakiety lub użyć innego mechanizmu, aby je ponownie zamówić, jeśli chcesz to zrobić. Ale jak dostajesz ten pakiet udp to przybywa z tymi samymi bajtami w w tej samej kolejności, w jakiej została, bez zmian. Tak więc termin UDP pakiet ma sens, ale pakiet tcp niekoniecznie. TCP ma swój własny mechanizm ponownej próby i zamawiania, który jest ukryty w Twojej aplikacji, możesz go ponownie wymyślić za pomocą UDP, aby dostosować go do swoich potrzeb.

UDP jest o wiele łatwiejszy do napisania kodu na obu końcach, głównie dlatego, że nie musisz tworzyć i utrzymywać połączeń punkt-punkt. Moje pytanie brzmi zazwyczaj, gdzie są sytuacje, w których chcesz, aby TCP overhead? Oraz jeśli korzystasz z skrótów, takich jak założenie, że odebrany pakiet tcp jest kompletnym pakietem, który został wysłany, czy lepiej Ci? (możesz wyrzucić dwa pakiety, jeśli chcesz sprawdzić długość/zawartość)

Komunikacja sieciowa dla gier wideo jest prawie zawsze wykonywana przez UDP.

Szybkość ma ogromne znaczenie i nie ma znaczenia, czy aktualizacje zostaną pominięte, ponieważ każda aktualizacja zawiera pełny aktualny stan tego, co gracz może zobaczyć.

Kluczowe pytanie odnosiło się do "jakie sytuacje UDP byłby lepszym wyborem [nad tcp]"

Istnieje wiele świetnych odpowiedzi powyżej, ale brakuje jakiejkolwiek formalnej, obiektywnej oceny wpływu niepewności transportowej na wydajność TCP.

Wraz z masowym rozwojem aplikacji mobilnych i paradygmatami" od czasu do czasu podłączonymi "lub" od czasu do czasu odłączonymi", są z pewnością sytuacje, w których narzut prób TCP utrzymywanie połączenia, gdy połączenia są trudne do zdobycia, prowadzi do silnej argumentacji dla UDP i jego "zorientowanej na wiadomości" natury.

Teraz nie mam matematyki / badań / liczb na ten temat, ale stworzyłem aplikacje, które działały bardziej niezawodnie przy użyciu i ACK / NAK i numeracji wiadomości przez UDP niż można było osiągnąć z TCP, gdy łączność była ogólnie słaba i biedny stary TCP po prostu spędził czas i pieniądze mojego klienta po prostu próbuje połączyć. Można to uzyskać na obszarach regionalnych i wiejskich wielu kraje zachodnie....

W niektórych przypadkach, które inni podkreślili, gwarantowane przybycie pakietów nie jest ważne, a zatem korzystanie z UDP jest w porządku. Istnieją inne przypadki, w których UDP jest lepszy od TCP.

Jednym z unikalnych przypadków, w którym chcesz użyć UDP zamiast TCP, jest tunelowanie TCP przez inny protokół (np. tunele, sieci wirtualne itp.). Jeśli tunelujesz TCP przez TCP, Kontrola zatorów każdego z nich będzie się ze sobą kolidować. Stąd generalnie woli się tunelować TCP nad UDP (lub jakiś inny protokół bezpaństwowy). Zobacz artykuł TechRepublic: Understanding TCP Over TCP: Effects of TCP Tunneling on End-to-End Throughput and Latency.

UDP może być używany, gdy aplikacja dba bardziej o dane "w czasie rzeczywistym" zamiast dokładnej replikacji danych. Na przykład VOIP może korzystać z UDP i aplikacja będzie martwić się o ponowne zamawianie pakietów, ale w końcu VOIP nie potrzebuje każdego pojedynczego pakietu, ale co ważniejsze potrzebuje ciągłego przepływu wielu z nich. Może tutaj "usterka" w jakości głosu, ale głównym celem jest to, że masz wiadomość, a nie to, że jest odtworzony doskonale po drugiej stronie. UDP jest również stosowany w sytuacjach, w których koszt utworzenia połączenia i synchronizacji z TCP przewyższa obciążenie. Doskonałym przykładem są zapytania DNS. Jeden pakiet z powrotem, jeden pakiet z powrotem, na zapytanie. W przypadku korzystania z TCP byłoby to znacznie bardziej intensywne. Jeśli nie otrzymasz odpowiedzi DNS z powrotem, po prostu spróbuj ponownie.

UDP, gdy wymagana jest szybkość i dokładność, Jeśli Pakiety nie są, i TCP, gdy potrzebujesz dokładności.

UDP jest często trudniejsze, ponieważ musisz napisać swój program w taki sposób, aby nie był zależny od dokładności pakietów.

To nie zawsze jest jasne. Jeśli jednak potrzebujesz gwarantowanej dostawy pakietów bez strat i we właściwej kolejności, TCP jest prawdopodobnie tym, czego chcesz.

Z drugiej strony UDP jest odpowiedni do przesyłania krótkich pakietów informacji, gdzie kolejność informacji jest mniej ważna lub gdzie dane mogą zmieścić się w jednym paczka.

Jest to również odpowiednie, gdy chcesz transmitować te same informacje do wielu użytkowników.

Innym razem, to właściwe podczas wysyłania danych sekwencyjnych, ale jeśli niektóre z nich brakujące nie jesteś zbyt zaniepokojony (np. aplikacja VOIP).

Niektóre protokoły są bardziej złożone, ponieważ potrzebne są niektóre (ale nie wszystkie) funkcje TCP, ale więcej niż zapewnia UDP. Tam warstwa aplikacji musi zaimplementuj dodatkową funkcjonalność. W takich przypadkach odpowiedni jest również UDP(np. radio internetowe, kolejność jest ważna, ale nie każdy pakiet musi się przedostać).

Przykłady gdzie jest/może być używany 1) serwer czasu nadawanie prawidłowego czasu do kilku maszyn w sieci LAN. 2) protokoły VOIP 3) wyszukiwanie DNS 4) Zamawianie usług LAN np. gdzie jesteś? 5) radio internetowe 6) i wiele innych...

W systemie unix możesz wpisać grep udp / etc / services, aby uzyskać listę zaimplementowanych protokołów UDP dzisiaj... są ich setki.

Spójrz na sekcję 22.4 Unix Network Programming, "Kiedy używać UDP zamiast TCP".

Zobacz też ten drugi, więc odpowiedz na błędne przekonanie, że UDP jest zawsze szybszy niż TCP.

To, co mówi Steven, można podsumować następująco:

Jest to jedyna opcja, która pozwala na nadawanie i multicast (używaj multicastu w nowych aplikacjach).]}
• możesz używać UDP do prostych aplikacji do żądania / odpowiedzi, ale musisz zbudować w swoim własne acki, timeouty i retransmisje
• nie używaj UDP do masowego przesyłania danych.

Wiemy, że UDP jest protokołem bezpołączeniowym, więc jest to

1. nadaje się do procesów wymagających prostej komunikacji żądanie-odpowiedź.
2. nadaje się do procesu, który ma wewnętrzny przepływ, kontrola błędów
3. nadaje się do szerokiego odlewania i multicastingu

Konkretne przykłady:

• używany w SNMP
• używany do niektórych protokołów aktualizacji tras, takich jak RIP

Porównując TCP z UDP, protokoły bez połączenia, takie jak UDP zapewniają szybkość, ale nie niezawodność transmisji pakietowej. Na przykład w grach wideo zazwyczaj nie potrzebują niezawodnej sieci, ale szybkość jest najważniejsza, a korzystanie z UDP dla gier ma tę zaletę, że zmniejsza opóźnienie sieci.

Chcesz używać UDP przez TCP w przypadkach, gdy utrata niektórych danych po drodze nie zrujnuje całkowicie przesyłanych danych. FPS, gdzie nie zawsze musisz wiedzieć, gdzie każdy gracz jest w danym momencie, a jeśli stracisz kilka pakietów po drodze, nowe dane i tak poprawnie powiedzą, gdzie są gracze) i strumieniowanie wideo w czasie rzeczywistym (jedna uszkodzona Ramka nie zrujnuje oglądania doświadczenie).

Mamy serwis internetowy, który ma tysiące klientów winforms na tylu komputerach. Komputery nie mają połączenia z zapleczem DB, cały dostęp odbywa się za pośrednictwem usługi internetowej. Zdecydowaliśmy się więc na stworzenie centralnego serwera rejestrującego, który nasłuchuje na porcie UDP, a wszyscy klienci wysyłają pakiet dziennika błędów xml (używając log4net UDP appender), który po otrzymaniu jest wysyłany do tabeli DB. Ponieważ tak naprawdę nie obchodzi nas, czy kilka dzienników błędów zostanie pominiętych, a z tysiącami klientów jest to szybkie dzięki dedykowanej usłudze rejestrowania, nie Ładowanie głównego serwisu www.

Jestem trochę niechętny sugerowaniu UDP, kiedy TCP może działać. Problem polega na tym, że jeśli TCP nie działa z jakiegoś powodu, ponieważ połączenie jest zbyt opóźnione lub przeciążone, Zmiana aplikacji na UDP raczej nie pomoże. Złe połączenie jest złe również dla UDP. TCP już bardzo dobrze radzi sobie z minimalizowaniem zatorów.

Jedyny przypadek, w którym wymagany jest UDP, to protokoły transmisji. W przypadkach, gdy aplikacja obejmuje dwa, Znane hosty, UDP będzie prawdopodobnie oferują jedynie marginalne korzyści w zakresie wydajności przy znacznie zwiększonych kosztach złożoności kodu.

Używaj UDP tylko wtedy, gdy naprawdę wiesz, co robisz. UDP jest dziś w niezwykle rzadkich przypadkach, ale liczba (nawet bardzo doświadczonych) ekspertów, którzy staraliby się trzymać go wszędzie, wydaje się być nieproporcjonalna. Być może sami lubią implementować kod obsługi błędów i konserwacji połączenia.

TCP powinien być znacznie szybszy dzięki nowoczesnym kartom interfejsu sieciowego ze względu na tzw. Zaskakująco, przy dużych prędkościach połączenia (takich jak 1Gbps) obliczanie sumy kontrolnej byłoby dużym obciążeniem dla procesora, więc jest ono odciążone na sprzęcie NIC , który rozpoznaje pakiety TCP do odcisku i nie zaoferuje ci tej samej usługi.

UDP jest idealnym rozwiązaniem dla adresów VoIP, gdzie pakiety danych muszą być wysłane ze względu na mniejszą ich niezawodność... Wideo czat jest przykładem UDP (można to sprawdzić przez Wireshark przechwytywania sieci podczas dowolnego czatu wideo).. Również TCP nie działa z protokołami DNS i SNMP. UDP nie ma żadnego narzutu, podczas gdy TCP ma wiele narzutu