Uno, tres apretones de manos

1.1 Proceso de protocolo de enlace de tres vías

El proceso específico del protocolo de enlace de tres vías es el siguiente:

El proceso del servidor está listo para recibir la conexión TCP externa, generalmente llamando a las tres funciones de enlace, escucha y socket . Este método de apertura se considera abierto pasivo (apertura pasiva). Entonces el proceso del servidor está en estado ESCUCHAR, esperando la solicitud de conexión del cliente .
El cliente inicia una apertura activa a través de conexión y envía una solicitud de conexión al servidor. El primer bit de sincronización en la solicitud es SYN = 1 y al mismo tiempo se selecciona un número de secuencia inicial , abreviado como seq = x . El segmento SYN no puede transportar datos y solo consume un número de secuencia. En este punto, el cliente ingresa al estado SYN-SEND.
Una vez que el servidor recibe la conexión del cliente, debe confirmar el segmento de mensaje del cliente. En el segmento de confirmación, establezca los bits SYN y ACK en 1 . El número de confirmación es ack = x + 1 y, al mismo tiempo, elija un número de secuencia inicial seq = y para usted . Este segmento tampoco puede transportar datos, pero también consume un número de secuencia . En este punto, el servidor TCP ingresa al estado SYN-RECEIVED (recibido sincrónicamente).
Después de recibir la respuesta del servidor, el cliente también necesita confirmar la conexión. El ACK en la conexión de confirmación se establece en 1, el número de secuencia es seq = x + 1 y el número de confirmación es ack = y + 1 . TCP estipula que este segmento puede transportar datos o no . Si no transporta datos, el número de secuencia del siguiente segmento de datos sigue siendo seq = x + 1. En este punto, el cliente ingresa al estado ESTABLECIDO (conectado)
Después de recibir la confirmación del cliente, el servidor también ingresa al estado ESTABLECIDO /ɪˈstæblɪʃt/.

Este es un proceso típico de protocolo de enlace de tres vías y el establecimiento de una conexión TCP se puede completar a través de los tres segmentos de mensajes anteriores. El propósito del protocolo de enlace de tres vías no es solo informar a las partes que se comunican que se está estableciendo una conexión, sino también utilizar el campo de opción en el paquete de datos para intercambiar información especial e intercambiar el número de secuencia inicial.

Generalmente, se considera que la primera parte que envía un mensaje SYN abre activamente una conexión, y esta parte también suele denominarse cliente. El receptor de SYN generalmente se llama servidor, que se utiliza para recibir el SYN y enviar el siguiente SYN, por lo que este método de apertura es apertura pasiva.

1.2 ¿Por qué hay un apretón de manos de tres vías, no de dos o cuatro?

Confirme que las capacidades de envío y recepción del cliente y el servidor son normales

Primero debemos comprender el significado del apretón de manos de tres vías. El protocolo de enlace de tres vías en realidad significa que al establecer una conexión TCP, el cliente y el servidor deben enviar un total de 3 paquetes. La función principal del protocolo de enlace de tres vías es confirmar si las capacidades de recepción y envío de ambas partes son normales y especificar su propio número de secuencia de inicialización para prepararse para una transmisión confiable posterior. En esencia, se trata de conectarse al puerto especificado del servidor, establecer una conexión TCP, sincronizar los números de serie y los números de confirmación de ambas partes e intercambiar información sobre el tamaño de la ventana TCP.

El primer apretón de manos: el cliente envía un paquete de red y el servidor lo recibe. De esta forma, el servidor puede concluir que la capacidad de envío del cliente y la capacidad de recepción del servidor son normales.
El segundo apretón de manos: el servidor envía un paquete y el cliente lo recibe. De esta manera, el cliente puede concluir que las capacidades de recepción y envío del servidor y las capacidades de recepción y envío del cliente son normales. Sin embargo, en este momento, el servidor no puede confirmar si la capacidad de recepción del cliente es normal.
El tercer apretón de manos: el cliente envía un paquete y el servidor lo recibe. De esta manera, el servidor puede concluir que las capacidades de envío y recepción del cliente son normales, y que las capacidades de envío y recepción del propio servidor también son normales.

