En el apretón de manos de tcp y mi ola de manos

En la TCP/IPpila de protocolos de la red informática, hay dos protocolos más comunes ubicados en la capa de transporte, TCPy UDP. Hablando de eso TCP, los dos puntos de conocimiento para comenzar también son puntos de prueba, e incluso los detalles, que se convertirán en puntos dudosos, son el apretón de manos de tres vías y la onda de cuatro veces .

Una imagen de la apertura, la máquina de estado tcp, de esta máquina de estado, podemos ver los dos temas que discutiremos esta vez.

Tres apretón de manos

El contenido general del apretón de manos de tres vías incluso se puede dibujar como una caricatura como se muestra a continuación.

El ridículo pertenece al ridículo, pero la verdad sigue siendo la misma. Sabemos que el propósito de TCP es proporcionar servicios de flujo de bytes confiables. Para entregar datos con precisión al destino, el protocolo TCP adopta una estrategia de enlace de tres vías para establecer un canal de transmisión. El proceso es el siguiente:

1. Inicialmente, los procesos de TCP en ambos extremos están en CLOSE(关闭)estado.
2. El remitente A envía activamente un SYN( synchronize)paquete de datos con una bandera al receptor B. En este momento, A irá activamente (active open)al connectservidor y lo enviará SYN. Suponiendo que el número de serie es J, el receptor es pasivo (passive open). Lo que hay que tener en cuenta es que los números de serie enviados por el cliente y el servidor son aleatorios.
3. Receptor B después de recibir el SYN, si acepta establecer una conexión, enviará otro SYN de retorno y un ACK (reconocimiento) al extremo de transmisión A, el número de secuencia ACK se J+1representa como Jrespuesta SYN, SYN nuevo Knúmero de secuencia de transmisión Sí K, el paquete de datos entrega el mensaje de confirmación, lo que significa que lo he recibido. Este número de serie también es aleatorio
4. El remitente A devuelve un ACKpaquete de datos con una bandera, lo que significa que lo sé y el apretón de manos ha terminado. Después de recibir el nuevo SYN Ky ACK J+1, el remitente también responde con ACK K+1para indicar que ha sido recibido y el canal de conexión está establecido.
5. Entonces ambos lados pueden comenzar a enviar datos

Naturaleza

Primero echemos un vistazo al formato del encabezado del mensaje TCP

El mensaje TCP aquí en realidad involucra mucho contenido, pero esta vez solo nos enfocamos en el bit de control, porque el bit de control está relacionado con nuestro protocolo de enlace de tres vías y cuatro ondas.

• URG: Cuando URG = 1, indica que el campo de puntero urgente es válido y le dice al sistema que hay datos urgentes en este segmento y se transmite primero.
• ACK: cuando ACK = 1, el campo del número de confirmación es válido, y cuando ACK = 0, el campo del número de confirmación no es válido
• PSH: Después de recibir el segmento TCP con PSH = 1, se entregará al proceso de solicitud lo antes posible, en lugar de esperar a que se llene todo el búfer antes de entregarlo hacia arriba.
• RST: Cuando RSH = 1, indica que hay un error en la conexión TCP, la conexión debe ser liberada y luego reestablecida.
• SYN: SYN = 1 significa que se trata de una solicitud de conexión o un mensaje de aceptación de conexión.
• FIN: FIN = 1 significa que los datos del remitente de este segmento de mensaje se han enviado y es necesario liberar la conexión de transporte.

Cabe señalar que cuando los datos se transmiten después del protocolo de enlace de tres vías, si el cliente envía el primer paquete después del protocolo de enlace, la secuencia y la confirmación del primer paquete son las mismas que las del tercer protocolo de enlace, entonces la secuencia de y ack se obtiene de acuerdo con seq, ack y len (longitud de datos) del último paquete recibido, específicamente: seq = ack, ack = seq + len

El papel de los números de serie

La función del número de secuencia es permitir que un receptor TCP descarte segmentos repetidos y registre segmentos que lleguen en desorden. Porque TCP usa IP para transmitir segmentos de mensajes, e IP no proporciona la función de eliminación de duplicados ni garantiza el orden correcto. Por otro lado, TCP es un protocolo de flujo de bytes y nunca enviará datos al programa superior en un orden desordenado. Por lo tanto, el receptor TCP se verá obligado a conservar los datos con el número de secuencia grande y no entregarlos al programa de aplicación hasta que se complete el segmento de número de secuencia pequeño que falta.

