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

302

Ponieważ TCP gwarantuje dostarczanie pakietów, a zatem może być uważany za „niezawodny”, podczas gdy UDP nie gwarantuje niczego i pakiety mogą zostać utracone. Jaka byłaby zaleta przesyłania danych przy użyciu UDP w aplikacji zamiast w strumieniu TCP? W jakich sytuacjach UDP byłby lepszym wyborem i dlaczego?

Zakładam, że UDP jest szybszy, ponieważ nie ma narzutu związanego z tworzeniem i utrzymywaniem strumienia, ale czy nie byłoby to bez znaczenia, gdyby niektóre dane nigdy nie dotarły do ​​miejsca docelowego?

Jeff L.
źródło
55
Oprócz możliwości utraty pakietów, UDP nie gwarantuje, że pakiet otrzymasz tylko raz. Jeśli masz zawiłe lub źle skonfigurowane sieci, możesz odebrać ten sam pakiet wiele razy. Tylko jedna głowa, ponieważ ludzie często o tym zapominają!
Brian Agnew
3
Nie gwarantuje nawet zamawiania pakietów.
Mehrdad Afshari
19
TCP nie gwarantuje dostarczenia , po prostu gwarantuje, że jeśli będzie w stanie dostarczyć pakiety, będą w tej samej kolejności, w jakiej zostały wysłane.
Chaim Geretz,
5
BTW, często widzę, że ludzie utożsamiają niezawodność / dostawę w kolejności do retransmisji TCP. Ci „eksperci” powiedzą ci, że aby przezwyciężyć błędy transmisji na UDP, ponownie zaimplementujesz TCP (źle) i dlatego równie dobrze możesz użyć TCP. To nie jest prawda. Istnieją inne techniki odzyskiwania błędów poza retransmisją, które nie cierpią z powodu opóźnień lub wykładniczo zmniejszonej przepustowości w wyniku małych, ale niezerowych poziomów błędów.
Ben Voigt
TCP gwarantuje również, że będziesz wiedzieć, czy miejsce docelowe nie otrzymało pakietów.
csga5000,

Odpowiedzi:

353

To jedno z moich ulubionych pytań. UDP jest tak źle zrozumiany.

W sytuacjach, gdy naprawdę chcesz szybko uzyskać prostą odpowiedź na inny serwer, UDP działa najlepiej. Ogólnie rzecz biorąc, chcesz, aby odpowiedź znajdowała się w jednym pakiecie odpowiedzi, i jesteś przygotowany na wdrożenie własnego protokołu w celu zapewnienia niezawodności lub ponownego wysłania. DNS jest doskonałym opisem tego przypadku użycia. Koszty konfiguracji połączeń są zbyt wysokie (jednak DNS obsługuje również tryb TCP).

Innym przypadkiem jest dostarczanie danych, które mogą zostać utracone, ponieważ nadchodzące nowsze dane zastąpią poprzednie dane / stan. Przychodzą na myśl dane pogodowe, streaming wideo, notowania giełdowe (nie wykorzystywane do faktycznego handlu) lub dane z gier.

Innym przypadkiem jest zarządzanie ogromną ilością stanów i unikanie używania protokołu TCP, ponieważ system operacyjny nie obsługuje tak wielu sesji. To dzisiaj rzadki przypadek. W rzeczywistości istnieją teraz stosy TCP dla użytkowników, dzięki którym program piszący aplikacje może mieć dokładniejszą kontrolę nad zasobami potrzebnymi dla tego stanu TCP. Przed 2003 rokiem UDP była naprawdę jedyną grą w mieście.

Innym przypadkiem jest ruch multiemisji. UDP może być multiemitowany na wielu hostach, podczas gdy TCP nie może tego w ogóle zrobić.

drudru
źródło
Dzięki za ciekawą odpowiedź. Serwer obecnie robi wszystko w UDP (wymaganie wysokiej przepustowości), co jest w porządku, ponieważ naprawdę jest jeden przeskok (wyłączony routing, ...), ale zauważyliśmy, że zmiana kolejności pakietów może stać się problemem w przypadku niektórych wadliwych kart sieciowych. Jaki stos TCP w trybie użytkownika (lub inny sterowany przepływem w trybie użytkownika) sugerujesz?
dashy
@dashesy - czy możesz pozbyć się wymogu zamawiania? Czy w ładunku znajduje się monotonicznie rosnąca liczba, której można użyć? Jeśli tak, to tak naprawdę nie potrzebujesz w pełni rozwiniętego stosu TCP lądu użytkownika.
drudru
@ drudru- tak, tam jest numer sekwencyjny, być może będę musiał sam buforować i usuwać jitter. Dzięki wyeliminowanie jeszcze jednej opcji jest zawsze świetne.
dashy
63

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

