Mówiąc o „tym, co jest szybsze” - istnieją co najmniej dwa bardzo różne aspekty: przepustowość i opóźnienie.
Mówiąc o przepustowości - kontrola przepływu TCP (jak wspomniano w innych odpowiedziach), jest niezwykle ważna i robienie czegokolwiek porównywalnego w stosunku do UDP, choć na pewno możliwe, byłoby dużym 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 - cała sprawa jest zupełnie inna. Podczas gdy przy braku utraty pakietów TCP i UDP zachowują się bardzo podobnie (wszelkie różnice, jeśli występują, są marginalne) - po utracie pakietu cały wzorzec zmienia się drastycznie.
Po każdej utracie pakietu TCP będzie czekać na retransmisję przez co najmniej 200 ms (1 s na paragraf 2.4 RFC6298, ale praktyczne nowoczesne implementacje mają tendencję do zmniejszania go do 200 ms). Co więcej, dzięki TCP nawet te pakiety, które dotarły do hosta docelowego - nie zostaną dostarczone do Twojej aplikacji, dopóki nie zostanie odebrany brakujący pakiet (tj. Cała komunikacja zostanie opóźniona o ~ 200 ms) - BTW, ten efekt, znany jako Head-of Blokowanie linii jest nieodłącznym elementem wszystkich niezawodnych uporządkowanych strumieni, czy to TCP, czy niezawodnych + uporządkowanych UDP. Co gorsza - jeśli retransmitowany pakiet również zostanie utracony, będziemy mówić o opóźnieniu ~ 600 ms (z powodu tak zwanego wykładniczego wycofania, 1. retransmisja to 200 ms, a drugi 200 * 2 = 400 ms). Jeśli nasz kanał ma 1% utraty pakietów (co nie jest złe według dzisiejszych standardów), i mamy grę z 20 aktualizacjami na sekundę - takie 600 ms opóźnienia będą występować średnio co 8 minut. A ponieważ 600 ms to więcej niż wystarczająca ilość, aby zabić Cię w szybkiej grze - no cóż, jest całkiem zła dla rozgrywki. Te efekty właśnie dlatego gamedevs często wolą UDP niż TCP.
Jednak w przypadku korzystania z UDP w celu zmniejszenia opóźnień - ważne jest, aby zdawać sobie sprawę, że samo „użycie UDP” nie jest wystarczające, aby uzyskać znaczną poprawę opóźnień, wszystko zależy od tego, JAK używasz UDP. W szczególności, podczas gdy biblioteki RUDP zwykle unikają tego „wykładniczego wycofania” i używają krótszych czasów retransmisji - jeśli są używane jako „niezawodny uporządkowany strumień”, nadal muszą cierpieć z powodu blokowania na początku linii (tak w przypadku podwójnego utrata pakietu, zamiast 600 ms otrzymamy około 1,5 * 2 * RTT - lub dla całkiem niezłego 80 ms RTT, opóźnienie to ~ 250 ms, co jest poprawą, ale nadal można to zrobić lepiej). Z drugiej strony, jeśli używa się technik omówionych w http://gafferongames.com/networked-physics/snapshot-compression/ i / lub http: // ithare. , możliwe jest całkowite wyeliminowanie blokowania Head-of-Line (więc w przypadku utraty podwójnego pakietu dla gry z 20 aktualizacjami na sekundę opóźnienie wyniesie 100 ms niezależnie od RTT).
Na marginesie - jeśli zdarza się, że masz dostęp tylko do TCP, ale nie ma UDP (np. W przeglądarce lub jeśli Twój klient stoi za jedną z 6-9% brzydkich zapór blokujących UDP) - wydaje się, że istnieje sposób na zaimplementuj UDP-over-TCP bez nadmiernych opóźnień, patrz tutaj: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (pamiętaj, aby przeczytać komentarze również (!)).