Estamos en RFC793 , que es el protocolo RFC de TCP, y encontrará que habla sobre por qué es necesario el protocolo de enlace de tres vías: TCP necesita el número de secuencia de secuencia para una retransmisión o recepción confiable, y evita la incapacidad de distinguir la secuencia durante reutilización de la conexión Es la secuencia del enlace retrasado o antiguo, por lo que se requiere un protocolo de enlace de tres vías para acordar la determinación del ISN (número de secuencia de secuencia inicial) de ambas partes

Una noción fundamental en el diseño es que cada octeto de datos enviados a través de una conexión TCP tiene un número de secuencia. Dado que cada octeto está secuenciado, se puede acusar recibo de cada uno de ellos. El mecanismo de acuse de recibo empleado es acumulativo, de modo que un acuse de recibo del número de secuencia X indica que se han recibido todos los octetos hasta X, pero sin incluirlo.

Una configuración básica en el diseño de TCP es que cada paquete enviado a través de una conexión TCP tiene uno sequence numbery, dado que cada paquete tiene un número de secuencia, se puede confirmar que recibe estos paquetes. El mecanismo de confirmación es acumulativo, por lo que una sequence numberconfirmación de X significa que se confirma la recepción de todos los paquetes antes del número de secuencia X (excluyendo X).

El protocolo no impone ninguna restricción al uso de una conexión en particular una y otra vez. El problema que surge de esto es: "¿cómo identifica el TCP los segmentos duplicados de encarnaciones anteriores de la conexión?" Este problema se hace evidente si la conexión se abre y se cierra en rápida sucesión, o si la conexión se rompe con pérdida de memoria y luego se restablece.

El protocolo TCP no restringe una conexión específica (los sockets en ambos extremos son iguales) para ser reutilizados. Entonces, hay una pregunta: ¿cómo reconoce TCP los paquetes retransmitidos del enlace anterior después de que la conexión se desconecta y se vuelve a conectar repentinamente? ——Esto requiere un mecanismo único ISN (Número de serie inicial).

Cuando se crean nuevas conexiones, se emplea un generador de número de secuencia inicial (ISN) que selecciona un nuevo ISN de 32 bits. El generador está vinculado a un reloj de 32 bits (posiblemente ficticio) cuyo bit de orden inferior se incrementa aproximadamente cada 4 microsegundos. Por lo tanto, el ISN realiza ciclos aproximadamente cada 4,55 horas. Dado que asumimos que los segmentos permanecerán en la red no más que el ciclo de vida máximo del segmento (MSL) y que el MSL es menos de 4.55 horas, podemos asumir razonablemente que los ISN serán únicos.

Cuando se establece una nueva conexión, el generador de número de secuencia inicial (número de secuencia inicial ISN) generará un nuevo ISN de 32 bits.

El ISN se calcula de la siguiente manera:

ISN = M + F(localhost, localport, remotehost, remoteport)

Donde M es un temporizador, que se incrementa en 1 cada 4 µs. F es un algoritmo hash que genera un valor aleatorio basado en la IP de origen, la IP de destino, el puerto de origen y el puerto de destino .

Este generador utilizará un reloj de 32 bits que 4µscrece casi una vez, por lo que ISNhará un ciclo cada 4,55 horas.

Y un segmento en la red no es más largo que la vida máxima del segmento MSL Maximum Segment Lifetime, el uso predeterminado es 2 minutos más y el MSL es menor a 4.55 horas, por lo que podemos pensar que el ISN será único.

El papel del apretón de manos de tres vías

Una conexión TCP consta de una tupla de 4, que son dos direcciones IP y dos números de puerto. Una conexión TCP generalmente se divide en tres etapas: inicio, transmisión de datos y salida (cierre). El cliente y el servidor deben estar conectados antes de comunicarse La función del "protocolo de enlace de 3 vías" es que ambas partes pueden saber que las capacidades de recepción y envío de ellos mismos y de la otra parte son normales.

Una de las funciones importantes del protocolo de enlace de tres vías es que el cliente y el servidor intercambian ISN (Número de secuencia inicial) para que la otra parte sepa cómo ensamblar los datos de acuerdo con el número de secuencia cuando reciba los datos a continuación.