Przykłady obejmują strumieniowe przesyłanie wideo, a zwłaszcza VoIP (np. Skype ). W takich przypadkach jednak upuszczony pakiet nie jest tak wielkim problemem: nasze zmysły nie są doskonałe, więc możemy nawet nie zauważyć. Właśnie dlatego tego typu aplikacje używają UDP zamiast TCP.

Stephan202
źródło
16
Myślę, że masz to wstecz. TCP ponownie zamawia pakiety, aby dane były dostarczane w wysłanej kolejności. UDP nie zmienia kolejności i dostarcza dane w dowolnej kolejności, w jakiej je otrzymano.
Hans MALHERBE
1
UDP nie gwarantuje kolejności, można jednak ponumerować pakiety i zmienić ich kolejność po ich odzyskaniu.
Kugel
7
@ Stephan202: Myślę, że musiałbym się nie zgodzić, że nie zauważyłem upuszczonych pakietów na Skypie ;-)
Robert S. Barnes
6
@Kugel: Uważaj tylko, że możesz wdrożyć nowy stos TCP. W tym momencie raczej nie wykonasz lepszej pracy niż system operacyjny.
erikkallen
1
@erikkallen: Gdyby używać protokołu UDP do implementacji protokołu wyższego poziomu o tych samych wymaganiach, które TCP miał spełnić, mało prawdopodobne byłoby, aby działał znacznie lepiej niż istniejące protokoły. Z drugiej strony niektóre aplikacje korzystają z dodania do protokołu kilku funkcji, które lepiej byłoby obsługiwać przez opakowanie UDP niż TCP.
supercat,
56

„Niewiarygodność” UDP jest formalizmem. Transmisja nie jest absolutnie gwarantowana. W praktyce prawie zawsze się przedostają. Po prostu nie są potwierdzane i ponawiane po upływie limitu czasu.

Narzut związany z negocjowaniem gniazda TCP i uzgadnianiem pakietów TCP jest ogromny. Naprawdę ogromny. Nie ma znaczącego narzutu UDP.

Co najważniejsze, możesz łatwo uzupełnić UDP o pewne niezawodne uzgadnianie dostawy, które jest mniej narzutowe niż TCP. Przeczytaj to: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP jest przydatny do rozpowszechniania informacji w aplikacji typu publikuj-subskrybuj. IIRC, TIBCO intensywnie wykorzystuje UDP do powiadamiania o zmianie stanu.

Każdy inny rodzaj „znaczącego zdarzenia” lub „rejestrowania” w jedną stronę można ładnie obsługiwać za pomocą pakietów UDP. Chcesz wysłać powiadomienie bez budowania całego gniazda. Nie oczekujesz żadnej odpowiedzi od różnych słuchaczy.

Systemowe komunikaty „bicie serca” lub „Jestem żywy” również są dobrym wyborem. Brak jednego nie jest kryzysem. Brakuje pół tuzina (z rzędu).

S.Lott
źródło
5
„W praktyce prawie zawsze się przedostają”. W dużym stopniu zależy od niższej niezawodności warstw sieciowych.
m0skit0 17.04.16
poza tym, czy istnieje różnica między planowaniem utraty „kilku” pakietów a „zbyt dużą” utratą pakietów? strata to strata. i tak musisz to zaplanować.
Sedat Kapanoglu
30

Pracuję nad produktem obsługującym zarówno komunikację UDP (IP), jak i TCP / IP mię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. Zbliżają się dzikie przypuszczenia: stosunek kodu UDP do TCP wynosi prawdopodobnie około 80/20. Produkt jest serwerem bazy danych, więc niezawodność ma kluczowe znaczenie. Musimy poradzić sobie ze wszystkimi problemami narzuconymi przez UDP (utrata pakietów, podwojenie pakietów, kolejność pakietów itp.), Które zostały już wspomniane w innych odpowiedziach. Rzadko występują problemy, ale czasem się zdarzają i dlatego należy je rozwiązać. Zaletą obsługi protokołu UDP jest to, że jesteśmy w stanie go nieco dostosować do własnych potrzeb i poprawić nieco wydajność.

