TCP czy UDP dla gry wieloosobowej?

To pytanie, które dużo widzę. Większość ludzi twierdzi, że UDP jest zawsze lepszy dla gier w czasie rzeczywistym niż TCP. Rozumiem, że TCP próbuje ciągle wysyłać pakiety, dopóki druga strona ich nie odbierze, podczas gdy UDP nie ma znaczenia.

Większość rzeczy, które przeczytałem, to to, że UDP jest koniecznością dla każdej gry w czasie rzeczywistym, a TCP jest okropny. Ale chodzi o to, że większość ludzi i tak implementuje jakąś formę TCP na UDP. Słyszałem również, że różnica między nimi jest znikoma, biorąc pod uwagę, że nie jesteśmy już w latach 80., a Internet jest teraz dość szybki i niezawodny.

Czy moje ogólne zrozumienie tutaj jest błędne? Czy ktoś może mi to wyjaśnić?

game-development networking tcp

— flooblebit
źródło

internet is now pretty fast and reliableNie, nie jest. Tak, przepustowość dramatycznie wzrosła, ale opóźnienie jest wciąż dość duże. W przypadku czystego protokołu TCP czas tykania serwera musi być większy niż maksymalne opóźnienie w przystępnej cenie, chyba że wykonujesz kompresowanie pakietów - co najlepiej jest wykonać u klienta za pośrednictwem protokołu UDP. Problem polega na tym, że niektóre informacje w grze muszą być wiarygodne, a inne muszą być szybkie. Umożliwiają to niestandardowe protokoły UDP, a także kilka zastrzeżonych, które zapewniają wszystko, czego potrzebujesz w ładnym pakiecie.

— Ordous

Nie wdrażają dokładnie protokołu TCP przez UDP. Pożądane są niektóre funkcje TCP, które są zaimplementowane oprócz UDP. Główną zaletą korzystania z UDP jest to, że jeśli wysyłasz pakiet zawierający stan świata, t0który nigdy nie został odebrany, to wysyłasz nowy stan świata w tym czasie t1, nie musisz czekać, aż klient faktycznie otrzyma pierwszą paczkę, który jest już przestarzały.

— Vincent Savard

@Ordous Myślę, że to odpowiada na moje pytanie :) Dzięki

— flooblebit

Pamiętaj również, że UDP jest podatny na fałszowanie adresów IP, co może spowodować, że Twój serwer będzie otwarty na ataki DDoS, jeśli jest to problem. Można tego uniknąć, mając „kontrolne” połączenie TCP, które wysyła adres IP klienta i inne szczegóły do serwera, który następnie przyjmuje pakiety UDP z „uwierzytelnionego” adresu. Konieczne może być także wdrożenie własnej warstwy szyfrowania, ponieważ nie ma otwartych standardów dla tego protokołu UDP.

— ARau

@ blownie55 dobre punkty tam

— Naresh Kumar

Odpowiedzi:

Zależy od tego, czy mówimy o sieci peer-to-peer, klient / serwer z użytkownikami serwera lub klient / serwer z centrum danych z serwerem. Tylko w drugim przypadku Internet jest naprawdę szybki i niezawodny. Komputery Twoich użytkowników nie mają gwarancji, że będą szybkie i na pewno nie będą niezawodne.

UDP pozwala na większą kontrolę nad rodzajem implementacji podobnej do TCP. Daje to większą elastyczność wykonywania pakietów poza kolejnością, odrzucania pakietów, które uważasz za niepotrzebne, podczas ponawiania pakietów, które uważasz za ważne, tego rodzaju rzeczy. Ale należy to zrobić tylko w razie potrzeby i jeśli masz niezbędną wiedzę specjalistyczną.

Jeśli możesz obejść się bez tej elastyczności, protokół TCP działa wystarczająco dobrze i oszczędza mnóstwo czasu. Nawet profesjonalne studia (takie jak te, w których pracowałem) używają protokołu TCP, jeśli absolutnie nie potrzebują UDP i mają osoby zajmujące się programowaniem sieciowym.

— Opłata Kevin
źródło

Sugerowałbym również, że „do tego, co ma znaczenie” - np. W przypadku systemu czatu w grze nawet nie wziąłbym pod uwagę UDP. Inną rzeczą, którą rozważę (przynajmniej w przypadku „serwera klienta”) jest to, jak efektywnie serwer może obsługiwać ruch - nowoczesne karty sieciowe mają wiele wbudowanych funkcji „odciążania” dla TCP (dzielenie i łączenie pakietów, sortowanie pakietów w strumienie, itp.), które zostały zaprojektowane w celu zmniejszenia obciążenia procesora, a większość z nich nie działa dla UDP.

— Brendan

Teraz może się zmienić sytuacja, w której QUIC ( en.wikipedia.org/wiki/QUIC ), który będzie częścią HTTP / 3, który używa UDP i jest domyślnie szyfrowany przy użyciu TLS. To zajmie trochę czasu, zanim będzie to szeroko dostępne i jest na co czekać. Więcej informacji na temat niektórych problemów, które należy rozwiązać tutaj blog.cloudflare.com/the-road-to-quic

— ARau

Założeniem byłoby powiedzieć, że „Internet jest teraz dość szybki i niezawodny”, jak zauważył @Ordous, a także niebezpieczny.

Powodem, dla którego niestandardowy protokół UDP + dla pakietów o kluczowym znaczeniu dla dostawy działa magicznie w większości gier jest to, że czasami może być „w porządku”, jeśli stracisz jakiś pakiet (np. Na przykład np. Drugorzędne niekrytyczne zdarzenia, aby ukończyć grę) , zdarzają się też sytuacje, w których „wcale nie jest w porządku” utrata niektórych danych, np. ruchów kursora itp. (Nie zajmuję się tworzeniem gier na życie, więc wybaczcie moje niejasne przykłady)

Domyślnie UDP nie marnuje czasu na popychanie ich raz po raz.

I, nawiasem mówiąc, w wielu grach wydaje się, że pakiety „są w stanie zgubić czasem” więcej niż „zawsze muszą dostarczać pakiety bezbłędnie”. Stąd naturalne dopasowanie do tego zadania.

UDP wymagało jedynie użycia niestandardowego protokołu, który po prostu pomaga prawidłowo dostarczać pakiety „zawsze trzeba dostarczać bezawaryjnie”, pozostawiając resztę danych gry na łasce połączenia sieciowego.

Teraz decyzja o tym, jaki rodzaj ruchu stanowi większość TWOICH danych, które mają być przekazywane, pomoże ci podjąć lepszą decyzję.

Chodzi o to, że TCP powinien polegać na tym, że czas poświęcony na ponawianie prób mógłby raczej zostać poświęcony na wysyłanie pakietów, które mają znaczenie TERAZ.

Istnieje również szansa, że jeśli wystąpi jakiś problem podczas transmisji, TCP może przejść kaskadowo do bardziej zepsutego scenariusza rozgrywki dla użytkownika, psując jego wrażenia w porównaniu do UDP + Custom Stack (ta ostatnia część jest po prostu przeczuciem. Wyjdę komentują to inni eksperci. Chciałbym dowiedzieć się o możliwościach tego scenariusza).

— Naresh Kumar
źródło