¿Tienes que estrechar la mano tres veces?

Durante el protocolo de enlace de tres vías, el efecto real es que el servidor sepa que el cliente sabe que el servidor lo sabe. Este es de hecho el significado de una matrioska, y puede haber dudas ¿Es suficiente con que el servidor sepa que el cliente lo sabe? ¿O no es necesario que el cliente sepa que el servidor sabe que el cliente sabe que el servidor lo sabe? ¿Por qué es innecesario? El autor puede conocer sus puntos de vista en el libro del maestro Xie Xiren, su punto de vista es evitar que el mensaje de solicitud de conexión no válida se transmita repentinamente al extremo opuesto, lo que provoca errores.

El profesor Xie explicó además que el llamado "segmento de solicitud de conexión fallida" se generó de esta manera.

• Considere una situación normal, A envía una solicitud de conexión, pero no ha recibido la confirmación debido a la pérdida del mensaje de solicitud de conexión. Entonces A retransmite la solicitud de conexión nuevamente. Posteriormente, se recibió la confirmación y se estableció la conexión. Una vez completada la transferencia de datos, se libera la conexión. A ha enviado un total de dos segmentos de solicitud de conexión, el primero de los cuales se pierde y el segundo llega a B, no hay "segmento de solicitud de conexión fallida".
• Ahora suponga que hay una situación anormal, es decir, el primer segmento de mensaje de solicitud de conexión enviado por A no se pierde, sino que permanece en algunos nodos de la red durante mucho tiempo, por lo que se retrasará hasta cierto tiempo después de que se libere la conexión. . Originalmente, este es un segmento que ha expirado hace mucho tiempo. Pero después de que B recibe este segmento de solicitud de conexión no válida, lo confunde con A para enviar una nueva solicitud de conexión. Entonces envía un segmento de acuse de recibo a A, acordando establecer una conexión. Suponiendo que no se utilice ningún protocolo de enlace de mensajes, siempre que B envíe un acuse de recibo, se establecerá una nueva conexión.
• Dado que A no ha enviado una solicitud para establecer una conexión, ignora la confirmación de B y no envía datos a B. Pero B piensa que se ha establecido una nueva conexión de transporte y ha estado esperando que A envíe datos. Muchos de los recursos de B se desperdiciaron de esta manera.

Lo anterior es el entendimiento de la escuela académica. Se analiza principalmente desde el aspecto del manejo de excepciones. Si es un apretón de manos bidireccional, si se produce la reconexión por congestión, se producirá la excepción del servicio de pares, y una Es necesario diseñar un mecanismo de manejo de excepciones.

Más tarde, vi una publicación en TopLanguage of Google Groups que hablaba del "apretón de manos de tres vías" de TCP y lo encontré bastante interesante. El cartel planteaba la pregunta "¿Por qué se establece la conexión TCP mediante un apretón de manos de tres vías?" Entre las muchas respuestas, una de ellas escribió: "La esencia de este problema es que el canal no es confiable, pero la comunicación dual debe alcanzar un acuerdo sobre un tema determinado. Para resolver este problema, independientemente de la información que incluya en el mensaje, la comunicación de tres veces es el mínimo teórico. Por lo tanto, el protocolo de enlace de tres vías no es un requisito de TCP en sí, sino para cumplir con el requisito de "transmisión confiable de información en canales no confiables". Causada por demanda. Preste atención a los requisitos esenciales aquí. El canal no es confiable y la transmisión de datos debe ser confiable. Después de tres veces, desea dar la mano o enviar datos, no importa con la demanda de transmisión de información confiable. Por lo tanto, si el canal es confiable, es decir, cada vez que se envía un mensaje, la otra parte puede recibirlo, o si a usted no le importa si la otra parte recibe su mensaje, entonces puedes enviar el mensaje directamente como UDP ".

De hecho, esto puede considerarse como otro ángulo de palanca a los efectos del "apretón de manos de tres vías". El pensamiento de ingeniería de pantalla completa, después de todo, esto es un compromiso para la transmisión del canal no confiable y completa la transmisión de información confiable. Después de todo, el protocolo de enlace de tres vías completa dos funciones importantes. Ambas partes deben prepararse para enviar datos (ambas partes saben que el otro está listo) y permitir que ambas partes negocien el número de serie inicial, que se utiliza en el proceso de enlace. Enviar y confirmar.

