Perché il mio throughput TCP è molto maggiore del throughput UDP?

Non ho fatto nulla di insolito per le mie configurazioni hardware o del kernel (tutte le impostazioni predefinite, nuova installazione del sistema operativo, stack TCP / IP 3.11 del kernel Linux) e sto facendo una media di circa 3,83 milioni di messaggi al secondo tramite TCP mentre sto solo facendo una media di 0,75 milioni di messaggi al secondo tramite UDP. Questo sembra sfidare completamente ciò che mi aspetto dai due protocolli.

Qual è la causa più probabile della drastica differenza e come posso diagnosticarla su 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

Per questo test ho due server di test identici e collegati direttamente tramite un cavo crossover 10G. Le schede di rete utilizzate in questo caso sono Intel X520 con configurazioni predefinite e collegate a uno slot PCIe 3.0 x8 sulla scheda madre, che comunica con la CPU tramite un controller NUMA.

— elleciel
fonte

Come hai fatto i benchmark? Contro ciò che hai inviato quei pacchi?

— Braiam

Ho usato netperfper i benchmark, i test UDP_STREAM e TCP_STREAM, fissati sulla stessa CPU e le dimensioni dei messaggi a 64 byte.

— elleciel,

Questo non risponde alla domanda di @ Braiam. La topologia di rete è e il metodo di test dettagliato è importante, qui.

— Pavel Šimerda,

@ PavelŠimerda Siamo spiacenti, pensavo che chiedesse solo la metodologia di test. Per quanto riguarda la topologia di rete, i due server di test sono identici e collegati direttamente tramite un cavo crossover 10G. Le schede di rete utilizzate in questo caso sono Intel X520 con configurazioni predefinite e collegate a uno slot PCIe 3.0 x8 sulla scheda madre, che comunica con la CPU tramite un controller NUMA. Questo risponde alla tua domanda?

— elleciel,

Sì, @elleciel, risponde sicuramente alla mia domanda. Anche se in questo caso non ho l'esperienza per darti la risposta per le macchine connesse direttamente. Vedo che hai modificato la domanda stessa, il che è fantastico. Risolverò la domanda come ora sono anche interessato.

— Pavel Šimerda,

Oltre a non ottenere informazioni dettagliate sulla configurazione del test, sembra che il problema principale sia l'utilizzo di una dimensione del messaggio di 64 byte. Questo è lontano dal solito MTU di 1500 byte e rende UDP altamente inefficiente: mentre TCP unisce più invii in un singolo pacchetto sul filo (tranne se è impostato TCP_NODELAY) per fare un uso efficiente del collegamento, ogni messaggio UDP comporterà un pacchetto separato. In numeri: circa 23 messaggi di dimensioni 64 byte verranno combinati in un singolo pacchetto TCP di dimensioni MTU, mentre per UDP saranno necessari 23 pacchetti singoli per la stessa quantità di dati. Ognuno di questi pacchetti significa sovraccarico con l'invio dall'host, la trasmissione sul filo e la ricezione da parte del peer. E come visto nel tuo caso, circa l'80% dei pacchetti UDP si perde perché l'hardware non è abbastanza veloce per trasmettere e ricevere tutti questi pacchetti.

Quindi quello che puoi imparare da questo benchmark è:

UDP non è affidabile (perdita di pacchetti dell'80%)
UDP è inefficiente se utilizzato con dimensioni di pacchetti molto inferiori a MTU
TCP è altamente ottimizzato per sfruttare al meglio il collegamento

Per quanto riguarda le tue aspettative, UDP dovrebbe essere migliore: ti sei mai chiesto perché tutti i principali trasferimenti di file (ftp, http, ...) vengano eseguiti con protocolli basati su TCP? Il benchmark ti mostra il motivo.

Quindi perché le persone usano UDP?

Con i dati in tempo reale (ad es. Voice over IP) non ti interessano i messaggi più vecchi, quindi non vuoi che il mittente combini i messaggi in pacchetti più grandi per fare un uso efficace del collegamento. E piuttosto accetti che un pacchetto si perda piuttosto che farlo arrivare troppo tardi.
Con i collegamenti ad alta latenza (come con i satelliti), il comportamento predefinito del TCP non è ottimale per un uso efficace del collegamento. Quindi alcune persone passano a UDP in questo caso e implementano nuovamente il livello di affidabilità di TCP e lo ottimizzano per i collegamenti ad alta latenza, mentre altri ottimizzano lo stack TCP esistente per utilizzare meglio il collegamento.
"getta via" i dati: a volte è più importante inviare i dati via e non preoccuparsi della perdita di pacchetti, come con i messaggi di registro (syslog)
Interazioni brevi: con TCP è necessario stabilire una connessione e mantenere uno stato, che costa tempo e risorse su client e server. Per interazioni brevi (come richieste brevi e risposte) questo potrebbe essere un sovraccarico eccessivo. Per questo motivo il DNS di solito viene eseguito con UDP ma ha creato nuovi tentativi su UDP.

— Steffen Ullrich
fonte

Dovresti anche dare un'occhiata alla tua perdita di pacchetti dell'80% con UDP. Sembra che il tuo hardware non sia abbastanza veloce per elaborare i pacchetti con la stessa velocità con cui vengono inviati. Mentre TCP si adatta a questo tipo di perdita di pacchetti con il rallentamento, UDP invierà alla stessa velocità e continuerà a perdere pacchetti. Ma alla fine non è rilevante la velocità con cui puoi inviare, ma ciò che ricevi.

— Steffen Ullrich,

Qualcos'altro che potrebbe essere un fattore è l'accelerazione / offloading TCP sulla scheda di rete (se supportata).

— cpugeniusmv,

L'invio di pacchetti potrebbe essere più efficiente della ricezione, soprattutto se l'ultimo è guidato dall'interruzione.

— Steffen Ullrich,

le persone usano anche UDP per un dispositivo incorporato per trasmettere i dati che sta raccogliendo su un filo e non si preoccupano della configurazione della connessione

— maniaco del cricchetto

Molto probabilmente sei IO legato dal bus PCI Express. Le schede di rete avranno l'offload del segmento TCP abilitato, molto probabilmente. Ciò significa che i trasferimenti TCP verranno inviati alla scheda come un unico grande blocco, quindi la scheda si divide e li suddivide in pacchetti e li mette sul filo. Non esiste un equivalente per UDP, quindi il risultato è una transazione PCIe (e tutte le spese generali associate) per ciascun pacchetto.

— alex.forencich