Każda sieć będzie inna, ale protokół komunikacyjny UDP jest dla nas nieco szybszy. Sceptyczny czytelnik słusznie zapyta, czy wszystko zaimplementowaliśmy poprawnie. Plus, czego możesz oczekiwać od faceta z 2-cyfrowym powtórzeniem? Niemniej jednak właśnie przeprowadziłem test z ciekawości. Test odczytał 1 milion rekordów (wybierz * z jakiegoś). Ustawiam liczbę rekordów zwracanych przy każdym indywidualnym żądaniu klienta na 1, 10, a następnie 100 (trzy testy z każdym protokołem). Serwer znajdował się w odległości zaledwie dwóch przeskoków w sieci LAN o przepustowości 100 Mb. Liczby wydawały się zgadzać z tym, co inni odkryli w przeszłości (UDP jest około 5% szybszy w większości sytuacji). Całkowity czas w milisekundach dla tego konkretnego testu był następujący:

  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

Łączna ilość przesłanych danych była mniej więcej taka sama dla obu adresów IP i TCP. Mamy dodatkowy narzut związany z komunikacją UDP, ponieważ mamy te same rzeczy, które otrzymujesz za darmo z TCP / IP (sumy kontrolne, numery sekwencyjne itp.). Na przykład Wireshark wykazał, że żądanie następnego zestawu rekordów wynosi 80 bajtów w przypadku UDP i 84 bajtów w przypadku TCP.

Mark Wilkins
źródło
Co jeśli opracowałbyś go tylko dla TCP i kupiłeś lepszy sprzęt zamiast 5-krotnie większego wysiłku w zakresie kodowania?
inf3rno
2
Dzięki za konkretne liczby! 5% poprawa jest nieco rozczarowująca złożonością, którą dodaje.
Siergiej
1
Prawdopodobnie 5% jest, ponieważ jest wysyłane w sieci lokalnej (dwie nadzieje dalej)? Domyślam się, że im dalej, tym większa różnica.
lepe
19

Istnieje już wiele dobrych odpowiedzi, ale chciałbym dodać jeden bardzo ważny czynnik, a także streszczenie. UDP może osiągnąć znacznie wyższą przepustowość przy prawidłowym strojeniu, ponieważ nie stosuje kontroli przeciążenia . Kontrola przeciążenia w TCP to bardzo, bardzoważny. Kontroluje szybkość i przepustowość połączenia w celu zminimalizowania przeciążenia sieci, próbując oszacować bieżącą pojemność połączenia. Nawet gdy pakiety są wysyłane przez bardzo niezawodne łącza, na przykład w sieci rdzeniowej, routery mają bufory o ograniczonym rozmiarze. Bufory te wypełniają się do swojej pojemności, a następnie pakiety są upuszczane, a TCP zauważa ten spadek z powodu braku odebranego potwierdzenia, ograniczając w ten sposób szybkość połączenia do oszacowania pojemności. TCP stosuje także coś, co nazywa się powolnym startem , ale przepustowość (w rzeczywistości okno przeciążenia)) jest powoli zwiększany, aż pakiety zostaną upuszczone, a następnie jest obniżany i powoli zwiększany, aż pakiety zostaną upuszczone itp. Powoduje to fluktuację przepustowości TCP. Widać to wyraźnie po pobraniu dużego pliku.

Ponieważ UDP nie używa kontroli przeciążenia, może być zarówno szybsze, jak i doświadczać mniejszego opóźnienia, ponieważ nie będzie dążyć do maksymalizacji buforów aż do punktu zrzutu, tj. Pakiety UDP spędzają mniej czasu w buforach i docierają tam szybciej z mniejszym opóźnieniem. Ponieważ protokół UDP nie stosuje kontroli przeciążenia, ale protokół TCP, może odebrać przepustowość TCP, która podlega przepływom UDP.