Por ejemplo, si ahora cambiamos el apretón de manos de tres vías a solo dos apretones de manos, puede producirse un interbloqueo. Suponga que la comunicación entre las computadoras S y C, en este momento C envía un paquete de solicitud de conexión a S, S recibe este paquete y envía un paquete de respuesta de acuse de recibo. Según el acuerdo de apretón de manos de dos, S cree que la conexión se ha establecido con éxito y puede comenzar a enviar paquetes de datos. Sin embargo, cuando el paquete de respuesta de S se pierde durante la transmisión, C no sabrá si S está listo, o qué número de secuencia S ha establecido, y C incluso duda si S ha recibido su propio paquete de solicitud de conexión. En este caso, C piensa que la conexión no se ha establecido correctamente e ignorará cualquier paquete de datos enviado por S y solo esperará el paquete de respuesta de confirmación de conexión. Y S envía el mismo paquete repetidamente después de que se agota el tiempo de espera del paquete enviado. Esto crea un punto muerto. Ilustración cómica como se muestra

En la descripción anterior, sabemos que tanto el emisor como el receptor tendrán su propio ISN (X e Y en el siguiente ejemplo) para comunicarse entre sí. La descripción específica es la siguiente:

1. A --> B  SYN my sequence number is X 
2. A <-- B  ACK your sequence number is X 
3. A <-- B  SYN my sequence number is Y 
4. A --> B  ACK your sequence number is Y

Tanto el 2 como el 3 son enviados por B a A, por lo que se pueden combinar para formar un protocolo de enlace de tres vías (o de tres mensajes). En este punto, se puede concluir que el protocolo de enlace de tres vías es necesario:

Es necesario un protocolo de enlace de tres vías porque los números de secuencia no están vinculados a un reloj global en la red, y los TCP pueden tener diferentes mecanismos para elegir los ISN. El receptor del primer SYN no tiene forma de saber si el segmento era antiguo retrasado o no, a menos que recuerde el último número de secuencia utilizado en la conexión (que no siempre es posible), por lo que debe pedirle al remitente que verifique este SYN. El protocolo de enlace de tres vías y las ventajas de un esquema controlado por reloj se analizan en [3].

Debido a que los números de secuencia (números de secuencia) no están vinculados al reloj global de toda la red (todos usan un solo reloj, puede determinar si el paquete está retrasado) y los TCP pueden tener diferentes mecanismos para seleccionar ISN (número de secuencia inicial).

Cuando el receptor recibe el primer SYN, no hay forma de saber si el SYN está retrasado durante mucho tiempo, a menos que tenga una forma de recordar los últimos números de secuencia recibidos en esta conexión (sin embargo, esto no siempre es factible).

El significado de esta oración es: ha llegado una seq, y es diferente de la seq recordada ahora ¿Cómo sé si está retrasada o retrasada? Por lo tanto, el receptor debe confirmar el SYN con el remitente.

Suponiendo que la SEQ en SYN no está confirmada, solo hay:

1) A --> B  SYN my sequence number is X 
2) A <-- B  ACK your sequence number is X  SYN my sequence number is Y

Solo B confirmó la recepción de la SEQ de A, y A no pudo confirmar la recepción de la de B. En otras palabras, solo los paquetes enviados por A a B son confiables, pero los paquetes enviados por B a A no lo son, por lo que esta no es una conexión confiable. En este caso, si solo se requiere que A envíe a B, y B no necesita responder, entonces se puede omitir el protocolo de enlace de tres vías.

Mano de onda de cuatro vías

Después de hablar sobre el apretón de manos de los tres, ¿es igual para las otras cuatro ondas? ¿Para comprometerse, para eliminar la situación anormal? Razonemos deductivamente paso a paso.

