Explicación detallada del apretón de manos de tres vías de la red informática-TCP

Directorio de artículos

TCP está orientado a la conexión, es decir, antes de que el remitente y el receptor envíen datos, primero deben establecer una conexión, de modo que la conexión siempre se use para transmitir datos hasta que se desconecte la conexión. El establecimiento de una conexión incluye la configuración de parámetros, la asignación de espacio de memoria y la negociación de parámetros entre las partes emisora y receptora. Este proceso requiere tres comunicaciones exitosas, lo que generalmente se denomina "apretón de manos de tres vías".

En términos sencillos, estas tres comunicaciones son:

Iniciador: "Hola, ¿puedo establecer una conexión con usted?" (enviar solicitud, esperar respuesta)
Destinatario: "Está bien, estoy listo, vamos".
Iniciador: "Está bien, gracias, ahora te envío datos".

Por supuesto, hay muchos detalles involucrados en el proceso de implementación específico, que se describirán uno por uno a continuación.

1. Estructura del segmento TCP

Para comprender qué mensajes se envían durante el protocolo de enlace de tres vías, primero debe saber de qué campos consta el segmento de mensaje TCP y qué campos juegan un papel clave en este proceso.
inserte la descripción de la imagen aquí
Nos enfocamos en los siguientes campos:

Número de secuencia: número de secuencia, utilizado para marcar el número de secuencia de un segmento de mensaje, el número de flujo de bytes del primer byte del segmento de mensaje
Número de reconocimiento: número de reconocimiento, solo cuando el indicador ACK es 1, el campo de número de secuencia de reconocimiento es válido
ACK: se utiliza para indicar que el número de reconocimiento es válido
SYN: sincronizar números de secuencia

2. Apretón de manos de tres vías

A continuación, mire más de cerca cómo se establece una conexión TCP.
Suponga que un proceso que se ejecuta en un host (cliente) quiere establecer una conexión con un proceso en otro host (servidor). El TCP en el cliente establecerá una conexión TCP con el TCP en el servidor de la siguiente manera:
inserte la descripción de la imagen aquí

Paso 1: el TCP del cliente envía un segmento de mensaje TCP especial al TCP del servidor. Este segmento de mensaje no contiene datos de capa de aplicación, y el SYN de su encabezado se establece en 1. Este segmento de mensaje especial se denomina mensaje SYN. párrafo . Y, el cliente selecciona aleatoriamente un número de secuencia inicial ( client_isn , número de secuencia inicial) y coloca ese valor en el campo de número de secuencia. El cliente envía un segmento SYN y entra en el estado SYN_SENT, esperando la confirmación del servidor.
Paso 2: una vez que el servidor recibe el segmento TCP SYN (se puede juzgar por el bit de indicador SYN que es 1), asignará búferes TCP y variables para la conexión, y enviará un segmento permitiendo que la conexión (conexión -segmento concedido) cliente TCP. Este segmento de mensaje tampoco contiene datos de capa de aplicación, y SYN también se establece en 1, y el bit de indicador ACK también es 1, el número de confirmación es client_isn+1 y se selecciona un número de secuencia inicial server_isn como el valor de la secuencia. campo numérico. Este segmento se denomina segmento SYNACK. En este punto, el servidor ingresa al estado SYN_RECV.
Paso 3: Después de que el cliente recibe el segmento SYNACK (que se puede juzgar por el SYN, ACK y el número de confirmación), también asigna búferes y variables para la conexión. Luego, el cliente enviará un mensaje de confirmación al servidor nuevamente, el indicador ACK es 1 y el número de confirmación es server_isn+1 (esta vez, SYN es 0 y SYN solo se establece en 1 en los dos primeros apretones de manos) , esta vez el mensaje Los segmentos pueden transportar datos de la capa de aplicación. En este punto el cliente entra en el estado ESTABLECIDO. Después de que el servidor recibe este segmento de mensaje, también ingresa al estado ESTABLECIDO En este momento, la conexión está completamente establecida y las dos partes pueden enviarse datos entre sí.

3. Ataque de inundación SYN

En la discusión anterior, sabemos que cuando el servidor recibe un segmento SYN, asigna e inicializa variables de conexión y cachés, y luego envía un SYNACK en respuesta. Antes de recibir el segmento ACK del cliente, la conexión no está completamente establecida, lo llamamos conexión semiabierta . Si el cliente no envía ACK para completar el tercer paso del protocolo de enlace de tres vías, el servidor finalizará la conexión semiabierta dentro de un cierto período de tiempo y reclamará los recursos asignados.

Bajo tal protocolo, es fácil ser atacado por un ataque de Denegación de Servicio (DoS) llamado ataque de inundación SYN. El atacante envía una gran cantidad de segmentos de mensajes TCP SYN al servidor sin completar el tercer paso del protocolo de enlace de tres vías, por lo que el servidor asigna continuamente recursos para estas conexiones semiabiertas, lo que hace que se agoten los recursos de conexión del servidor.

Actualmente existe un mecanismo de defensa contra este ataque llamado cookie SYN .