UDP jest jednak nadal podatne na przeciążenia i spadki pakietów, więc aplikacja musi być przygotowana na rozwiązanie tych problemów, prawdopodobnie przy użyciu kodów retransmisji lub korekcji błędów.

W rezultacie UDP może:

  • Osiągnij wyższą przepustowość niż TCP, o ile szybkość zrzutu sieci mieści się w granicach, które aplikacja może obsłużyć.
  • Dostarcz pakiety szybciej niż TCP z mniejszym opóźnieniem.
  • Szybsze konfigurowanie połączeń, ponieważ nie ma wstępnego uzgadniania w celu skonfigurowania połączenia
  • Przesyłaj pakiety multiemisji, podczas gdy TCP musi używać wielu połączeń.
  • Przesyłaj pakiety o stałym rozmiarze, podczas gdy TCP przesyła dane w segmentach. Jeśli prześlesz pakiet UDP o wielkości 300 bajtów, otrzymasz 300 bajtów na drugim końcu. Za pomocą protokołu TCP możesz zasilić gniazdo wysyłające 300 bajtów, ale odbiornik odczytuje tylko 100 bajtów i musisz dowiedzieć się, że po 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 rodzaju aplikacji, które może TCP, pod warunkiem, że zaimplementujesz również odpowiedni mechanizm retransmisji. UDP może być bardzo szybki, ma mniejsze opóźnienie, nie jest obciążony przeciążeniem na podstawie połączenia, przesyła datagramy o stałej wielkości i może być wykorzystywany do multiemisji.

Andy
źródło
1
Kiedy sieci są wystarczająco przepełnione, aby spowodować utratę pakietów, TCP próbuje zminimalizować swój wpływ na innych użytkowników sieci, podczas gdy wiele implementacji opartych na UDP nie. To pozwala im złapać większą część malejącego tortu, ale także zmniejsza całkowitą użyteczną dostępną przepustowość dostępnego okresu (np. W wyniku niepotrzebnej retransmisji w przypadkach, w których dane zostałyby faktycznie dostarczone, ale nadawca nie zdawałby sobie z tego sprawy)
supercat
Przede wszystkim dziękuję za świetną odpowiedź, naprawdę wiele się z niej nauczyłem! Ale mam pytanie: czy segmentacja nie zachodzi na warstwie 3 (IP) z powodu ograniczeń adaptera Ethernet dla wszystkich pakietów otrzymanych z warstwy 4 (zarówno TCP, jak i UDP)? Czy masz na myśli jakąkolwiek inną segmentację, która dzieje się w TCP, ale nie w UDP? Byłbym bardzo wdzięczny, gdybyś mógł mi to wyjaśnić.
RuslanSh
1
@Freezy. Masz rację, fragmentacja pakietów, które przekraczają MTU łącza (warstwa 2) ma miejsce w warstwie 3-IP. Jednak TCP jest protokołem opartym na strumieniu i traktuje dane jako strumień bajtów. TCP wysyła swoje dane w segmentach, aby zmieściły się w pakietach IP, których rozmiar jest zgodny z MSS, więc segmentacja zachodzi również w TCP. Ile danych TCP umieszcza w segmencie lub ile danych czyta twoje gniazdo różni się jednak wieloma czynnikami; może to być 1 bajt lub bajt MSS. W przypadku UDP odbiornik zawsze otrzymuje dokładną liczbę bajtów wysłanych przez nadajnik, jeśli pakiet nie zostanie utracony na trasie.
Andy
15

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

Jest stosowany w SNMP, ponieważ zarządzanie siecią musi często odbywać się, gdy sieć jest obciążona, tj. Gdy trudno jest uzyskać niezawodny, kontrolowany przez przeciążenia transfer danych.

Jest używany w DNS, ponieważ nie wymaga nawiązywania połączenia, co pozwala uniknąć opóźnień w nawiązywaniu połączeń.

Twoje zdrowie

Arnkrishn
źródło
14

UDP ma mniejszy narzut i jest dobry do robienia takich rzeczy, jak przesyłanie strumieniowe danych w czasie rzeczywistym, takich jak audio lub wideo, lub w każdym przypadku, gdy jest dobrze, jeśli dane zostaną utracone.

Dana Holt
źródło
12

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ą, jaka jest.

