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

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?

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ć.

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.

„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).

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.

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.

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

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.

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.

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

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ść)

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.

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 ....

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 .

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.

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.

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.

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.

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

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.

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).

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.

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.

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.

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