UDP vs TCP, o ile szybciej? [zamknięte]

Ludzie mówią, że główną rzeczą, jaką daje TCP, jest niezawodność. Ale to nie do końca prawda. Najważniejszą rzeczą, jaką daje TCP, jest kontrola zatorów: możesz uruchomić 100 połączeń TCP przez łącze DSL z maksymalną prędkością, a wszystkie 100 połączeń będzie produktywne, ponieważ wszystkie "wyczują" dostępną przepustowość. Wypróbuj to w 100 różnych aplikacjach UDP, wszystkie pushing Pakiety tak szybko, jak to możliwe, i zobaczyć, jak dobrze wszystko działa dla Ciebie.

Na większą skalę, ten TCP zachowanie jest tym, co sprawia, że Internet nie blokuje się w"zatłoczeniu".

Rzeczy, które mają tendencję do popychania aplikacji w kierunku UDP:

• Semantyka dostarczania grupowego: możliwe jest niezawodne dostarczanie do grupy ludzi znacznie wydajniej niż potwierdzenie TCP typu point-to-point.

• Out-of-order delivery: w wielu aplikacjach, tak długo, jak masz wszystkie dane, nie obchodzi cię, w jakiej kolejności przybywa; możesz zmniejszyć opóźnienie na poziomie aplikacji o akceptuję blokadę poza zamówieniem.

• Nieprzyjazność: na stronie LAN możesz nie dbać o to, czy twoja przeglądarka działa ładnie, o ile tak szybko, jak to tylko możliwe, aktualizujesz sieć.

Ale nawet jeśli zależy ci na wydajności, prawdopodobnie nie chcesz iść z UDP:

• Teraz masz problem z niezawodnością, a wiele rzeczy, które możesz zrobić, aby wdrożyć niezawodność, może skończyć się wolniejszym rozwiązaniem niż TCP tak.

• Teraz jesteś nieprzyjazny w sieci, co może powodować problemy we współdzielonych środowiskach.

• Co najważniejsze, zapory sieciowe będą Cię blokować.

Można potencjalnie przezwyciężyć pewne problemy z wydajnością TCP i opóźnieniami poprzez "trunkingowanie" wielu połączeń TCP razem; iSCSI robi to, aby obejść kontrolę zatorów w sieciach lokalnych, ale można to również zrobić, aby utworzyć kanał wiadomości "pilnych" o niskim opóźnieniu (zachowanie "pilnych" TCP jest całkowicie złamane).

W niektórych aplikacjach TCP jest szybszy (lepsza przepustowość) niż UDP.

Tak jest w przypadku wykonywania wielu małych zapisów w stosunku do rozmiaru MTU. Na przykład czytałem eksperyment, w którym strumień 300-bajtowych pakietów był wysyłany przez Ethernet (1500-bajtowy MTU) i TCP był o 50% szybszy niż UDP .

Powodem jest to, że TCP spróbuje buforować dane i wypełnić cały segment sieci, dzięki czemu bardziej efektywne wykorzystanie dostępnej przepustowości.

UDP on druga ręka natychmiast umieszcza pakiet na przewodzie, zatykając sieć wieloma małymi pakietami.

Prawdopodobnie nie powinieneś używać UDP, chyba że masz bardzo konkretny powód. Zwłaszcza, że możesz nadać TCP taki sam rodzaj opóźnienia jak UDP, wyłączając algorytm Nagle (na przykład, jeśli przesyłasz dane z czujników w czasie rzeczywistym i nie martwisz się o przeciążenie sieci lotami małych pakietów).

Z tolerancją strat

Zasadniczo UDP nie jest "tolerancyjny na straty". Możesz wysłać komuś 100 pakietów, a on może dostać tylko 95 z tych pakietów, a niektóre mogą być w złej kolejności.

W przypadku streamingu wideo i gier wieloosobowych, gdzie lepiej przegapić pakiet niż opóźnić wszystkie inne pakiety za nim, jest to oczywisty wybór