Si solo hay dos apretones de manos, entonces el cliente sabe que la aceptabilidad de ambas partes es normal, pero el servidor no sabe si su envío y la capacidad de aceptación del cliente son normales. Por lo tanto, se requiere un protocolo de enlace de tres vías para confirmar si las capacidades de recepción y envío de ambas partes son normales.

Evitar que la "conexión histórica" inicialice la conexión

Imagine que si usa dos apretones de manos, ocurrirá la siguiente situación:

Si el cliente envía una solicitud de conexión, pero no recibe un acuse de recibo debido a la pérdida del mensaje de solicitud de conexión, el cliente retransmite la solicitud de conexión nuevamente. Posteriormente se recibió una confirmación y se estableció la conexión. Una vez completada la transmisión de datos, se libera la conexión y el cliente envía dos segmentos de solicitud de conexión, el primero se pierde y el segundo llega al servidor, pero el primer segmento perdido está solo en algunos El nodo de red permanece por un Durante mucho tiempo, se retrasa hasta cierto tiempo después de que se libera la conexión para llegar al servidor. En este momento, el servidor cree erróneamente que el cliente envía una nueva solicitud de conexión, por lo que envía un segmento de mensaje de confirmación al cliente, aceptando Para establecer una conexión, no se utiliza un protocolo de enlace de tres vías. Siempre que el servidor envíe una confirmación, se establece una nueva conexión. En este momento, el cliente ignora la confirmación enviada por el servidor y no envía datos. El servidor espera a que el cliente envíe datos, lo que desperdicia el recurso de la red. En el caso de dos apretones de manos, el servidor no tiene un estado intermedio para que el cliente evite conexiones históricas, lo que puede hacer que el servidor establezca una conexión histórica, lo que resulta en un desperdicio de recursos.

Por eso es necesario un tercer apretón de manos. Cuando se encuentra congestión de la red y el primer segmento perdido llega al servidor, debido al tercer protocolo de enlace, el cliente ignorará el segundo segmento enviado por el servidor cuando sabe que el segmento ya se envió de acuerdo con el número de secuencia del paquete. En este momento, la conexión TCP no está establecida, por lo que el servidor no esperará a que el cliente envíe datos después de un período de tiempo, lo que reduce el desperdicio de recursos de la red.

Sincronizar el número de secuencia inicial (ISN) de ambas partes

Ambos lados de la comunicación del protocolo TCP deben mantener un "número de serie". El número de serie es un factor clave para una transmisión confiable. Su función: puede deduplicar, mantener el orden de aceptación y comprender lo que se ha aceptado.

Se puede ver que el número de serie juega un papel muy importante en la conexión TCP, por lo que cuando el cliente envía un mensaje SYN que lleva el "número de serie inicial", el servidor debe devolver un mensaje de respuesta ACK, lo que indica que el mensaje SYN del cliente Se ha completado. Si el servidor lo recibe con éxito, cuando el servidor envía el "número de serie inicial" al cliente, aún necesita obtener una respuesta del cliente, para que los números de serie iniciales de ambas partes puedan ser confiables. sincronizado.

¿ Por qué no un apretón de manos de cuatro vías ?

En teoría, el protocolo de enlace de tres vías ha establecido la conexión menos confiable, por lo que no es necesario utilizar más tiempos de comunicación.

1.3 Inundación SYN (ataque de inundación SYN)

1.3.1 ¿Qué es SYN Flood?