La idea de este mecanismo no es asignar recursos inmediatamente después de recibir SYN (por miedo), sino juzgar si el iniciador de la conexión es un usuario legítimo en el tercer paso y, de ser así, asignar recursos y establecer una conexión. .

En primer lugar, cuando el servidor recibe un SYN, no asigna recursos inmediatamente, sino que genera un número de serie inicial de la siguiente manera: el número de serie es " las direcciones IP de origen y destino y los números de puerto en el segmento de mensaje SYN y un hash valor del número secreto (secret number) que conoce, es decir, sólo si conoce el número secreto, puede calcular el número de serie (este número de serie inicial se llama "cookie" ) . Luego, el servidor envía un SYNACK que contiene este número de secuencia inicial. Cabe señalar que el servidor no mantiene ninguna información de estado sobre el SYN en este momento, y ni siquiera necesita recordar el valor de la cookie. Entonces, si el cliente no devuelve un ACK, entonces no le sucede nada al servidor, y ahora no se puede realizar el ataque de inundación SYN.

Entonces, ¿cómo completa el usuario legítimo el tercer paso? De hecho, nada ha cambiado, y continúa de la forma original, enviando un ACK al servidor. En este momento, es el servidor el que necesita hacer algo.¿Cómo juzga el servidor que este mensaje ACK es una confirmación del SYNACK anterior? Es muy simple, porque el número de secuencia SYNACK anterior se calcula en función de " las direcciones IP y los números de puerto de origen y destino en el segmento de mensaje SYN y un número secreto que solo el servidor conoce ", por lo que si sigue siendo el mismo usuario esta vez Entonces, las direcciones IP de origen y destino y los números de puerto no cambiarán, y luego el servidor también conoce el número secreto.Usando la función hash original, se puede obtener el número de serie y luego agregar 1 para ver si coincide con el ACK. los números de confirmación de los mensajes son iguales, si son iguales significa que el ACK corresponde al SYNACK anterior y es legal, por lo que se crea una conexión.

4. ¿Por qué "tres veces"?

Primero, ¿por qué un apretón de manos de tres vías en lugar de cuatro o más? Este problema es relativamente simple, porque si el problema se puede resolver tres veces, ¿por qué usar cuatro veces para desperdiciar recursos?

Pero, de hecho, el punto de la pregunta es, ¿por qué no se puede usar solo dos veces? ¿No se puede eliminar el tercer apretón de manos?
Para la versión mejorada del "apretón de manos de tres vías" contra los ataques de inundación SYN (ver arriba), el tercer apretón de manos es definitivamente necesario, lo cual es obvio.

¿Qué pasa si no se considera el ataque? ¿Pueden dos apretones de manos hacer el truco?

La edición de Xie Xiren de "Computer Network" discutió este tema. En general, el protocolo de enlace de tres vías es para evitar que el segmento de solicitud de conexión no válida se envíe repentinamente al servidor, lo que genera incoherencias entre las dos partes y genera una pérdida de recursos.

"Segmento de solicitud de conexión inválida" se refiere a la situación en la que el cliente envía un segmento SYN, que se queda en la red debido a la congestión u otras razones, por lo que el cliente piensa que el paquete está perdido (de hecho, no está perdido), así que vuelva a enviar un segmento de mensaje SYN, asumiendo que esta vez se completó con éxito, luego las dos partes establecen una conexión. Esto parece no ser un problema, pero hay un peligro oculto en la red, es decir, el segmento SYN que todavía se está transmitiendo en la red. Si el servidor recibe el SYN durante la conexión, el servidor simplemente lo ignorará. , y todo estará bien. , pero ¿y si se recibe después de que se libera la conexión? En este momento, el servidor cree que alguien le ha enviado una solicitud de conexión, por lo que responde con un SYNACK, si se usan dos handshakes, el servidor cree que la conexión se ha establecido en este momento. Pero cuando el cliente recibe este SYNACK, si no inicia una conexión, ignorará el SYNACK, como si nada hubiera pasado (si el cliente inicia una conexión en este momento, ignorará el SYNACK, porque el el número de confirmación es incorrecto). Ese es un gran problema En este momento, el servidor piensa que la conexión es buena y envía datos al cliente, pero el cliente está en estado CERRADO y descartará estos paquetes, lo cual es un gran desperdicio. Y hay otro problema vergonzoso, es que cuando el cliente intenta iniciar una conexión en este momento, el servidor lo ignora nuevamente, esto es vergonzoso aquí, y ni siquiera quieren enviarse datos entre ellos. Por supuesto, estos problemas no parecen irresolubles, cuando el cliente descubre que el servidor siempre se envía datos a sí mismo, pero siempre los descarta, puede enviar un RST al servidor (el número de etiqueta RST del segmento de mensaje es 1 ), al forzar el fin del servicio se cierra la conexión. Pero los recursos siempre se desperdician por un tiempo. Con el apretón de manos de tres vías, no habrá tales problemas.

Lectura relacionada:
Red informática: explicación detallada del proceso de ondulación de cuatro vías TCP
Apretón de manos de tres vías y onda de conexión TCP de cuatro vías: analogía de las parejas de amor a larga distancia que comienzan a interactuar y se separan (fácil de entender)