Dla większości innych rzeczy, choć brakuje lub "przestawiony" Pakiet jest krytyczny. Musisz napisać dodatkowy kod, aby uruchomić na UDP, aby spróbować ponownie, jeśli coś zostało pominięte, i wymusić poprawną kolejność. To dodałoby trochę nad głową w niektórych miejscach.

Pomyśl o tym w ten sposób: jeśli pakiet zniknie, wolisz po prostu dostać następny pakiet tak szybko ,jak to możliwe i kontynuować (użyj UDP), czy naprawdę potrzebujesz tych brakujących danych (użyj TCP). Koszty nie będą miały znaczenia, jeśli nie znajdziesz się w naprawdę skrajnym scenariuszu.

Który protokół działa lepiej (pod względem przepustowości) - UDP lub TCP-tak naprawdę zależy od charakterystyki sieci i ruchu sieciowego. Robert S. Barnes, na przykład, wskazuje scenariusz, w którym TCP działa lepiej (pisze o małych rozmiarach). Teraz rozważmy scenariusz, w którym sieć jest przeciążona i ma zarówno ruch TCP, jak i UDP. Nadawcy w sieci, którzy korzystają z TCP, wyczują "zatory" i obniżą swoje stawki wysyłania. Jednak UDP nie ma żadnych zatorów mechanizmy unikania lub kontroli zatorów, a nadawcy korzystający z UDP nadal będą pompować dane w tym samym tempie. Stopniowo nadawcy TCP zmniejszali szybkość wysyłania do minimum, a jeśli nadawcy UDP mają wystarczającą ilość danych do wysłania przez sieć, zwiększali większość dostępnej przepustowości. W takim przypadku nadawcy UDP będą mieli większą przepustowość, ponieważ uzyskają większą przepustowość sieci. W rzeczywistości jest to aktywny temat badawczy - jak poprawić przepustowość TCP w obecność ruchu UDP. Jednym ze sposobów, jaki znam, za pomocą którego aplikacje TCP mogą poprawić przepustowość, jest otwarcie wielu połączeń TCP. W ten sposób, nawet jeśli przepustowość każdego połączenia TCP może być ograniczona, suma przepustowości wszystkich połączeń TCP może być większa niż przepustowość aplikacji używającej UDP.

Mówiąc o "co jest szybsze" - istnieją co najmniej dwa bardzo różne aspekty: przepustowość i opóźnienie.

Jeśli mówimy o przepustowości - Kontrola przepływu TCP (jak wspomniano w innych odpowiedziach), jest niezwykle ważna i robienie czegokolwiek porównywalnego z UDP, choć z pewnością możliwe, byłoby wielkim bólem głowy(tm). W rezultacie - korzystanie z UDP, gdy potrzebujesz przepustowości , rzadko kwalifikuje się jako dobry pomysł (chyba że chcesz uzyskać nieuczciwą przewagę nad TCP).

Jeśli jednak mówimy o opóźnieniach - wszystko jest zupełnie inne. Podczas gdy przy braku utraty pakietów TCP i UDP zachowują się bardzo podobnie ( ewentualne różnice są marginalne) - po utracie pakietu cały wzór zmienia się drastycznie.