SYN Flood es un método de ataque que explota las vulnerabilidades del protocolo TCP. El atacante utiliza el proceso de protocolo de enlace de tres vías en el protocolo TCP para enviar una gran cantidad de paquetes TCP SYN (paquetes de solicitud de conexión) al host de destino. Después de recibir estas solicitudes, el El host de destino enviará un paquete TCP SYN-ACK (es decir, un paquete de respuesta síncrona) al atacante, lo que indica que se puede establecer una conexión. El atacante no continúa comunicándose después de recibir estos paquetes de respuesta, pero los descarta y no envía paquetes TCP ACK (es decir, paquetes de confirmación), por lo que una gran cantidad de solicitudes de conexión incompletas se acumulan en la cola de conexión del objetivo. host, lo que eventualmente causa que el host de destino normalmente no pueda procesar otras solicitudes de conexión legítimas, lo que resulta en la indisponibilidad del servicio.

1.3.2 Principios básicos de SYN Flood

El atacante envía una gran cantidad de solicitudes de conexión TCP falsificadas, cada una con un indicador SYN, pero en realidad no establece una conexión.
Después de recibir la solicitud SYN, el servidor receptor enviará una respuesta SYN-ACK (respuesta de sincronización) al atacante, indicando que se acepta la solicitud de conexión.
Después de recibir la respuesta SYN-ACK, el atacante no enviará una confirmación ACK (respuesta), sino que descartará la solicitud de conexión sin establecer una conexión real.
El atacante sigue repitiendo los pasos anteriores y envía una gran cantidad de solicitudes SYN falsificadas, lo que hace que el servidor espere la confirmación ACK y consume muchos recursos al mismo tiempo.
Debido al agotamiento de los recursos del servidor, las solicitudes legítimas de conexión de los clientes no pueden responderse, lo que provoca la indisponibilidad del servicio.

1.3.3 Cómo defenderse de los ataques SYN Flood

Para prevenir ataques SYN Flood, se pueden tomar las siguientes medidas:

Límite de conexión: limite la cantidad de servidores que mantienen un estado medio conectado al mismo tiempo. Cuando la cantidad de conexiones alcance el límite superior, se descartarán nuevas solicitudes de conexión. Esto puede evitar que el servidor mantenga una gran cantidad de estados semiconectados en un corto período de tiempo, mitigando así el impacto de los ataques SYN Flood. El límite de conexión se puede establecer a nivel del sistema operativo o en la configuración del firewall.
Utilice la tecnología SYN Cookies: esta tecnología puede utilizar un algoritmo de cifrado especial para generar un valor de cookie durante el proceso de protocolo de enlace TCP y enviarlo al cliente. Cuando el cliente devuelve un paquete ACK con un valor de cookie, el host de destino puede verificar si la conexión es legal según el valor de la cookie.
Filtrado y limitación de velocidad: utilice un firewall o un sistema de prevención de intrusiones (IDS/IPS) para filtrar y limitar el tráfico y evitar que una gran cantidad de solicitudes SYN falsificadas ingresen al servidor. El filtrado y la limitación de velocidad pueden ayudar a reducir el poder de los ataques SYN Flood y controlar el tráfico de ataques dentro de un rango aceptable.
Equilibrio de carga: utilice equipos de equilibrio de carga para distribuir el tráfico a varios servidores, distribuyendo así uniformemente el tráfico de ataque a diferentes servidores y reduciendo la presión sobre un solo servidor.
Protección en la nube: implemente el servidor en la plataforma del proveedor de servicios en la nube, lo que le permitirá manejar ataques SYN Flood a gran escala. Los proveedores de servicios en la nube suelen tener una infraestructura sólida y mecanismos de protección que pueden hacer frente eficazmente a los ataques DDoS.
Limitar conexiones simultáneas: la capa de aplicación puede limitar la cantidad de conexiones simultáneas desde una única dirección IP. Esto evita que una única dirección IP envíe una gran cantidad de solicitudes de conexión en un corto período de tiempo, lo que ralentiza el impacto de un ataque.

Dos o cuatro olas

2.1 El proceso de agitar cuatro veces.

El proceso específico de agitar cuatro veces es el siguiente:

El programa de aplicación cliente envía un segmento de mensaje para liberar la conexión, deja de enviar datos y cierra activamente la conexión TCP. El host del cliente envía un segmento de mensaje para liberar la conexión. La primera posición FIN en el segmento de mensaje es 1 , no contiene datos y el número de secuencia es bit seq = u . En este momento, el host del cliente ingresa al FIN-WAIT- 1 etapa (espera de terminación 1).
Después de que el host del servidor recibe el segmento de mensaje enviado por el cliente, envía un mensaje de respuesta de confirmación. En el mensaje de respuesta de confirmación, ACK = 1, genera su propio número de serie bit seq = v, ack = u + 1, y luego el servidor El host ingresa al estado CLOSE -WAIT (espera de apagado) .
Después de que el host del cliente recibe la respuesta de confirmación del host del servidor, ingresa al estado FIN-WAIT-2 (dejar de esperar 2) . Espere a que el cliente envíe un segmento de liberación de conexión.
En este momento , el host del servidor enviará un segmento de mensaje para la desconexión, en el segmento del mensaje, ACK = 1, número de secuencia seq = v, ack = u + 1. Después de enviar el mensaje de solicitud de desconexión, el host del servidor ingresará al escenario de LAST-ACK (confirmación final).
Después de que el cliente recibe la solicitud de desconexión del servidor, el cliente debe responder. El cliente envía un segmento de mensaje desconectado. En el segmento de mensaje, ACK = 1 y el número de secuencia seq = u + 1, porque el cliente No más datos Se ha enviado desde que se desconectó la conexión, ack = v + 1, y luego ingresa al estado TIME-WAIT (tiempo de espera) . Tenga en cuenta que la conexión TCP no se ha liberado en este momento. El cliente ingresará al estado CERRADO solo después de que se establezca el tiempo de espera, es decir, 2 MSL. El tiempo MSL se denomina vida útil máxima del segmento (vida útil máxima del segmento).
Después de que el servidor reciba principalmente la confirmación de desconexión del cliente, entrará en el estado CERRADO. Debido a que el servidor finaliza la conexión TCP antes que el cliente , y todo el proceso de desconexión de la conexión necesita enviar cuatro segmentos, el proceso de liberación de la conexión también se denomina cuatro ondas.

Cualquier lado de la conexión TCP puede iniciar la operación de cierre, pero normalmente el cliente inicia la operación de cierre de conexión. Sin embargo, algunos servidores, como los servidores web, también iniciarán la operación de cerrar la conexión después de responder a la solicitud. El protocolo TCP estipula que una operación de cierre se inicia enviando un mensaje FIN.

2.2 TIEMPO_ESPERA

Después de que las partes en comunicación establezcan una conexión TCP, la parte que cierra activamente la conexión ingresará al estado TIME_WAIT. El estado TIME_WAIT también se denomina estado de espera 2MSL. En este estado, TCP esperará el doble del tiempo de vida útil máxima del segmento (Vida útil máxima del segmento, MSL).

MSL debe explicarse aquí

MSL es la vida útil máxima esperada de un segmento TCP, es decir, el tiempo más largo que existe en la red. Este tiempo es limitado, porque sabemos que TCP se basa en segmentos de datos IP para la transmisión. Hay un campo TTL en los datagramas IP, que determina la vida útil de los paquetes IP. Generalmente, la vida útil máxima de TCP es de 2 minutos, pero este valor puede modificarse, y este valor se puede modificar según los diferentes sistemas operativos.

En base a esto, analicemos el estado de TIME_WAIT.

Cuando TCP realiza un cierre activo y envía el ACK final, TIME_WAIT debe existir con una vida útil máxima de 2 *, para que TCP pueda reenviar el ACK final para evitar pérdidas. Reenviar el ACK final no se debe a que TCP retransmitió ACK, sino a que la otra parte retransmitió FIN. El cliente a menudo envía FIN porque necesita una respuesta ACK para cerrar la conexión. Si el tiempo de supervivencia excede 2MSL, el cliente enviará RST, lo que provocará el servidor para cometer un error.

