Protocolos de red: en el protocolo de enlace TCP 3, ¿por qué necesitamos el tercer ACK?

En aras de la discusión, supongamos que el tercer ACK no es necesario. En ese caso, la conexión se verá así:

Enviador recibidor
SYN
————————> (Conexión establecida en el receptor)

SYN + ACK
<———————— (Conexión establecida en el remitente)

La secuencia de pasos anterior muestra lo que debería suceder idealmente. Ahora, qué fácil es hacer un ataque DOS. Simplemente, envíe un paquete SYN al receptor y se abrirá una conexión en el receptor. El remitente ni siquiera necesita preocuparse por el paquete (SYN + ACK) que regresa de Receiver.

Por otro lado, el apretón de manos de 3 vías se ve así:
Enviador recibidor
SYN
————————>

SYN + ACK
<———————— (Conexión establecida en el remitente)

ACK
————————> (Conexión establecida en el receptor)

El caso anterior todavía es posible en un protocolo de enlace de 3 vías, pero al menos en este caso, no hay una conexión medio abierta en el receptor. Entonces, si el paquete ACK regresa del remitente, el receptor puede asumir que:
1. La conexión estaba abierta en el remitente.
2. El remitente está realmente interesado en establecer una conexión con Receiver.
Además, el paquete ACK de Sender también puede contener datos reales, por lo que no es un desperdicio total.

La respuesta de Diwakar Tundlam a In TCP, el cliente envía un SYN y luego el servidor responde con un ACK del SYN. Pero luego el cliente regresa y envía otro ACK antes de enviar datos. ¿Cuál es el punto del segundo ACK?

Un apretón de manos de tres vías asegura que se establezca una ruta clara y bidireccional. Si la negociación se detuvo en la segunda etapa del apretón de manos, solo el remitente sabe que el enlace funciona en ambas direcciones, pero el receptor no. La tercera parte del apretón de manos le garantiza al receptor que ambas direcciones del enlace funcionan. En ese punto, el emisor y el receptor saben que se ha establecido una conexión.

En pocas palabras … como TCP proporciona el transporte, el servidor no es el único que dicta cuántos bits se enviarán desde la aplicación a la red para evitar (tanto como sea posible) retrasos, ajustar la ventana de congestión que puede aumentar y aumentará con el tiempo. Si UDP, el cliente no se está considerando. Durante el primer y el segundo ACK, el cliente calcula el RTT (Tiempo de ida y vuelta) y en el tercer ACK lo coloca en el campo Marca de tiempo del encabezado TCP y lo envía de vuelta al servidor. Cuando el servidor recibe TCP del cliente, puede calcular cuántos bytes colocar en un solo paquete, es decir, cómo hacer la fragmentación de datos de la aplicación y pasarla a la red.

Una secuencia de datos consta de un SYN, los datos y un FIN en ese orden. SYN y FIN son necesarios para definir el inicio y el final de los datos. Los ACK son necesarios para confirmar la recepción. Una sesión TCP es una secuencia en una dirección y una en la otra. Eso es todo. Ninguno de los dos extremos de la sesión sabe realmente de 3 maneras. Las 3 formas solo son imaginadas por un observador que ve ambos extremos. El cliente pasa al estado establecido tan pronto como recibe el SYNACK, que es solo el segundo apretón de manos. En realidad, la palabra apretón de manos tergiversa todo el asunto.

Apretón de manos de 3 vías

PC ———— Sync- ——————-> Servidor

(Sincronización: – Estoy comenzando la comunicación contigo)

<—————— –Sync-Ack ———————

(También comienzo a sincronizar contigo)

———— -Ack– ———

——————

(Lo tengo ahora comenzar la comunicación).

(Eso se repite cada vez que ocurre la comunicación).

Las otras respuestas lo cubren bien. Sin embargo, hay un divertido, aunque muy artificial, dilema asociado con esto:

Imagina que estuvieras en guerra hace unos cien años. El enemigo tiene un gran campamento en un valle; tienes dos campamentos más pequeños (A y B), uno a cada lado de ellos. Si atacas desde ambos lados a la medianoche, probablemente ganarás, pero si un lado espera que el otro ataque, probablemente no lo harás.

La única forma de comunicarse es enviando a los corredores a pie, pero pueden quedar atrapados. ¿Cuántos mensajeros necesitas para que ambas partes se aseguren de que el otro ataque?

Veamos el estado de las cosas.

1 mensajero (de A a B):
A no puede estar seguro de que B lo consiguió, por lo que no pueden atacar.
B no puede atacar incluso si lo logra, porque saben que A no lo hará.

2 mensajeros (respuesta de B a A):
B todavía no puede atacar, porque no saben si lo logró.
A todavía no puede atacar incluso si lo logra, ya que saben que B no puede.

3 mensajeros (respuesta de A a B):
A todavía no puede atacar, porque no saben si lo logró
B todavía no puede atacar incluso si lo logra, porque saben que A no puede atacar

Parece contrario a la intuición que necesitaría una cantidad infinita de mensajeros, pero ¿dónde se detiene?