TCP ma blokowanie na początku kolejki, ponieważ gwarantuje kompletne i zgodne z zamówieniem dostarczanie, więc gdy pakiet zgubi się w transporcie, musi poczekać na ponowną transmisję brakującego pakietu, podczas gdy UDP dostarcza pakiety do aplikacji po ich przybyciu , w tym duplikaty i bez żadnej gwarancji, że pakiet w ogóle dotrze lub która kolejność dotrze (tak naprawdę jest to zasadniczo adres IP z numerami portów i (opcjonalnie) sumą kontrolną ładunku dodanego), ale jest to dobre w przypadku telefonii, na przykład tam, gdzie zwykle po prostu nie ma znaczenia, gdy brakuje kilku milisekund dźwięku, ale opóźnienie jest bardzo denerwujące, więc nie zawracaj sobie głowy retransmitami, po prostu upuszczasz duplikaty, sortujesz uporządkowane pakiety w odpowiedniej kolejności przez kilkaset milisekund bufora jittera , a jeśli pakiety nie pojawią się na czas lub w ogóle, są po prostu pomijane,możliwa interpolacja, jeśli jest obsługiwana przez kodek.

Ponadto znaczną częścią TCP jest kontrola przepływu, aby upewnić się, że uzyskasz jak najwięcej przepustowości, ale bez przeciążania sieci (co jest trochę redundantne, ponieważ przeciążona sieć zrzuci twoje pakiety, co oznacza, że ​​musisz zrobić retransmisje, co szkodzi przepustowości), UDP nie ma nic takiego - co ma sens w aplikacjach takich jak telefonia, ponieważ telefonia z danym kodekiem wymaga określonej przepustowości, nie można jej „spowolnić”, a także dodatkowej przepustowości nie przyspiesza połączenia.

Oprócz aplikacji działających w czasie rzeczywistym / o niskim opóźnieniu, UDP ma sens w przypadku naprawdę małych transakcji, takich jak wyszukiwanie DNS, po prostu dlatego, że nie ma połączenia TCP i narzutu porzucenia, zarówno pod względem opóźnienia, jak i wykorzystania przepustowości. Jeśli twoje żądanie jest mniejsze niż typowy MTU i prawdopodobnie jest to również powtórka, możesz to zrobić w jednym okrążeniu, bez potrzeby utrzymywania jakiegokolwiek stanu na serwerze i zamawiania kontroli przepływu, a wszystko to prawdopodobnie nie jest szczególnie przydatne do takich zastosowań albo.

A potem, oczywiście, możesz użyć UDP do budowy własnych zamienników TCP, ale prawdopodobnie nie jest to dobry pomysł bez dogłębnego zrozumienia dynamiki sieci, nowoczesne algorytmy TCP są dość wyrafinowane.

Myślę też, że należy wspomnieć, że jest więcej niż UDP i TCP, takich jak SCTP i DCCP. Obecnie jedynym problemem jest to, że Internet (IPv4) jest pełen bram NAT, co uniemożliwia korzystanie z protokołów innych niż UDP i TCP w aplikacjach użytkowników końcowych.

Shital Shah
źródło
Możesz uruchomić SCTP i DCCP przez UDP.
Demi
8

Streaming wideo jest doskonałym przykładem użycia UDP.

Daniel A. White
źródło
Podaj kilka przykładów.
Gaurav Singh
Przykładem jest „Streaming wideo”. Rozważ transmisję na żywo transmitowaną przez hotstar.
Sisir
8

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

Nie ma żadnych gwarancji dostarczenia TCP, należy po prostu powiedzieć, czy gniazdo zostało odłączone, czy w zasadzie, jeśli dane nie dotrą. W przeciwnym razie dotrze tam, kiedy tam dotrze.

Wielką rzeczą, o której ludzie zapominają, jest to, że udp jest oparte na pakietach, a tcp jest oparte na bystream, nie ma gwarancji, że wysłany „pakiet tcp” to pakiet, który pojawia się na drugim końcu, można go podzielić na tyle pakietów jak chcą routery i stosy. Twoje oprogramowanie ma więc dodatkowy narzut związany z analizowaniem bajtów z powrotem na użyteczne porcje danych, co może zająć sporo. UDP może być niesprawny, więc musisz ponumerować swoje pakiety lub użyć innego mechanizmu, aby je ponownie zamówić, jeśli chcesz to zrobić. Ale jeśli dostaniesz ten pakiet udp, otrzyma wszystkie te same bajty w tej samej kolejności, w jakiej zostało, bez zmian. Zatem termin pakiet udp ma sens, ale pakiet tcp niekoniecznie. TCP ma własny mechanizm ponownej próby i zamawiania, który jest ukryty przed aplikacją,

