Dlaczego moja przepustowość TCP jest znacznie większa niż przepustowość UDP?

Nie zrobiłem nic niezwykłego dla moich konfiguracji sprzętowych lub jądra (wszystkie ustawienia domyślne, świeża instalacja systemu operacyjnego, jądro Linux 3.11 stos TCP / IP) i uśredniam około 3,83 miliona wiadomości na sekundę przez TCP, podczas gdy ja tylko średnio 0,75 milion wiadomości na sekundę za pośrednictwem UDP. Wydaje się to całkowicie przeczyć temu, czego oczekuję od obu protokołów.

Jaka jest najbardziej prawdopodobna przyczyna drastycznej różnicy i jak mogę ją zdiagnozować na Ubuntu 13.10?

#TCP RESULTS
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

87380  65536     64    10.00      1963.43   32.96    17.09    5.500   2.852

#UDP RESULTS
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

4194304      64   10.00     7491010      0      383.5     28.97    24.751
212992            10.00     1404941              71.9     25.03    21.381

Do tego testu mam dwa serwery testowe, które są identyczne i bezpośrednio połączone kablem krosowym 10G. W tym przypadku używane są karty sieciowe Intel X520 z gotowymi konfiguracjami i podłączone do gniazda PCIe 3.0 x8 na płycie głównej, które komunikuje się z procesorem poprzez kontroler NUMA.

Oprócz nie uzyskania szczegółowych informacji o konfiguracji testu wydaje się, że głównym problemem jest to, że używasz wiadomości o rozmiarze 64 bajtów. Jest to dalekie od zwykłej MTU wynoszącej 1500 bajtów i powoduje, że UDP jest bardzo nieefektywny: podczas gdy TCP łączy wiele wysyłek w jeden pakiet w przewodzie (z wyjątkiem, jeśli ustawiony jest TCP_NODELAY), aby efektywnie wykorzystać łącze, każda wiadomość UDP spowoduje osobny pakiet. Liczbowo: około 23 wiadomości o rozmiarze 64 bajtów zostanie połączonych w pojedynczy pakiet TCP o rozmiarze MTU, podczas gdy będzie potrzebował 23 pojedynczych pakietów dla UDP dla tej samej ilości danych. Każdy z tych pakietów oznacza narzut związany z wysyłaniem z hosta, przesyłaniem przewodowym i odbieraniem przez partnera. I jak widać w twoim przypadku, około 80% pakietów UDP gubi się, ponieważ twój sprzęt nie jest wystarczająco szybki, aby przesyłać i odbierać wszystkie te pakiety.

Czego możesz się nauczyć z tego testu porównawczego:

• UDP jest zawodny (utrata pakietów 80%)
• UDP jest nieefektywny, jeśli jest używany z rozmiarami pakietów znacznie poniżej MTU
• TCP jest wysoce zoptymalizowany, aby jak najlepiej wykorzystać łącze

Jeśli chodzi o twoje oczekiwania, to UDP powinno być lepsze: czy kiedykolwiek zastanawiałeś się, dlaczego wszystkie główne transfery plików (ftp, http, ...) są wykonywane przy użyciu protokołów opartych na TCP? Benchmark wskazuje przyczynę.

Dlaczego ludzie w ogóle korzystają z UDP?

• W przypadku danych w czasie rzeczywistym (np. VoIP) nie przejmujesz się starszymi wiadomościami, więc nie chcesz, aby nadawca łączył wiadomości w większe pakiety, aby efektywnie korzystać z łącza. A raczej akceptujesz fakt, że pakiet się gubi, niż spóźnienie.
• W przypadku łączy o dużym opóźnieniu (jak w przypadku satelitów) domyślne zachowanie protokołu TCP nie jest optymalne, aby efektywnie korzystać z łącza. Dlatego niektóre osoby przełączają się w tym przypadku na UDP i ponownie wdrażają warstwę niezawodności TCP i optymalizują ją pod kątem łączy o dużych opóźnieniach, podczas gdy inne dostrajają istniejący stos TCP, aby lepiej wykorzystać łącze.
• „wyrzucanie” danych: czasami ważniejsze jest wysyłanie danych i nie przejmowanie się utratą pakietów, jak w przypadku komunikatów dziennika (syslog)
• Krótkie interakcje: z TCP musisz nawiązać połączenie i utrzymać stan, który kosztuje czas i zasoby na kliencie i serwerze. W przypadku krótkich interakcji (takich jak krótkie żądanie i odpowiedź) może to być zbyt duże obciążenie. Z tego powodu DNS jest zwykle wykonywany za pomocą UDP, ale ma wbudowane ponownych prób na UDP.