Po utracie pakietów, TCP będzie czekał na retransmisję przez co najmniej 200ms (1SEK na paragraf 2.4 RFC6298, ale praktyczne współczesne implementacje mają tendencję do zmniejszania go do 200ms). Ponadto z TCP, nawet te pakiety, które dotarły do hosta docelowego - nie zostaną dostarczone do Twojej aplikacji, dopóki brakujący pakiet nie zostanie odebrany ( tzn. cała komunikacja jest opóźniona o ~200ms)-BTW, efekt ten, znany jako blokowanie Head-of-Line, jest nieodłączny dla wszystkich niezawodnych uporządkowanych strumieni, czy to TCP, czy niezawodny+uporządkowany UDP. Co gorsza - jeśli retransmitowany pakiet również zostanie utracony, wtedy będziemy mówić o opóźnieniu ~600ms (z powodu tak zwanego wykładniczego cofnięcia, 1. retransmitacja to 200ms, a 2. jeden to 200 * 2=400ms). Jeśli nasz kanał ma 1% strat pakietów (co jak na dzisiejsze standardy nie jest złe), a my mamy grę z 20 aktualizacjami na sekundę - takie opóźnienia 600ms będą występować średnio co 8 minut. I jak 600ms jest więcej niż wystarczająco, aby cię zabić w szybkim tempie gry-Cóż, to jest dość złe dla rozgrywki. Właśnie dlatego gamedevs często preferuje UDP zamiast TCP.

Jednak przy użyciu UDP do zmniejszenia opóźnień-ważne jest, aby zdać sobie sprawę, że samo "używanie UDP" nie jest wystarczy, aby uzyskać znaczną poprawę latencji, chodzi o to, jak używasz UDP. W szczególności, podczas gdy biblioteki RUDP zwykle unikają tego "wykładniczego cofnięcia" i używają krótszych czasów retransmisji - jeśli są używane jako "niezawodny uporządkowany" strumień, nadal muszą cierpieć z powodu blokowania Head-of-Line (więc w przypadku podwójnej utraty pakietów, zamiast tego 600ms otrzymamy około 1.5*2*RTT - lub dla całkiem dobrego 80ms RTT, jest to opóźnienie ~250ms, co jest poprawą, ale nadal można to zrobić w przypadku lepiej). Z drugiej strony, jeśli przy użyciu technik omówionych w http://gafferongames.com/networked-physics/snapshot-compression/ i / lub http://ithare.com/udp-from-mog-perspective/#low-latency-compression , możliwe jest całkowite wyeliminowanie blokowania Head-of-Line (Tak więc dla podwójnej utraty pakietów dla gry z 20 aktualizacjami / sekundę opóźnienie będzie wynosić 100ms niezależnie od RTT).

I na marginesie-jeśli zdarzy ci się mieć dostęp tylko do TCP, ale bez UDP (np. w przeglądarka, lub jeśli twój klient stoi za jedną z 6-9% brzydkich zapór blokujących UDP) - tam wydaje się być sposobem na zaimplementowanie UDP-over-TCP bez ponoszenia zbyt dużych opóźnień, zobacz tutaj: http://ithare.com/almost-zero-additional-latency-udp-over-tcp / (koniecznie przeczytaj też komentarze (!)).

Każde połączenie TCP wymaga wstępnego uścisku dłoni przed przesłaniem danych. Ponadto nagłówek TCP zawiera wiele nagłówków przeznaczonych do wykrywania różnych sygnałów i dostarczania wiadomości. W przypadku wymiany wiadomości UDP prawdopodobnie wystarczy, jeśli dopuszczalna jest niewielka szansa na awarię. Jeśli odbiór musi zostać zweryfikowany, TCP jest najlepszą opcją.

Wyjaśnię wszystko. TCP / UDP {[2] } to dwa samochody, które jeżdżą po drodze. Załóżmy, że znaki drogowe i przeszkody to błędy TCP dba o znaki drogowe, szanuje wszystko wokół. Powolna Jazda, ponieważ coś może się stać z samochodem. Podczas gdy UDP po prostu odjeżdża, Pełna Prędkość bez szacunku do znaków drogowych. Nic, szalony kierowca. UDP nie ma odzyskiwania błędów, jeśli jest przeszkoda, po prostu zderzy się z nią, a następnie kontynuuje. While TCP zapewnia, że wszystkie pakiety są wysyłane i odbierane idealnie , bez błędów , więc samochód po prostu przechodzi przeszkody bez kolizji. Mam nadzieję, że jest to dobry przykład dla ciebie, aby zrozumieć, dlaczego UDP jest preferowany w grach. Granie wymaga szybkości. TCP jest konfferowany w plikach do pobrania lub pobrane pliki mogą być uszkodzone.