UDP jest znacznie łatwiejsze do pisania kodu na obu końcach, po prostu dlatego, że nie trzeba nawiązywać i utrzymywać połączeń typu punkt-punkt. Moje pytanie zazwyczaj brzmi, gdzie są sytuacje, w których chciałbyś narzut TCP? A jeśli przyjmiesz skróty, takie jak założenie, że otrzymany „pakiet” TCP jest kompletnym pakietem, który został wysłany, czy lepiej ci będzie? (prawdopodobnie zrzucisz dwa pakiety, jeśli zechcesz sprawdzić długość / zawartość)

old_timer
źródło
TCP ma gwarancję dostarczenia: porcja A zostanie dostarczona do aplikacji przed porcją B, dlatego jeśli aplikacja potwierdzi (na poziomie aplikacji) porcję B, to wiesz, że dostała porcję A. Ale dzieje się tak również na poziomie obsługi TCP.
Simeon Pilgrim
W TCP można bezpiecznie oddzielić fragmenty danych, po prostu poprzedzając każdy fragment jego długością. W zależności od zastosowania, każdy fragment może mieć przedrostek o ustalonej długości jednego bajta, dwóch bajtów lub czterech bajtów, lub może poprzedzać każdy fragment o wielkości 128 ^ N lub mniejszej o długości N-bajtów. Niezupełnie duże koszty ogólne. Taki projekt byłby zły w przypadku protokołów, które nie gwarantują dostarczania zamówienia bez przerw, ale przy użyciu TCP taki projekt jest w porządku.
supercat
jeśli szukasz danych o stałej długości, nie potrzebujesz nawet długości, po prostu policz bajty, gdy się pojawią ...
old_timer
1
@supercat. Masz absolutną rację. Oznacza to również, że zwiększasz złożoność aplikacji; złożoność, która jest faktycznie potrzebna w UDP. Z tego powodu TCP lepiej nadaje się do przesyłania strumieni, takich jak pliki. Ale robię dokładnie to, co robisz, gdy chcę niezawodności fragmentów danych i być może dodatkowego bezpieczeństwa TLS na najwyższym TCP.
Andy,
5

Komunikacja sieciowa gier wideo prawie zawsze odbywa się przez UDP.

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

17 z 26
źródło
5
normalny wcale nie pełny stan, ale delta od ostatniego potwierdzenia, dlatego aktualizacje stają się coraz większe.
Simeon Pilgrim
5

Kluczowe pytanie dotyczyło „w jakich sytuacjach UDP byłby lepszym wyborem [w porównaniu z TCP]”

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

Przy ogromnym wzroście aplikacji mobilnych i towarzyszących im paradygmatach „okazjonalnie połączonych” lub „okazjonalnie rozłączonych”, z pewnością zdarzają się sytuacje, w których obciążenie TCP prób utrzymania połączenia, gdy połączenia są trudne, prowadzi do silnego przypadek UDP i jego charakter „zorientowany na wiadomości”.

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

Rob Von Nesselrode
źródło
3

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

Jedynym wyjątkowym przypadkiem, 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 przeciążenia każdego z nich będzie kolidować ze sobą. Dlatego na ogół preferuje się tunelowanie TCP zamiast UDP (lub innego protokołu bezstanowego). Zobacz artykuł TechRepublic: Zrozumienie protokołu TCP przez TCP: wpływ tunelowania protokołu TCP na przepustowość i opóźnienie między końcami .

Brian M. Hunt
źródło
2

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, a aplikacja będzie się martwić o zmianę kolejności pakietów, ale ostatecznie VOIP nie potrzebuje każdego pojedynczego pakietu, ale co ważniejsze, potrzebuje ciągłego przepływu wielu z nich. Być może masz tutaj „usterkę” w jakości głosu, ale głównym celem jest to, że dostaniesz wiadomość, a nie to, że zostanie odtworzona idealnie po drugiej stronie. UDP jest również używany w sytuacjach, w których koszt utworzenia połączenia i synchronizacji z TCP przeważa ładunek. Zapytania DNS są doskonałym przykładem. Jeden pakiet, jeden pakiet z powrotem, na zapytanie. W przypadku korzystania z protokołu TCP byłoby to znacznie bardziej intensywne. Jeśli nie otrzymasz odpowiedzi DNS, po prostu spróbuj ponownie.

