Чому моя пропускна здатність TCP набагато більша, ніж пропускна здатність UDP?

Я не робив нічого незвичайного для моєї конфігурації апаратного забезпечення або ядра (всі налаштування за замовчуванням, свіжа установка ОС, Linux ядро ​​3.11 TCP / IP стек), і я в середньому використовую близько 3,83 мільйона повідомлень за секунду через TCP, тоді як я лише в середньому становить 0,75 мільйон повідомлень в секунду через UDP. Це, здається, повністю спростує те, що я очікую від двох протоколів.

Яка найімовірніша причина різкої різниці і як я можу діагностувати це на 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

Для цього тесту у мене є два тестових сервера, які однакові і безпосередньо підключені через крос-кросс 10G. NIC, що використовуються в цьому випадку, - це Intel X520 з нестандартною конфігурацією та підключений до слота PCIe 3.0 x8 на материнській платі, який спілкується з процесором через контролер NUMA.

Окрім того, що ви не отримуєте детальної інформації про тестові установки, головна проблема, мабуть, полягає в тому, що ви використовуєте повідомлення розміром 64 байт. Це далеко від звичайного MTU в 1500 байт і робить UDP дуже неефективним: в той час як TCP об'єднує декілька відправлень в один пакет по дроту (за винятком випадків, коли встановлено TCP_NODELAY) для ефективного використання посилання, кожне повідомлення UDP призведе до окремий пакет. У цифрах: близько 23 повідомлень розміром 64 байт буде об’єднано в один TCP-пакет розміром MTU, тоді як для такої кількості даних йому знадобиться 23 одиночні пакети для UDP. Кожен з цих пакетів означає накладні витрати з відправленням від хоста, передачею по проводу і прийому однорангом. І, як видно у вашому випадку, близько 80% пакетів UDP втрачаються через те, що ваше обладнання недостатньо швидко для передачі та отримання всіх цих пакетів.

Тож, про що можна дізнатися з цього еталону, це:

• UDP недостовірний (втрата пакету 80%)
• UDP неефективний, якщо використовується з розмірами пакетів значно нижче MTU
• TCP дуже оптимізований для найкращого використання посилання

Що стосується ваших очікувань, що UDP має бути кращим: ви коли-небудь замислювалися, чому всі основні передачі файлів (ftp, http, ...) здійснюються за допомогою протоколів на основі TCP? Тест показує вам причину.

То чому люди взагалі використовують UDP?

• З даними в реальному часі (наприклад, голосом через IP) вам не байдуже старіші повідомлення, тому ви не хочете, щоб відправник поєднував повідомлення у більші пакети, щоб ефективно використовувати посилання. І ви швидше приймаєте, що пакет втрачається, ніж змушувати його надто пізно.
• За високої затримки (наприклад, із супутниками) поведінка TCP за замовчуванням не є оптимальною для ефективного використання посилання. Тож деякі люди переходять на UDP в цьому випадку і повторно реалізують рівень надійності TCP та оптимізують його для посилань з високою затримкою, а інші налаштовують існуючий стек TCP, щоб краще використовувати посилання.
• "викинути" дані: іноді важливіше відправляти дані геть і не турбуватися про втрату пакету, як, наприклад, повідомлення журналу (syslog)
• Короткі взаємодії: з TCP вам потрібно встановити з'єднання, підтримувати стан, який коштує часу та ресурсів у клієнта та сервера. Для коротких взаємодій (наприклад, короткого запиту та відповіді) це може бути занадто великим накладним витратом. Через це DNS зазвичай робиться за допомогою UDP, але він має вбудовані спроби поверх UDP.