¿TCP envía un SYN / ACK en cada paquete o solo en la primera conexión?


Tengo un servidor TCP que escucha un cliente entrante, luego le envía un paquete de datos cada segundo. Me preguntaba, ¿el paquete SYN/ACK solo se envía en la conexión inicial, por lo que se ve así:

<client connect>
SYN
ACK
DATA
DATA
DATA
<client disconnect>

¿O se envía con cada paquete, así?

<client connect>
SYN
ACK
DATA

SYN
ACK
DATA

SYN
ACK
DATA
<client disconnect>

Además, si es el primer caso, ¿hay algún beneficio de UDP sobre TCP si solo mantiene la conexión abierta durante un largo período de tiempo?

Author: Daniel T., 2010-08-31

3 answers

Es como:

+-------------------------------------------------------+
|     client           network            server        |
+-----------------+                +--------------------|
|    (connect)    | ---- SYN ----> |                    |
|                 | <-- SYN,ACK -- |     (accepted)     |
|   (connected)   | ---- ACK ----> |                    |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/

when client sends...
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
|                 |                |                    |
|     (send)      | ---- data ---> |                    |
|                 | <---- ACK ---- |  (data received)   |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/

when server sends...
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
|                 |                |                    |
|                 | <--- data ---- |       (send)       |
| (data received) | ---- ACK ----> |                    |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/

...and so on, til the connection is shut down or reset

SYN inicia una conexión; normalmente solo la verá cuando se establezca la conexión. Pero todos los datos que se envían a través de TCP requieren un ACK. Cada byte enviado debe ser contabilizado, o será retransmitido (o el restablecimiento de conexión (cerrado), en casos graves).

Las conexiones reales no suelen ser exactamente como el diagrama anterior, sin embargo, por dos razones:

  • Los ACKS pueden acumularse, por lo que un ACK puede reconocer todo recibido hasta ese punto. Eso significa que puede reconocer dos o más envíos con un ACK.
  • Un ACK es simplemente una bandera y un campo en una cabecera TCP. El envío de uno requiere al menos el valor de un ancho de banda de cabecera, además de lo que las capas inferiores viran. Pero los segmentos de datos ya incluyen todos that...so si estás enviando datos, puedes enviar un ACK al mismo tiempo de forma gratuita.

La mayoría de las pilas TCP/IP intentan reducir el número de ACKs desnudos sin arriesgar indebidamente la retransmisión o un reinicio de conexión. Así que una conversación como esta es bastante posible:

\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
|                 |                |                    |
|                 | <--- data ---- |       (send)       |
| (data received) |                |                    |
|     (send)      | -- data,ACK -> |                    |
|                 |                |  (data received)   |
|                 | <- data,ACK -- |       (send)       |
| (data received) |                |                    |
|  (wait a bit)   | <--- data ---- |       (send)       |
| (data received) |                |                    |
|     (send)      | -- data,ACK -> |                    |
|                 |                |  (data received)   |
|     (send)      | ---- data ---> |   (wait a bit)     |
|                 |                |  (data received)   |
|                 | <- data,ACK -- |       (send)       |
| (data received) |                |                    |
|  (wait a bit)   |   (dead air)   |                    |
|                 | ---- ACK ----> |                    |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/

En cuanto a UDP, no hay un concepto incorporado de SYN y ACK U UDP es por naturaleza "poco confiable", y no está orientado a la conexión, por lo que los conceptos no se aplican tanto. Su acuse de recibo generalmente será solo la respuesta del servidor. Pero algunos protocolos de capa de aplicación construidos sobre UDP tendrán alguna forma específica de reconocer los datos enviados y recibidos.

 66
Author: cHao,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-09-02 21:34:27

SYN es solo al principio.

ACK está en segmentos subsecuentes en cualquier dirección. [editar]El ACK también definirá un tamaño de ventana. Si el tamaño de la ventana es 100, por ejemplo, el remitente puede enviar 100 segmentos antes de esperar recibir un ACK. Por ejemplo, si el remitente envía 100 segmentos pero el número de segmento 50 se pierde, el receptor obtendrá 1-49 y 51-100. Receptor entonces ACK para 50 (siguiente segmento que espera) y establecer el tamaño de la ventana a 1. El remitente volverá a enviar 1 segmento con el número de secuencia 50. Receptor entonces ACK para 101 y establecer el tamaño de la ventana de nuevo a un número mayor [editar]

Ambos son realmente campos en el encabezado TCP y se pueden enviar con datos, aunque el SYN y el primer ACK típicamente son sin datos.

Así que ninguno de los escenarios que describes es del todo correcto. El primero es realmente más cercano a la realidad, pero todos los paquetes de datos después del SYN tienen que incluir un ACK, y también un campo de número de reconocimiento que identifica el número del siguiente paquete previsto.

El final de una sesión también implica apretones de manos con paquetes marcados con FIN y ACKs relacionados con ellos.

Los números de secuencia intercambiados se utilizan para identificar paquetes perdidos y habilitar un mecanismo de reintento, y también para volver a ensamblar todo el flujo de paquetes en el orden correcto.

Además, si es el primer caso, ¿hay algún beneficio de UDP sobre TCP si solo mantiene la conexión abierta durante un largo período de tiempo?

Con UDP no puedes simplemente mantenga la conexión abierta durante un largo período de tiempo. No hay conexión.

Esta secuencia de indicadores SYN/ACK/FIN es lo que hace una conexión.

Con UDP, no hay SYN ni ACKs, por lo que la comunicación es unidireccional, la entrega no está garantizada y el pedido no se conserva. Pero tiene menos sobrecarga, por lo que es útil cuando la velocidad es más importante que la fiabilidad, como por ejemplo en streaming media.

Esto es un poco simplificado todavía, pero es lo mejor que puedo hacer en el momento.

Hay mucho más sobre esto en la entrada de wikipedia en TCP y, por supuesto, en los RFC.

 10
Author: Don Roby,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-04-15 13:04:12

Imagine esto: Sin embargo, el estándar TCP original RFC 793 permitía enviar datos con el primer paquete SYN. Sin embargo, ese no es el caso hoy. Lo que obtienes es un paquete SYN separado durante el inicio del Apretón de Manos de Tres Vías del solicitante de la conexión. Supongamos que A solicita conectarse con B, por lo tanto A envía un paquete con un conjunto de bits SYN. B responde con un ACK para acusar recibo y envía A los paquetes ACK + SYN. Los datos pueden transmitirse a partir de ahora.

Dordal tiene una muy buena explicación sobre este asunto. Haga clic en este enlace aquí.

 0
Author: StacknormalFlow,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-12-30 18:54:06