RC.
źródło
2

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

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

bgw
źródło
2

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

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

Jest to również odpowiednie, gdy chcesz przekazać te same informacje wielu użytkownikom.

Innym razem jest to właściwe, gdy wysyłasz zsekwencjonowane dane, ale jeśli część z nich zaginie, nie martw się zbytnio (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. Właśnie tam warstwa aplikacji musi zaimplementować dodatkową funkcjonalność. W takich przypadkach odpowiedni jest również UDP (np. Radio internetowe, kolejność jest ważna, ale nie każdy pakiet musi się połączyć).

Przykłady tego, gdzie jest / może być użyty 1) Serwer czasu nadający prawidłowy czas do kilku komputerów w sieci LAN. 2) Protokoły VOIP 3) Wyszukiwanie DNS 4) Żądanie usług LAN, np. Gdzie jesteś? 5) Radio internetowe 6) i wiele innych ...

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

Matt
źródło
2

Spójrz na sekcję 22.4 programowania sieci Unix Stevena , „Kiedy używać UDP zamiast TCP”.

Zobacz także inną odpowiedź SO dotyczącą błędnego przekonania, że ​​UDP jest zawsze szybszy niż TCP .

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

  • Użyj UDP do emisji i multiemisji, ponieważ jest to twoja jedyna opcja (użyj multiemisji do nowych aplikacji)
  • Możesz używać UDP do prostych aplikacji z prośbą / odpowiedzią, ale musisz wbudować własne pakiety, limity czasu i retransmisje
  • Nie używaj UDP do masowego przesyłania danych.
Robert S. Barnes
źródło
1
Trochę więcej informacji na temat tego ostatniego punktu, dla każdego, kto przyjdzie. TCP działa w przypadku masowego przesyłania danych, ale jeśli nie obchodzi Cię, że Twoje dane docierają w kolejności od początku do końca, możesz napisać protokół UDP, który może być szybszy - znacznie szybszy w bardzo szczególnych przypadkach patologicznych. Nie chodzi o to, że nie można wykonać masowego transferu w UDP, nie chodzi o to, że zawsze ma gorsze wyniki; wdrożenie takiego osła jest tak uciążliwe, że rzadko warto się tym przejmować.
ijw
1
Tak, możesz użyć UDP do masowego transferu i musisz wdrożyć własny mechanizm kontroli. Jeśli boli cię to w dupę, zależy od twoich umiejętności programistycznych, ale zdecydowanie nie zawsze jest gorsza. Musisz wiedzieć, co robisz; jeśli tego nie zrobisz, możesz cierpieć.
Andy,
2

Wiemy, że UDP to protokół bez połączenia, więc tak jest

  1. nadaje się do procesów wymagających prostej komunikacji żądanie-odpowiedź.
  2. nadaje się do procesu o wewnętrznym przepływie, kontroli błędów
  3. nadaje się do szerokiego castingu i multiemisji

Konkretne przykłady:

  • używane w SNMP
  • używane w niektórych protokołach aktualizujących trasy, takich jak RIP
Vikki
źródło
2

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

wprowadź opis zdjęcia tutaj

Jorgesys
źródło
1

Chcesz używać UDP przez TCP w przypadkach, gdy utrata niektórych danych po drodze nie zniszczy całkowicie przesyłanych danych. Wiele z jego zastosowań znajduje się w aplikacjach czasu rzeczywistego, takich jak gry (np. FPS, gdzie nie zawsze musisz wiedzieć, gdzie jest każdy gracz w danym momencie, a jeśli po drodze stracisz kilka pakietów, nowe dane i tak poprawnie wskażą, gdzie są odtwarzacze), a strumieniowe przesyłanie wideo w czasie rzeczywistym (jedna uszkodzona klatka nie zepsuje oglądania).