Otro factor que afecta el estado de espera de 2MSL es que cuando TCP está en estado de espera, las partes en la comunicación definen la conexión (dirección IP del cliente, número de puerto del cliente, dirección IP del servidor, número de puerto del servidor) como no reutilizable. Solo cuando finaliza la espera 2MSL, o cuando el número de secuencia inicial utilizado por una nueva conexión excede el número de secuencia más alto utilizado por la instancia anterior de la conexión, o cuando se permite la opción de marca de tiempo para distinguir el segmento de la instancia de conexión anterior para evitar confusión, esta conexión sólo se puede utilizar de nuevo. Desafortunadamente, algunas implementaciones imponen restricciones más estrictas. En estos sistemas, si cualquier extremo de comunicación utiliza un número de puerto en el estado de espera 2MSL, entonces el número de puerto no se volverá a utilizar.

2.2.1 El significado de la existencia del estado TIME_WAIT

Garantice una terminación confiable de la conexión: cuando la conexión TCP se cierra, tanto el servidor como el cliente deben enviar el último segmento ACK como confirmación para garantizar el cierre bidireccional de la conexión. El estado TIME_WAIT garantiza que tanto el servidor como el cliente tengan tiempo suficiente para recibir el último segmento ACK que puede estar atascado en la red.
Manejo de segmentos retrasados: cuando se cierra una conexión TCP, pueden aparecer segmentos retrasados en la red y estos segmentos pueden llegar después de que se cierra la conexión. El estado TIME_WAIT permite que estos segmentos retrasados se procesen correctamente después de su llegada, evitando que las conexiones posteriores reciban datos antiguos incorrectamente.

2.2.2 Por qué la hora del estado debe mantener 2 MSL

La duración del estado TIME_WAIT se establece en el doble de MSL (vida útil máxima del segmento), principalmente para garantizar que todos los segmentos relacionados con la conexión en la red puedan desaparecer por completo en la red. Durante el cierre de una conexión TCP, hay dos aspectos a considerar:

Reciba de manera confiable el acuse de recibo final: cuando se cierra la conexión TCP, el segmento ACK (confirmación) final puede experimentar algún retraso en la red, lo que se denomina segmento "huérfano". Si el recurso se libera inmediatamente después de que se cierra la conexión y estos segmentos retrasados todavía están en la red, puede provocar que las conexiones posteriores reciban datos antiguos por error. El estado TIME_WAIT da tiempo suficiente para que estos segmentos retrasados se reciban y procesen, garantizando así un cierre confiable de la conexión.
Eliminar conexiones redundantes: si el cliente intenta restablecer una nueva conexión en el estado TIME_WAIT, pero el segmento de la conexión anterior aún existe en la red, el servidor rechazará la solicitud. Esto elimina conexiones redundantes que podrían provocar daños en los datos.

MSL se refiere al tiempo máximo que un paquete de datos puede vivir en la red en una red IP. Dado que el mensaje puede retrasarse, copiarse, retransmitirse, etc. en la red, establecer el doble de MSL como duración del estado TIME_WAIT puede garantizar que todos los segmentos de mensajes relacionados con la conexión desaparezcan por completo en la red, garantizando así la confiabilidad del TCP. conexión sexo y estabilidad.

Vale la pena señalar que, de hecho, la conexión TCP se puede cerrar inmediatamente después de que finaliza el estado TIME_WAIT, porque los recursos relacionados con la conexión anterior ya no son necesarios en este momento. Sin embargo, configurar el doble de MSL es para garantizar un cierre confiable de la conexión cuando el entorno de red es inestable o la latencia es alta. Si el entorno de red es muy estable y la latencia es baja, la conexión se puede cerrar más rápido.

2.3 CERRAR_ESPERAR

