Sobrecarga general de crear una conexión TCP

Question

Me gustaría saber el costo general de crear una nueva conexión, en comparación con UDP. Sé que TCP requiere un intercambio inicial de paquetes (el apretón de manos de 3 vías). ¿Cuáles serían otros costos? Por ejemplo, ¿hay algún tipo de magia en el kernel necesaria para configurar búferes, etc.?

La razón por la que estoy preguntando es que puedo mantener abierta una conexión existente y reutilizarla si es necesario. Sin embargo, si hay poca sobrecarga volviendo a conectar, se reduciría la complejidad.

Answer 1

En comparación con la latencia del intercambio de paquetes, todos los demás costos, como los tiempos de configuración del kernel, son insignificantes.

Answer 2

Una vez que un paquete UDP ha sido volcado en el cable, la pila del protocolo UDP puede olvidarse por completo. Con TCP, hay al mínimo los detalles de conexión (puerto de origen/destino y IP de origen/destino), el número de secuencia, el tamaño de la ventana para la conexión, etc ... No es una gran cantidad de datos, pero se suma rápidamente en una servidor ocupado con muchas conexiones.

Y luego está el handshake de 3 vías también. Algunos braindead (y/o sistemas maliciosos) pueden abusar del proceso (buscar 'syn flood'), o simplemente dejar caer la conexión en su extremo, dejando a su sistema esperando una respuesta o un aviso cercano que nunca llegará. El lado positivo es que con TCP, el sistema hará todo lo posible para asegurarse de que el paquete llegue donde debe. Con UDP, no hay garantías en absoluto.

Answer 3

OPCIÓN 1: El costo general de la creación de una conexión TCP son:

1. Crear conexión de socket
2. Enviar datos
3. Derribar conexión de socket

Paso 1: Requiere un intercambio de paquetes, por lo que se retrasa por & desde la latencia de la red más el tiempo de servicio del servidor de destino. No se requiere un uso significativo de la CPU en ninguna de las casillas.

Paso 2: Depende del tamaño del mensaje.

Paso 3: IIRC, acaba de enviar un paquete de 'cierre ahora', sin esperar la confirmación de destino, por lo que no hay latencia.

OPCIÓN 2: Costos de la UDP: *

1. crear el objeto UDP
2. Enviar datos
3. Cerrar objeto UDP

Paso 1: Se requiere un mínimo de configuración, no hay preocupaciones de latencia , muy rapido.

Paso 2: TENGA CUIDADO CON EL TAMAÑO, no hay retransmisión en UDP ya que no le importa si el paquete fue recibido por alguien o no. He oído que cuanto mayor es el mensaje, mayor es la probabilidad de que se reciban datos corruptos, y que una regla general es que perderá un cierto porcentaje de mensajes de más de 20 MB.

Paso 3: trabajo mínimo, tiempo mínimo.

OPCIÓN 3: Uso ZeroMQ lugar

que está comparando a TCP UDP con el objetivo de reducir el tiempo de reconexión. HAY UNA COMPROMISO AGRADABLE: zócalos ZeroMQ.

ZMQ le permite configurar un socket de publicación donde no le importe si alguien está escuchando (como UDP) y tiene múltiples oyentes en ese socket. Esto NO es un socket UDP, es una alternativa a ambos protocolos.

Ver: ZeroMQ.org para más detalles.

Es muy rápido y tolerante a fallas, y cada vez es más utilizado en la industria financiera por esos motivos.