Zachary Murray
źródło
Cóż, jedna uszkodzona klatka zniszczy tę część oglądania, ale nie chcesz, aby zatrzymywała wszystkie ostatnie klatki, czekając na nią, jeśli późniejsze klatki mają większą wartość niż utracona klatka.
Simeon Pilgrim
1

Mamy serwis internetowy, który ma tysiące klientów winforms na tylu komputerach. Komputery nie mają połączenia z backendem DB, cały dostęp odbywa się za pośrednictwem usługi internetowej. Postanowiliśmy więc opracować centralny serwer rejestrujący, który nasłuchuje na porcie UDP, a wszyscy klienci wysyłają pakiet dziennika błędów xml (za pomocą programu dołączającego UDP log4net), który po otrzymaniu zostaje zrzucony do tabeli DB. Ponieważ tak naprawdę nie dbamy o to, czy pominięto kilka dzienników błędów, a w przypadku tysięcy klientów jest to szybkie dzięki dedykowanej usłudze rejestrowania, która nie ładuje głównej usługi internetowej.

softveda
źródło
0

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

Jedynym przypadkiem, w którym mogę wymyślić, gdzie wymagany jest UDP, są protokoły rozgłoszeniowe. W przypadkach, gdy aplikacja obejmuje dwa znane hosty, UDP prawdopodobnie zapewni jedynie marginalną poprawę wydajności przy znacznie zwiększonych kosztach złożoności kodu.

SingleNegationElimination
źródło
Jedna aplikacja, w której uzyskasz lepsze wyniki z UDP, znajduje się w teście Put, jeśli węzeł pośredni wykonuje kontrolę ruchu, ponieważ możesz łatwiej kontrolować szybkość pakietów, werset TCP, który szybko przepchnie pakiety, oraz interakcję TCP okienkowanie negatywnie wpływa na funkcjonowanie policji.
Simeon Pilgrim
To wciąż optymalizacja, która powinna wynikać z faktycznych testów. Argumentuję, że powinieneś najpierw spróbować użyć TCP i wypróbować alternatywy tylko wtedy, gdy odkryjesz, że TCP z jakiegoś powodu nie działa. Wybór UDP, ponieważ teoretycznie obsługuje lepsze wykorzystanie przepustowości, jest formą przedwczesnej optymalizacji.
SingleNegationElimination
Och, zgódź się na front optymalizacji. Ale wiedza o tym, kiedy TCP może być problemem werset, coś innego pomaga, gdy próbujesz rozwiązać ten problem wydajności.
Simeon Pilgrim
-1

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 próbowaliby go wszędzie trzymać, wydaje się nieproporcjonalna. Być może lubią same implementować kod obsługi błędów i obsługi połączeń.

TCP powinien być znacznie szybszy dzięki nowoczesnym kartom sieciowym ze względu na tak zwany nadruk sumy kontrolnej . Zaskakujące jest to, że przy dużych prędkościach połączenia (takich jak 1 Gb / s) obliczenie sumy kontrolnej stanowiłoby duże obciążenie dla procesora, więc jest odciążone do sprzętu NIC, który rozpoznaje pakiety TCP do nadruku, i nie oferuje tej samej usługi.

Pavel Radzivilovsky
źródło
2
Odciążanie sumy kontrolnej UDP jest dostępne podobnie jak odciążanie sumy kontrolnej TCP.
Ben Voigt
ale nie sprawdzanie poprawności sumy kontrolnej.
Pavel Radzivilovsky,
1
Nawet karty sieciowe Ethernet klasy konsumenckiej mają obecnie funkcję odciążania sumy kontrolnej UDP zarówno dla transmisji, jak i odbioru (odciążanie odbioru dokonuje sprawdzania poprawności). I widziałem tę funkcję w sprzęcie prosumenckim dekadę temu, jestem pewien, że była jeszcze w kartach sieciowych klasy serwerowej.
Ben Voigt,
-2

UDP idealnie nadaje się do adresowania VoIP, gdzie pakiet danych musi być wysyłany ze względu na jego mniejszą niezawodność ... Czat wideo jest przykładem UDP (można to sprawdzić przechwytywaniem sieci wireshark podczas dowolnego czatu wideo). Również TCP nie działa z Protokoły DNS i SNMP. UDP nie ma narzutu, podczas gdy TCP ma dużo narzutu

Himanshu Saxena
źródło