¿Por qué la creación de una nueva conexión TCP se considera costosa?

9

No entiendo por qué crear una nueva conexión TCP se considera una tarea costosa. Básicamente, configurar una nueva conexión se refiere a realizar el protocolo de enlace de 3 vías de TCP. Eso es enviar dos paquetes y recibir uno. Teniendo en cuenta que seguirán miles de paquetes (de datos), el apretón de manos no puede ser la parte costosa. ¿Puede?

networking tcp

¿Quizás debido al uso de CPU y memoria de las conexiones?

— joeqwerty

@joeqwerty Entiendo que una nueva conexión TCP generalmente también significa crear un nuevo proceso / hilo en, por ejemplo, el servidor, pero eso no se debe a TCP, sino a la aplicación.

Si siguen miles de paquetes de datos, los apretones de manos no son la parte costosa. Pero, ¿por qué no usar una nueva conexión TCP para cada fragmento de datos? Porque crear una nueva conexión TCP es costoso. Es por eso que establece una conexión y luego la usa para miles de fragmentos de datos.

— David Schwartz

1

También tenga en cuenta que la creación de una nueva conexión podría no estar limitada solo al protocolo de enlace TCP. Por ejemplo, SSL agrega mucha negociación de detalles de autenticación y cifrado en la parte superior.

— Zoredache

10

En general, creo que abrir una conexión TCP se considera costoso en comparación con la capacidad de reutilizar conexiones ya abiertas al mantenerla abierta. Tiene razón, abrir una conexión tomará solo 3 paquetes / turnos, pero esa vez, 3 veces su RTT, va mucho más allá del costo de reutilizar una conexión ya abierta, que está mucho más cerca de 0. La disparidad aumenta aún más rápido si usted Estamos abriendo y cerrando conexiones con frecuencia.

Sin embargo, ciertamente tiene razón, en comparación con la cantidad de vueltas que verá, ya que la aplicación "hace las cosas", esos 3 paquetes pueden parecer bastante pequeños, pero de nuevo, depende de cómo desee comparar las opciones Y cómo se comporta su aplicación / cuántas veces planea abrir una conexión.

Editar Sin embargo, si estamos hablando de UDP vs. TCP, Cheekaleek aquí es 100% correcto: la sobrecarga es masiva a largo plazo en comparación con las operaciones sin conexión de UDP

— Univ426
fuente

1

Un buen ejemplo que he visto en un paquete de rastreo: una conexión MySQL reutilizada puede cambiar las consultas en 2-5ms. Una serie de consultas de ElasticSearch da vuelta a las consultas en 17-25 ms, la mayor parte de ese tiempo estaba en la configuración de la conexión (incluida la búsqueda inicial de DNS).

— sysadmin1138

2

Ciertamente es más sobrecarga que enviar un paquete UDP y no importarle lo que pase después de eso.

TCP también viene con más datos de encabezado y mantiene el estado de conexión, que consumirá recursos.

Entonces, sí, en comparación con UDP, TCP es más caro, pero caro es un término relativo.

"¿Las conexiones TCP son las mejores amigas de una chica?"

— HostBits
fuente

55

"TCP connections are a girl's best friend???" No, no lo son. Obtuve miles de ellas para su cumpleaños y todo lo que hizo fue dejar de devolver mis correos electrónicos. :(

— HopelessN00b

2

No se trata solo de enviar y recibir paquetes. Se debe asignar memoria adicional y, como mínimo, actualizar las tablas de estado de red en cada paso hasta que se establezca la sesión. Sin mencionar las comprobaciones de seguridad adicionales que se pueden realizar (protección de falsificación de rutas, etc.).

Simplemente usando algunos números de ejemplo (porque no estamos hablando de ningún sistema operativo específico) si un paquete para una sesión establecida tiene un costo de CPU de 1 unidad, el costo de una nueva sesión puede ser 10x o 100x ese costo en la cantidad de operaciones realizadas La mayoría de los firewalls de hardware con los que he trabajado pueden manejar un orden de magnitud menos conexiones nuevas por segundo de lo que pueden manejar sesiones establecidas.

A menudo no es tan importante, especialmente porque un SYN-SYN / ACK-ACK ocurre en milisegundos, pero para sistemas grandes con muchos clientes, las nuevas sesiones pueden convertirse en una sobrecarga significativa .

— bahamat
fuente

2

La cantidad o tipo de tráfico importa mucho menos que el código asociado con la asignación real de memoria y el seguimiento asociado de la información de estado. Si desea tener una idea muy aproximada de lo que esto implica, eche un vistazo a la cantidad de código en el kernel de Linux asociado con TCP versus el asociado con UDP o ICMP. Una comparación increíblemente aproximada muestra que TCP requiere algo como 10 veces el número de líneas de código encontradas en UDP.

En las redes IP, la cantidad de mantenimiento de estado requerida es uno de los determinantes más importantes de la escalabilidad. Para los puntos finales TCP, esto se expresa no solo en SYN / ACK, sino también en el mantenimiento continuo de ventanas deslizantes, números de secuencia, gestión de búfer y acciones de QoS, etc. Compruebe la complejidad del FSM para tcp y considere la falta inherente de los mismos en UDP ...

— rnxrx
fuente