¿Por qué mi rendimiento TCP es mucho mayor que el rendimiento UDP?

No he hecho nada inusual en mis configuraciones de hardware o kernel (todas las configuraciones predeterminadas, instalación nueva del sistema operativo, kernel de Linux 3.11 TCP / IP stack) y estoy promediando alrededor de 3.83 millones de mensajes por segundo a través de TCP mientras solo estoy promediando 0.75 millones de mensajes por segundo a través de UDP. Esto parece desafiar completamente lo que espero de los dos protocolos.

¿Cuál es la causa más probable de la diferencia drástica y cómo puedo diagnosticarla en 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

Para esta prueba, tengo dos servidores de prueba que son idénticos y están conectados directamente a través de un cable cruzado de 10G. Las NIC utilizadas en este caso son Intel X520 con configuraciones listas para usar y conectadas a una ranura PCIe 3.0 x8 en la placa base, que se comunica con la CPU a través de un controlador NUMA.

Además de no obtener información detallada sobre la configuración de la prueba, el principal problema parece ser que utiliza un tamaño de mensaje de 64 bytes. Esto está muy lejos de la MTU habitual de 1500 bytes y hace que UDP sea altamente ineficiente: mientras TCP combina múltiples envíos en un solo paquete en el cable (excepto si TCP_NODELAY está configurado) para hacer un uso eficiente del enlace, cada mensaje UDP dará como resultado un paquete separado En números: aproximadamente 23 mensajes de 64 bytes se combinarán en un solo paquete TCP de tamaño MTU, mientras que necesitará 23 paquetes individuales para UDP para la misma cantidad de datos. Cada uno de estos paquetes significa gastos generales con el envío desde el host, la transmisión por cable y la recepción por parte del par. Y como se ve en su caso, aproximadamente el 80% de los paquetes UDP se pierden porque su hardware no es lo suficientemente rápido como para transmitir y recibir todos estos paquetes.

Entonces, lo que puede aprender de este punto de referencia es:

• UDP no es confiable (80% de pérdida de paquetes)
• UDP es ineficiente si se usa con tamaños de paquetes muy por debajo de MTU
• TCP está altamente optimizado para hacer el mejor uso del enlace

En cuanto a sus expectativas, ese UDP debería ser mejor: ¿alguna vez se preguntó por qué todas las principales transferencias de archivos (ftp, http, ...) se realizan con protocolos basados ​​en TCP? El punto de referencia te muestra el motivo.

Entonces, ¿por qué la gente usa UDP?

• Con los datos en tiempo real (por ejemplo, voz sobre IP), no le interesan los mensajes más antiguos, por lo que no desea que el remitente combine los mensajes en paquetes más grandes para hacer un uso efectivo del enlace. Y prefiere aceptar que se pierda un paquete que llegar demasiado tarde.
• Con enlaces de alta latencia (como con los satélites) el comportamiento predeterminado de TCP no es óptimo para hacer un uso efectivo del enlace. Por lo tanto, algunas personas cambian a UDP en este caso y vuelven a implementar la capa de confiabilidad de TCP y la optimizan para enlaces de alta latencia, mientras que otras ajustan la pila TCP existente para hacer un mejor uso del enlace.
• datos "desechables": a veces es más importante enviar los datos y no preocuparse por la pérdida de paquetes, como ocurre con los mensajes de registro (syslog)
• Interacciones breves: con TCP necesita establecer una conexión y mantener un estado, lo que cuesta tiempo y recursos en el cliente y el servidor. Para interacciones cortas (como solicitud y respuesta cortas), esto podría ser una sobrecarga. Debido a esto, el DNS generalmente se realiza con UDP, pero ha creado reintentos sobre UDP.