1. Wave por primera vez: el cliente envía un FIN para cerrar la transferencia de datos del cliente al servidor, y el cliente entra en el estado FIN_WAIT_1.
2. La segunda ola: después de recibir el FIN, el servidor envía un ACK al cliente, confirmando que el número de serie es el número de serie recibido +1 (igual que SYN, un FIN ocupa un número de serie), y el servidor entra en el estado CLOSE_WAIT . En este momento, TCP se encuentra en un estado medio cerrado y el servidor puede enviar datos al cliente, pero el servidor no puede enviar datos.
3. La tercera ola: el servidor envía un FIN para cerrar la transferencia de datos del servidor al cliente, y el servidor entra en el estado LAST_ACK.
4. Cuarta ola: después de que el cliente recibe el FIN, el cliente ingresa al estado TIME_WAIT, espera 2 MSL (tiempo máximo de supervivencia del mensaje) y luego libera la conexión, y luego envía un ACK al servidor, confirmando que el número de serie es el recibido. número de serie +1, y el servidor ingresa después de confirmar el estado CERRADO, libere la conexión, complete cuatro ondas.

Dicho popular:

1. Cliente: he terminado de hablar de todo
2. Servidor: las he escuchado todas, pero espérame, no he terminado
3. Servidor: Está bien, ya terminé
4. Cliente: Bien, entonces nuestra comunicación ha terminado :)

significado

Cuando la parte pasiva recibe la notificación del mensaje FIN de la parte activa, solo significa que la parte activa no tiene datos para enviar a la parte pasiva. Pero no necesariamente todos los datos de la parte pasiva se han enviado por completo a la parte activa, por lo que la parte pasiva no cerrará inmediatamente SOCKET, es posible que deba enviar algunos datos a la parte activa y luego enviar un mensaje FIN a la parte activa. parte, indicando a la parte activa que esté de acuerdo. La conexión está cerrada, por lo que el mensaje ACK y el mensaje FIN aquí se envían por separado en la mayoría de los casos.

la razón

Observe que hay dos estados Close-waity durante el movimiento de Time-waitmanos, esta es en realidad la razón de la necesidad de diseñar un apretón de manos de cuatro vías.

CERRAR-ESPERAR

Después de que el cliente envía el FINmensaje de liberación de la conexión, el servidor recibe el mensaje y entra en el CLOSE-WAITestado. Este estado es para que el servidor envíe los datos que aún no se han transmitido. Una vez completada la transmisión, el servidor enviará un FINmensaje de liberación de conexión.

TIEMPO DE ESPERA

El cliente FINingresa a este estado después de recibir el mensaje del servidor, en este momento no ingresa directamente al CLOSEDestado y debe esperar el tiempo establecido por un temporizador 2MSL.

¿Por qué A tiene que esperar 2MSL en el estado TIME-WAIT?

Hay dos razones para esto:

• Para garantizar que el último segmento ACK enviado por A pueda llegar a B. Es posible que se pierda el segmento del mensaje ACK enviado por A. Si B no recibe el mensaje de confirmación enviado por A, entonces A reenviará el mensaje de solicitud de liberación de la conexión. A espera un período de tiempo para tratar esta situación.
• Evite que el "segmento de solicitud de conexión fallida" aparezca en este enlace. Después de que A haya enviado el último segmento ACK, y haya transcurrido el tiempo 2MSL, todos los segmentos generados dentro del tiempo de esta conexión pueden desaparecer de la red. De esta forma, el segmento de solicitud de conexión anterior no aparecerá en la próxima conexión nueva.

¿Tienes que estrechar la mano cuatro veces?

Esto se debe a que cuando el SOCKET en el estado LISTEN del servidor recibe la solicitud de conexión del mensaje SYN, puede enviar ACK y SYN (ACK es la respuesta y SYN es la sincronización) en un mensaje. Sin embargo, cuando la conexión se cierra activamente, cuando se recibe la notificación del mensaje FIN de la otra parte, solo significa que la otra parte no tiene datos para enviarle; pero no todos sus datos se han enviado a la otra parte, por lo que puede no necesariamente cerrar SOCKET inmediatamente. Es decir, es posible que deba enviar algunos datos a la otra parte y luego enviar un mensaje FIN a la otra parte para indicar que está de acuerdo en que puede cerrar la conexión ahora, por lo que el mensaje ACK y el mensaje FIN aquí se envían principalmente por separado

Experiencia

Ver horizontalmente como crestas y picos, mirar este asunto desde diferentes ángulos y perspectivas se ha beneficiado mucho.

Referencia

1. "Computer Network" (séptima edición) Xie Xiren
2. https://zhuanlan.zhihu.com/p/58603455
3. https://www.ietf.org/rfc/rfc793.txt
4. https://www.zhihu.com/question/24853633/answer/573627478