CLOSE_WAIT es un estado durante el proceso de cierre de la conexión TCP, que indica que la aplicación local completó el envío de datos y cerró el puerto de envío, pero aún se pueden recibir datos de la aplicación remota. En este estado, la conexión TCP permanece abierta hasta que la aplicación remota también cierra la conexión.

El estado CLOSE_WAIT generalmente es causado por la aplicación local. Cuando la aplicación local cierra el puerto de envío de la conexión, pero la aplicación remota aún necesita enviar algunos datos o completar algunas operaciones, la conexión TCP entrará en el estado CLOSE_WAIT. En este estado, la aplicación local aún puede recibir datos de la aplicación remota hasta que la aplicación remota también cierre la conexión.

Una vez que la aplicación remota cierra la conexión, la conexión TCP pasará del estado CLOSE_WAIT al estado FIN_WAIT_2, lo que indica que la aplicación remota completó el envío de datos y cerró el puerto de envío, pero aún se pueden recibir datos de la aplicación local. En el estado FIN_WAIT_2, la aplicación local aún puede enviar datos a la aplicación remota hasta que la aplicación local también cierre el puerto de recepción de la conexión.

El estado CLOSE_WAIT generalmente no causa problemas, pero si la conexión TCP dura demasiado en el estado CLOSE_WAIT, puede causar un desperdicio de recursos del sistema. Por lo tanto, en aplicaciones prácticas, debe intentar evitar que la conexión TCP entre en el estado CLOSE_WAIT. Por ejemplo, antes de cerrar la conexión, puede enviar un segmento FIN (solicitud para cerrar la conexión) y esperar a que la aplicación remota envíe un segmento ACK (acuse de recibo) al segmento FIN) y luego cierre el puerto de recepción de la conexión. Esto puede evitar que la conexión TCP entre en el estado CLOSE_WAIT, mejorando el rendimiento del sistema y la utilización de recursos.

2.4 La diferencia entre TIME_WAIT y CLOSE_WAIT

TIME_WAIT y CLOSE_WAIT son dos estados en el proceso de cerrar una conexión TCP. Tienen algunas diferencias:

Estado CLOSE_WAIT:
- El estado CLOSE_WAIT aparece en el servidor, lo que indica que el servidor ha recibido la solicitud de cierre de conexión (segmento FIN) enviada por el cliente, pero el servidor todavía está esperando que la capa de aplicación complete la transmisión de datos. Es decir, el servidor ha cerrado el canal de transmisión de datos al cliente, pero aún puede recibir datos del cliente. En el estado CLOSE_WAIT, después de que el servidor espera a que la aplicación procese los datos restantes, enviará su propia solicitud para cerrar la conexión, ingresará al estado LAST_ACK y finalmente completará el proceso de saludar cuatro veces.
Estado TIME_WAIT:
- El estado TIME_WAIT aparece en el cliente, lo que indica que el cliente envió una solicitud de cierre de conexión (segmento FIN) al servidor y recibió la confirmación del servidor (segmento ACK). En el estado TIME_WAIT, el cliente espera un período de tiempo (generalmente esperando el doble del MSL, es decir, la vida útil más larga del segmento) para garantizar que se descarten todos los segmentos retrasados en la red. Esto evita que conexiones posteriores confundan paquetes antiguos con la misma conexión. Una vez finalizado el tiempo de espera, el cliente ingresa al estado CERRADO y cierra completamente la conexión.

Para resumir las diferencias:

El estado CLOSE_WAIT está en el lado del servidor, lo que significa que el servidor espera a que la capa de aplicación procese los datos y luego cierra la conexión y puede recibir los datos enviados por el cliente.
El estado TIME_WAIT está en el lado del cliente, lo que significa que después de que el cliente espera durante un período de tiempo, se asegura de que todos los segmentos retrasados en la red se descarten y luego cierra completamente la conexión.

Jiwang: protocolo de enlace TCP de tres vías y protocolo de enlace de cuatro vías