UDP jest z mojego doświadczenia nieco szybszy, ale niewiele. Wyboru nie należy dokonywać w odniesieniu do wydajności, ale w odniesieniu do treści wiadomości i technik kompresji.

Jeśli jest to protokół z Komunikatem exchange , sugerowałbym, że bardzo niewielki wpływ na wydajność TCP jest więcej niż wart. Otrzymujesz połączenie między dwoma punktami końcowymi, które da Ci wszystko, czego potrzebujesz. Nie próbuj produkować własnego niezawodnego protokołu dwukierunkowego na bazie UDP, chyba że bardzo, bardzo pewny siebie w tym, co robisz.

Jeśli chcesz szybko wysłać wiadomość przez sieć między dwoma IP, które jeszcze nie rozmawiały, wtedy UDP dotrze co najmniej 3 razy szybciej, zwykle 5 razy szybciej.

Należy pamiętać, że TCP Zwykle przechowuje wiele wiadomości na kablu. Jeśli chcesz zaimplementować to w UDP, będziesz miał sporo pracy, jeśli chcesz to zrobić niezawodnie. Twoje rozwiązanie będzie albo mniej niezawodne, mniej szybkie lub niewiarygodnie dużo pracy. Istnieją ważne aplikacje UDP, ale jeśli zadajesz to pytanie, prawdopodobnie nie jest.

Wykonano pewne prace, aby programista mógł czerpać korzyści z obu światów.

SCTP

Jest to niezależna warstwa transportowa protolol, ale może być używana jako biblioteka dostarczająca dodatkową warstwę przez UDP. Podstawową jednostką komunikacji jest wiadomość (odwzorowana na jeden lub więcej pakietów UDP). Wbudowana jest kontrola zatorów. Protokół posiada pokrętła do włączania

• w kolejności dostarczania wiadomości
• automatyczny retransmisja utraconych wiadomości z parametrami zdefiniowanymi przez Użytkownika

Jeśli cokolwiek z tego jest potrzebne do konkretnego zastosowania.

Problem polega na tym, że ustanowienie połączenia jest skomplikowanym (a więc powolnym procesem)

Inne podobne rzeczy

• https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

Jeszcze jeden podobny własnościowy eksperyment thing

• https://en.wikipedia.org/wiki/QUIC

To również stara się poprawić potrójny sposób uścisku dłoni TCP i zmienić kontrolę zatorów, aby lepiej radzić sobie z szybkimi liniami.

Bez znaczenia jest mówienie o TCP lub UDP bez uwzględniania stanu sieci. Jeśli sieć między dwoma punktami ma bardzo wysoką jakość, UDP jest absolutnie szybszy niż TCP, ale w niektórych innych przypadkach, takich jak sieć GPRS, TCP może być szybszy i bardziej niezawodny niż UDP.

Konfiguracja sieci jest kluczowa dla wszelkich pomiarów. Robi to ogromną różnicę, jeśli komunikujesz się za pośrednictwem gniazd na lokalnej maszynie lub z drugim końcem świata.

Trzy rzeczy, które chcę dodać do dyskusji:

1. znajdziesz tutaj Bardzo dobry artykuł o TCP vs. UDP w kontekst tworzenia gier.
2. dodatkowo, iperf (jperf enhance iperf with a GUI) jest bardzo ładne narzędzie do odpowiedzi na twoje pytanie siebie poprzez pomiar.
3. zaimplementowałem benchmark w Pythonie (zobacz to pytanie ). W średniej iteracji 10^6 różnica przy wysyłaniu 8 bajtów wynosi około 1-2 mikrosekundy dla UDP.