Dlaczego nie należy stosować myślenia TCP do UDP
Categories:
- Dlaczego nie należy stosować myślenia TCP do UDP
Dlaczego nie należy stosować myślenia TCP do UDP?
Różnice strukturalne


Koncepcje TCP są liczne: nawiązanie połączenia, wykorzystanie zasobów, przesyłanie danych, niezawodna transmisja, retransmisja oparta na potwierdzeniach skumulowanych, retransmisja po przekroczeniu limitu czasu, suma kontrolna, kontrola przepływu, kontrola przeciążenia, maksymalny rozmiar segmentu, potwierdzenie wyboru, opcja skalowania okna TCP, znacznik czasu TCP, wymuszone przekazanie danych, zakończenie połączenia.
UDP nie posiada większości z tych możliwości, oferując jedynie nieco większą niż warstwa łącza zdolność rozróżniania aplikacji docelowych. UDP jest wystarczająco proste, aby być elastycznym.
Jeśli może się zdarzyć, to się zdarzy
Prawo Murphy’ego:
Jeśli istnieje więcej niż jeden sposób wykonania czegoś, a jeden z nich prowadzi do katastrofy, to ktoś na pewno wybierze ten sposób.
Często mówi się, że UDP nadaje się do gier/wideo/głosu itp., ponieważ niewielka liczba błędnych pakietów nie wpływa na działanie usługi. Dlaczego UDP nadaje się do tych zastosowań? To, że UDP może być używane w tych przypadkach, nie oznacza, że jest to optymalne rozwiązanie, konieczne jest istnienie problemów, których TCP nie potrafi rozwiązać, co skłania te usługi do wyboru protokołu UDP o ograniczonych funkcjach. Błędne pakiety nie wpływają na usługę, co oznacza, że TCP dba o błędne pakiety, a UDP nie. UDP dba bardziej o rzeczywistość/ciągłość. UDP charakteryzuje się tym, że nie dba o czynniki, o które dba TCP, a te czynniki wpływają na rzeczywistość.
W implementacji kodu, UDP wymaga jedynie utworzenia gniazda i powiązania go z portem, aby móc rozpocząć odbiór i wysyłanie. Zazwyczaj, gdy gniazdo zostanie zużyte, port również zostaje zużyty.
Można więc używać UDP w następujący sposób:
- Wysyłać losowe pakiety do dowolnych portów dowolnego IP i sprawdzać, który port odpowiada.
- A wysyła żądanie z portu A do portu B B; B wysyła odpowiedź z portu C do portu D A.
- A wysyła żądanie z portu A do portu B B; B deleguje C, aby wysłać odpowiedź z portu C do portu D A.
- A wysyła żądanie z portu A do portu B B, ale zmienia źródłowy IP na IP C, więc B wyśle odpowiedź do C.
- Strony uzgadniają, że każda użyje 10 portów UDP, jednocześnie odbierając i wysyłając.
Te metody nie działają w TCP, ale w protokole UDP, jeśli da się to zrobić, to ktoś to zrobi. Dlatego stosowanie niektórych myślenia TCP do UDP jest idealistyczne; rzeczywistość jest zawsze inna niż możemy wyliczyć.
Pakiet UDP jest bardzo prosty i elastyczny, nie ma pierwotnie pojęcia połączenia, trzeba samodzielnie definiować połączenie UDP. Próbowałem kilku metod definicji, ale żadna nie może dokładnie osiągnąć celu rozpoznawania kierunku połączenia, więc trzeba przyjąć pewne błędy,毕竟原本就没有 UDP 连接的定义, 当各方对 UDP 连接的定义不一致时, 必然会导致行为与预期不一样.
Perspektywa klienta UDP
Głos/wideo itp. często powodują utratę pakietów, ale różne sposoby utraty pakietów mają różne skutki na usługę. Na przykład, czy 30% utraty pakietów jest równomiernie rozłożone, czy zgromadzone w pewnym okresie, ma wyraźny wpływ na doświadczenie użytkownika. Oczywiście oczekujemy bardziej równomiernej utraty pakietów. Ale UDP nie ma metody kontroli przepływu, więc sposób utraty pakietów ma pewne metody. Mimo że komunikacja UDP jest często opisywana jako “najlepsza stara”, różne sposoby “najlepszej stary” osiągają różne efekty.
Perspektywa dostawcy usług UDP
W atakach TCP klient musi ponieść pewne koszty, tworzyć połączenia, utrzymywać połączenia, czyli atakujący musi ponieść pewne koszty. W atakach UDP atakujący ponosi znacznie mniejsze koszty. Jeśli atakujący chce zużyć przepustowość usługodawcy, UDP jest dobrym sposobem. Na przykład, jeśli usługa kupuje 100 GB nieograniczonego ruchu, ale ma zdolność przetwarzania tylko 10 MB na sekundę, a prędkość odbioru to 1 GB na sekundę, to 90% ruchu żądań jest nieważne, ale ten ruch nie jest darmowy. Strona usługodawcy powinna unikać takiej sytuacji.
Perspektywa operatora UDP
Komunikacja wymaga wielu terminali i kanałów komunikacyjnych. Zawsze skupiamy się na serwerze i kliencie, ale perspektywa operatora jest również ważna. W atakach DDoS zawsze interesujemy się zużyciem zasobów serwera, ale zasoby operatora są również ograniczone. Serwer może po prostu nie odpowiadać na żądania, ale odbieranie ruchu już zużywa przepustowość, a ten zasób należy do operatora. Dlatego operator również stara się zablokować ten ruch, czyli QoS UDP. W TCP istnieje kontrola przeciążenia, ale w UDP operator może kontrolować ruch poprzez utratę pakietów. W rzeczywistości operator jest jeszcze prostszy, po prostu blokuje ruch z długotrwale używanych portów, czyli blokowanie portów UDP. W rzeczywistym teście rozmowy przez WeChat odkryliśmy, że każdy telefon klienta używa wielu portów, z których jeden port UDP komunikuje się z 6 portami UDP tego samego serwera, co sugeruje, że jest to reakcja na blokowanie portów przez operatora.
Podsumowanie
Elastyczność UDP oznacza, że podczas realizowania celu istnieje wiele sposobów implementacji, a wszystkie są legalne. Dopóki ostatecznie zostanie osiągnięta stabilna komunikacja, nie ma znaczenia, jak bardzo różni się to od TCP. To jest “istnieje, więc jest uzasadnione”. Dlatego nie można całkowicie przenosić pojęć TCP na UDP. Nawet jeśli dla projektowania produktu tworzy się nową definicję połączenia UDP, należy przewidywać i dopuszczać błędy,毕竟允许出错就是 UDP 的核心功能, 这是 UDP 的优势, 不是它的缺点, 是服务主动选择的协议核心能力, 而不是不得不接受的缺点.
Więcej do przeczytania
- 20 tysięcy słów, aby nauczyć się zasad QoS
- Protocol sterowania transmisją
- Protocol użytkownika datagramu