Directorio de artículos
1. Apretón de manos de tres vías
SYN: es un mensaje de solicitud de conexión (apretón de manos de tres vías) y se envía el encabezado TCP
La esencia del apretón de manos de tres vías es establecer un vínculo ¿Qué es un vínculo?
Habrá múltiples enlaces establecidos en el sistema operativo. El sistema operativo necesita gestionar estos enlaces establecidos. La
esencia de la gestión es describir primero
la estructura de datos mantenida en la organización. Para gestionar el mantenimiento de la conexión en el sistema operativo,
el Primero se utiliza la estructura struct tcp_link body, que contiene varios campos vinculados
y luego usa listas vinculadas para organizarlos.
Crear y mantener un enlace tiene un costo
1. Consumo de espacio de memoria (si desea crear un enlace, necesita crear un objeto de enlace, por lo que necesita un objeto de enlace nuevo/nalloc)
2. Consumo de recursos de CPU ( temporizador de mantenimiento para garantizar el tiempo de espera para reiniciar la transmisión, etc.)
proceso general
Mientras el cliente envía SYN, el estado del cliente cambia a SYN_SENT, lo que se llama transmisión síncrona.
Mientras el servidor recibe SYN, el estado del servidor cambia a SYN_RCVD
. Luego, el servidor responde con SYN+ACK. Después de la respuesta,
el El cliente recibe ACK y cuando se envía ACK, se completa el protocolo de enlace de tres vías del cliente.
El protocolo de enlace de tres vías en el lado del servidor no se completa hasta que el lado del servidor recibe el ACK.
Problema de pérdida de mensajes durante el protocolo de enlace de tres vías
Si se pierde el primer mensaje, es decir, se pierde el SYN,
el servidor no se verá afectado de ninguna manera porque nunca ha recibido un mensaje.
Si se pierde el segundo mensaje, es decir, se pierde SYN+ACK,
el proceso de protocolo de enlace de tres vías entre las dos partes no tendrá éxito porque no se ha establecido la conexión entre las dos partes.
Si se pierde el tercer mensaje, es decir, se pierde el ACK.
Para el cliente, solo necesita enviar el ACK y el protocolo de enlace de tres vías se considera completo.
Para el servidor, el protocolo de enlace de tres vías se considera completo únicamente. cuando se recibe el mensaje ACK.
Por lo tanto, cuando se pierde el mensaje ACK, el cliente cree que está completo, pero el servidor cree que no está completo
. En este momento, el cliente cree que está establecido, por lo que enviará un mensaje directamente al servidor
. Si el servidor no se establece, el servidor se vuelve a conectar inmediatamente.Establecido , en respuesta a RST,
el cliente cerrará la conexión y luego la restablecerá.
¿Por qué no se permite el protocolo de enlace bidireccional?
El protocolo de enlace bidireccional no es posible porque es muy fácil ser atacado.
Es muy fácil para una máquina enviarle continuamente una gran cantidad de SYN. Después de que el servidor recibe el SYN, enviará directamente un ACK. independientemente de si el cliente lo ha recibido o no. El servidor ya ha considerado que el establecimiento está completo
. Hay
un costo para mantener la conexión. Si la máquina envía una gran cantidad de SYN
al servidor para mantenimiento inmediato, la memoria será se consume inmediatamente Se consumirá mucha memoria y es posible que el servidor no pueda proporcionar servicios a los usuarios normales.
¿Por qué tres apretones de manos?
1. No hay lagunas obvias en el diseño: una vez que ocurre una excepción al establecer una conexión, el costo se transfiere al cliente, mientras que el costo del lado del servidor es menor.
2. Verificar la fluidez del canal de comunicación entre ambas partes
El protocolo de enlace de tres vías es el costo mínimo para verificar la fluidez del canal de comunicación full-duplex.
Durante el primer apretón de manos, se puede demostrar que el cliente puede enviar mensajes.
Durante el segundo apretón de manos, se puede demostrar que el cliente puede recibir mensajes.
Durante el primer apretón de manos, prueba que el servidor puede recibir el mensaje.
Durante el tercer apretón de manos, prueba que el servidor puede enviar el mensaje
(solo cuando el cliente recibe el mensaje y responde, puede probar que el servidor envió el mensaje).
2. Saluda cuatro veces
Al desconectarse, es posible que el cliente quiera desconectarse, pero
que el servidor no quiera desconectarse.
Para desconectarse es necesario obtener el consentimiento de ambas partes, no solo de una parte, porque el estatus de ambas partes es igual.
Agite cuatro veces para desconectar a ambas partes al mínimo costo.
proceso general
FIN: Es un mensaje de solicitud de desconexión
La primera ola:
después de enviar el mensaje FIN, el estado del cliente es FIN_WAIT 1.
El servidor recibe el mensaje FIN y el estado del servidor es CLOSE_WAIT
La segunda ola:
cuando el cliente recibe el mensaje ACK en respuesta del servidor, el estado del cliente es FIN_WAIT 2
La tercera ola:
si el servidor también quiere desconectarse, envía un mensaje FIN al cliente y luego el servidor ingresa al estado LAST_ACK .
La cuarta ola:
después de recibir el mensaje FIN del servidor, el cliente enviará una respuesta ACK al servidor.
Dado que el cliente se apaga activamente, el cliente ingresa al estado TIME_WAIT y después de que el servidor recibe la respuesta ACK del cliente. , el servidor entra en el estado CERRADO
El cliente ingresa al estado TIME_WAIT y necesita esperar 2MSL antes de ingresar al estado CLOSE .
Después de enviar el último mensaje ACK, el cliente considera que se han completado cuatro oleadas. Cuando
el servidor recibe el mensaje ACK, el servidor considera que se han completado cuatro oleadas.
La parte que se desconecte activamente definitivamente enviará el último mensaje ACK.
¿Por qué esperar a 2MSL?
El protocolo TCP estipula que la parte que cierra activamente la conexión debe ingresar al estado final TIME_WAIT y esperar 2 MSL.
MSL indica el tiempo máximo que existe un mensaje en la red.
TCP estipula que generalmente tiene que esperar 2 MSL.
El máximo El tiempo de supervivencia de un mensaje enviado es 1 MSL, la otra parte debe responder en el futuro y el tiempo de respuesta también es un MSL.
Espere a que 2MSL
se asegure de que todos los segmentos de mensajes no recibidos o tardíos en ambas direcciones de transmisión hayan desaparecido.
Si no espera 2MSL
, es posible que la conexión se haya desconectado y habrá mensajes residuales en la red antes de que se desconectara la conexión. Después de desconectar la conexión, el servidor se volverá a conectar inmediatamente. Cuando se establezca la conexión
, Habrá mensajes residuales históricos. El archivo existe, afectará los datos de recepción normales correspondientes al receptor.
Por lo tanto, trate de asegurarse de que los mensajes históricos se disipen y no afecten la siguiente comunicación normal.
3. control de flujo
Cuando el cliente y el servidor se comunican, tienen sus propios buffers de envío y recepción.
Cuando el cliente envía datos, envía los datos en el buffer de envío del cliente al buffer de recepción del servidor.
Cuando el servidor envía datos, envía los datos en el buffer del servidor. búfer de envío Los datos en el área se envían al búfer de recepción del cliente.
En la respuesta de confirmación, se puede llevar el tamaño de la ventana de 16 bits para indicar el tamaño del espacio restante en el búfer de recepción, es decir, la capacidad de carga. Como receptor, conocer la capacidad de carga
de la recepción de datos puede permitir al remitente enviar datos más lento al enviar datos. , lo que da como resultado la capacidad de recibir
esta operación se llama control de flujo
Si el extremo receptor encuentra que su búfer está casi lleno, establecerá el tamaño de la ventana en un valor más pequeño y notificará al extremo emisor. Si el
extremo emisor recibe esta ventana, reducirá su velocidad de envío.
Si el búfer en el extremo receptor está lleno, la ventana se establecerá en 0. En este momento, el remitente ya no enviará datos, pero necesita enviar un segmento de datos de detección de ventana con regularidad para que el extremo receptor pueda informarle al remitente. el tamaño de la ventana.
4. Ventana corredera
consenso
Para cada segmento de datos enviado, se debe dar una respuesta de confirmación ACK. Después de recibir el ACK, se envía el siguiente segmento de datos.
Sin embargo, la eficiencia de envío y recepción es muy baja.
El acceso concurrente es muy eficiente, pero también tiene un límite superior en las capacidades de recepción
. El remitente debe enviar simultáneamente bajo la premisa de que la otra parte puede aceptarlo.
La cantidad máxima de datos que el remitente puede enviar a la otra parte a la vez está determinada por el tamaño de la ventana de la otra parte.
Caso general de ventanas correderas.
Debido a que la capacidad de recepción del receptor es limitada,
la velocidad de envío del remitente se ve afectada por el espacio restante en el búfer de recepción de la otra parte.
La ventana deslizante es parte del búfer de envío,
esta parte de los datos en la ventana deslizante: no necesita recibir una respuesta por el momento, puede enviarla directamente.
Debido a la existencia de una ventana deslizante, el búfer de envío se divide en tres partes:
el lado izquierdo se llama ya enviado y confirmado
y se puede sobrescribir, es decir, datos no válidos.
El lado derecho se llama ventana deslizante del área de datos no enviados
: se puede enviar directamente, pero no se recibe respuesta.
El tamaño de la ventana deslizante está relacionado con la capacidad de recepción de la otra parte.
Entendiendo las ventanas correderas
Piense en el búfer de envío como una matriz de tipo char.
Debido a que el tipo char solo ocupa un byte y refleja el flujo de bytes,
la matriz se llama sendbuffer.
La esencia de la ventana deslizante es una ventana de intervalo mantenida por dos subíndices de matriz (inicio y final),
deslizarse significa que los subíndices inicial y final se mueven ++
Caso especial de ventanas correderas
Caso 1: ¿La ventana corrediza solo puede deslizarse hacia la derecha? ¿Puedo deslizarme hacia la izquierda?
No puede deslizarse hacia la izquierda porque el área de la izquierda contiene datos que se han enviado y recibido confirmación, lo cual no tiene sentido,
por lo que solo puede deslizarse hacia la derecha.
Caso 2: ¿La ventana corredera puede hacerse más grande o más pequeña? ¿Puede convertirse en 0? ¿Qué significa después de cambiar a 0?
Puede volverse más grande o más pequeño. La ventana deslizante más grande o más pequeña depende de la capacidad de recepción de la otra parte. La ventana deslizante
se hace más grande, es decir, el subíndice final aumenta.
La ventana deslizante se vuelve más pequeña, es decir, el subíndice final aumenta. no se mueve y el subíndice inicial se mueve hacia la derecha.
Entonces el tamaño de la ventana corredera es flotante, no fijo.
La capa de aplicación superior del receptor nunca recupera datos, lo que hará que el espacio restante del búfer de recepción se haga cada vez más pequeño hasta llegar a 0. Esto hará que el remitente envíe cada vez menos
datos hasta llegar a 0. Es decir, la ventana deslizante de 0 significa que la otra parte no puede recibir
el inicio y el final apuntando al mismo
Caso 3: Hay varios mensajes en la ventana deslizante que se pueden enviar directamente, ¿qué pasa si se pierde el primero?
Si hay mensajes 1000 2000 3000 4000
y si se pierde el primer mensaje 1000, hay dos situaciones
Caso 1: Se recibe el mensaje, pero se pierde la respuesta de reconocimiento (ACK),
según el número de secuencia de reconocimiento, cuando se recibe la respuesta de reconocimiento 2001 correspondiente al mensaje 2000, se conoce el mensaje 1000 correspondiente y el receptor debe haberlo recibido. él.
Escenario 2: Se pierden los datos del primer mensaje 1000
En este momento, debido a que se pierde el primer mensaje, es decir, se pierden los datos en el rango 1001-2000, el número de secuencia de confirmación no puede devolver 2001 y 3001, porque 2001 significa que se han recibido todos los números de secuencia antes de 2000, y
1000 no se ha recibido,
por lo que solo se puede devolver el número de secuencia de confirmación 1001, lo que significa que se han recibido los números de secuencia anteriores a 1000, por lo que se
recibirán muchos números de secuencia ACK duplicados y TCP reconocerá que el paquete se ha perdido y lo retransmitirá. después de un tiempo de espera.
Para admitir la retransmisión, los datos deben guardarse temporalmente y guardarse en una ventana deslizante.