Los estudiantes que necesitan servidores en la nube y otros productos en la nube para aprender Linux pueden pasar a / --> Tencent Cloud <-- / --> Alibaba Cloud <-- / --> Huawei Cloud <-- / sitio web oficial, los servidores en la nube livianos son de bajo costo a 112 yuanes al año, y los nuevos usuarios pueden disfrutar de descuentos ultrabajos en su primer pedido.
Tabla de contenido
1. División del número de puerto
1. pidof (usado para ver la identificación del proceso)
2. netstat (verificar el estado de la red)
2. Cómo encapsular, descomprimir y dividir el protocolo UDP
2.1 Encapsulación y desembalaje
3. Características del protocolo UDP
3.1 Características del protocolo UDP
3.3 Protocolo UDP Longitud UDP de 16 bits
4. Protocolo TCP (Protocolo de control de transmisión)
2. Fiabilidad del protocolo TCP
2.1 Reflejo de falta de confiabilidad
2.2 Cómo garantizar la confiabilidad
3. Encabezado del protocolo TCP
3.1 Encapsulación y desembalaje (longitud del encabezado de 4 dígitos)
3,2 puntos (número de puerto de origen de 16 bits, número de puerto de destino)
3.5 Seis bits de bandera del protocolo TCP (diferenciación de tipos de mensajes)
4. Mecanismo de respuesta de confirmación (ACK)
5. Mecanismo de retransmisión por tiempo de espera
6. Mecanismo de gestión de conexión.
6.1 Apretón de manos de tres vías (el establecimiento de la conexión lo inicia el cliente)
6.2 Saludar cuatro veces (la desconexión es cuestión de ambas partes)
8. Ventana corrediza/mecanismo de retransmisión rápida
8.1 La naturaleza de las ventanas correderas.
8.2 El papel de las ventanas correderas
8.3 Algunas preguntas y respuestas sobre ventanas correderas
12. Comprender la orientación del flujo de bytes de TCP y la orientación de datagramas de UDP
13. Problema con la bolsa pegajosa
14. El problema del establecimiento anormal de una conexión TCP.
5. Resumen del protocolo UDP/TCP
1. Fiabilidad y rendimiento de TCP
2. Escenarios aplicables de los protocolos UDP y TCP
3. Respecto al segundo parámetro de escucha.
1. División del número de puerto
El número de puerto es un entero sin signo de 16 bits con un rango de valores de 0 a 65535.
0 - 1023: números de puerto conocidos, HTTP, FTP, SSH y otros protocolos de capa de aplicación ampliamente utilizados, sus números de puerto son fijos.
Los siguientes son algunos números de puerto convencionales:
servidor ssh, usando el puerto 22
servidor ftp, usando el puerto 21
servidor telnet, usando el puerto 23
servidor http, usando el puerto 80
servidor https, use 443
1024 - 65535: Número de puerto asignado dinámicamente por el sistema operativo. El número de puerto del programa cliente lo asigna el sistema operativo dentro de este rango.
2. Algunas instrucciones
1. pidof (usado para ver la identificación del proceso)
pidof httpServer | xargs kill -9//xargs用于将标准输入转换为命令行参数2. netstat (verificar el estado de la red)
n 拒绝显示别名，能显示数字的全部转化成数字
l 仅列出有在 Listen (监听) 的服务状态
p 显示建立相关链接的程序名
t (tcp)仅显示tcp相关选项
u (udp)仅显示udp相关选项
a (all)显示所有选项，默认不显示LISTEN相关3. protocolo UDP
1. Formato de protocolo UDP
Si la suma de verificación es incorrecta, el paquete será descartado.
El encabezado UDP es esencialmente un objeto de estructura o una estructura que contiene campos de bits.
struct udphdr {
uint16_t uh_sport; /* 源端口号 */
uint16_t uh_dport; /* 目的端口号 */
uint16_t uh_ulen; /* UDP数据报长度（包括头部+数据） */
uint16_t uh_sum; /* 数据校验和 */
};2. Cómo encapsular, descomprimir y dividir el protocolo UDP
2.1 Encapsulación y desembalaje
Cuando personalizamos el protocolo anteriormente, usamos caracteres especiales para distinguir encabezados y cargas útiles.
El protocolo UDP sigue directamente el método de longitud de encabezado fija y considera los primeros 8 bytes como encabezado.
2,2 minutos de uso
El encabezado UDP contiene un número de puerto de destino de 16 bits. Hay un proceso vinculado a este número de puerto en la capa de aplicación de la otra parte. El proceso vinculado a este número de puerto en la capa superior puede leerlo en forma de descriptor de archivo y entréguelo a Se procesan protocolos específicos de la capa de aplicación.
3. Características del protocolo UDP
3.1 Características del protocolo UDP
El proceso de transmisión UDP es similar a enviar una carta, simplemente envía la carta y listo, no importa si la otra parte la recibe o no.
Sin conexión: Transmite directamente sin conocer la IP y el número de puerto del extremo opuesto, sin establecer una conexión;
No confiable: no existe un mecanismo de confirmación ni un mecanismo de retransmisión; si el segmento no se puede enviar a la otra parte debido a una falla de la red, lo que resulta en la pérdida de paquetes, el protocolo UDP no devolverá ningún mensaje de error a la capa de aplicación;
Orientado a datagramas: no es posible controlar de manera flexible el número y la cantidad de datos de lectura y escritura, Sendto es tantas veces como recvfrom es tantas veces como sea posible. La capa de aplicación entrega la longitud del mensaje a UDP, que lo envía como está, sin dividirlo ni fusionarlo, usando UDP para transmitir 100 bytes de datos: si el remitente llama a sendto una vez y envía 100 bytes, entonces El extremo receptor debe También llame al recvfrom correspondiente una vez para recibir 100 bytes; no puede llamar a recvfrom 10 veces en un bucle y recibir 10 bytes cada vez.
Una lectura UDP exitosa leerá un mensaje. No necesitamos considerar el problema del encabezado, solo necesitamos realizar la serialización y deserialización de la carga útil.
3.2 Búfer de protocolo UDP
No considere el problema de que varios paquetes UDP se peguen, porque UDP no tiene un búfer de envío real. La llamada a sendto se entregará directamente al kernel (la capa de aplicación envía uno, la capa de transporte envía uno), y el el kernel pasa los datos a la capa de red y el protocolo realiza acciones de transmisión posteriores;
UDP tiene un búfer de recepción. Sin embargo, este búfer de recepción no puede garantizar que el orden de los paquetes UDP recibidos sea consistente con el orden de los paquetes UDP enviados; si el búfer está lleno, los datos UDP entrantes se descartarán; por lo tanto, el protocolo UDP es un protocolo full-duplex.
3.3 Protocolo UDP Longitud UDP de 16 bits
Hay un campo de longitud UDP de 16 bits en el encabezado del protocolo UDP, lo que significa que la longitud máxima transmisible de un mensaje UDP es 2^16 o 64 KB (incluidos los 8 bytes del encabezado UDP). Si necesita transmitir datos más grandes de 64 KB, debe aplicar Las capas se subcontratan varias veces y se ensamblan manualmente en el extremo receptor.
4. Protocolo TCP (Protocolo de control de transmisión)
1. Formato del protocolo TCP
El encabezado es un objeto de estructura:
struct tcphdr
{
uint16_t th_sport; /* 源端口号 */
uint16_t th_dport; /* 目的端口号 */
uint32_t th_seq; /* 序列号 */
uint32_t th_ack; /* 确认号 */
uint8_t th_off; /* 偏移量，指明TCP报文头的长度，单位是4个字节 */
uint8_t th_flags; /* 控制标志，如SYN、ACK、FIN等 */
uint16_t th_win; /* 接收窗口大小 */
uint16_t th_sum; /* 校验和 */
uint16_t th_urp; /* 紧急指针 */
};2. Fiabilidad del protocolo TCP
2.1 Reflejo de falta de confiabilidad
La distancia de transmisión de la red es muy larga y pasará a través de múltiples nodos de dispositivos en el camino, por lo que puede haber problemas como pérdida de paquetes, desorden, errores de verificación y duplicación de mensajes en el camino.
2.2 Cómo garantizar la confiabilidad
Solo cuando un mensaje recibe una respuesta de la otra parte se puede garantizar la confiabilidad del mensaje. Cuando las dos partes se comunican, debe haber los datos más recientes, por ejemplo, el mensaje "Son las 12 en punto" en la figura aún no ha recibido una respuesta de la otra parte, por lo que no es confiable si este mensaje se ha recibido. .
La respuesta del mensaje se puede enviar sola o se puede combinar con los datos que se enviarán y se enviarán en un solo mensaje. Por ejemplo, en la imagen de arriba, el servidor siguiente responde "Recibí el mensaje de que ahora son las 12 o "En punto, así que vayamos a las 13 en punto." ¡Juguemos!" Esto es para meter la respuesta y los datos que se transmitirán en un solo mensaje.
Ya sea que el cliente envíe un mensaje al servidor o el servidor envíe un mensaje al cliente, se debe responder a cada mensaje. Por supuesto, no es necesario responder a mensajes de respuesta puros.
3. Encabezado del protocolo TCP
3.1 Encapsulación y desembalaje (longitud del encabezado de 4 dígitos)
Los primeros 20 bytes del protocolo TCP se pueden convertir en datos estructurados y se puede extraer la longitud del encabezado de 4 bits en el encabezado estándar. La longitud total del mensaje TCP = longitud del encabezado de 4 bits * 4 bytes = [20 bytes (mínimo 20 bytes), 60 bytes]. El tamaño total del paquete TCP que se puede calcular en función de los campos del encabezado (el tamaño de paquete estándar es el tamaño del encabezado restante. Después de eliminar toda la información del mensaje, el resto es la carga útil).
3,2 puntos (número de puerto de origen de 16 bits, número de puerto de destino)
El encabezado TCP contiene un número de puerto de destino de 16 bits. Al vincular el número de puerto cuando se inicia el servidor, puede encontrar el proceso de la capa de aplicación correspondiente al mensaje TCP. La estructura de datos en la que el sistema operativo mantiene la PCB y el número de puerto del proceso de red es una tabla hash.
3.3 Número de secuencia de 32 bits y número de secuencia de confirmación del protocolo TCP (este campo es útil para la deduplicación de retransmisión de ventana deslizante y tiempo de espera)
El cliente puede enviar varios mensajes en un corto período de tiempo. Tenga en cuenta que el orden en que estos mensajes llegan al servidor es incierto. Entonces, después de que el cliente recibe la respuesta del servidor, ¿cómo puede distinguir a qué solicitud envié antes de que corresponda esta respuesta? Esto se debe a que existen números de secuencia de 32 bits y números de secuencia de confirmación de 32 bits en el protocolo TCP.
El número de secuencia es un campo utilizado para identificar paquetes de datos en el protocolo TCP y representa el número de secuencia del primer byte en el flujo de bytes del paquete de datos enviado por el remitente. El propósito del número de secuencia es garantizar el orden y la integridad de los paquetes de datos. En el protocolo TCP, cada paquete de datos tiene un número de secuencia único.
El número de reconocimiento (Número ACK) es un campo en el protocolo TCP que se utiliza para confirmar que el receptor ha recibido exitosamente el paquete de datos e indica el número de secuencia del siguiente paquete de datos que el receptor espera recibir. En el protocolo TCP, el receptor debe enviar un paquete de confirmación (paquete ACK) para informarle al remitente que el paquete de datos se recibió correctamente. El campo Número ACK en el paquete de confirmación es el número de secuencia del siguiente paquete de datos que el receptor espera recibir.
La razón para utilizar dos conjuntos de números de secuencia es que el protocolo TCP es full-duplex y tanto el cliente como el servidor pueden actuar como remitentes o receptores, por lo que es necesario utilizar dos conjuntos de números de secuencia.
3.4 Tamaño de ventana de 16 bits del protocolo TCP (utilizado para controlar la velocidad de envío de mensajes)
Cuando el protocolo TCP envía datos, si el remitente los envía demasiado rápido, el receptor no tendrá tiempo de leerlos. El mensaje llenará el búfer de entrada de la otra parte. Si el búfer de la otra parte está lleno, aún se enviará. y el mensaje recién enviado será descartado directamente. Entonces necesitas controlar la velocidad de envío de mensajes.
Hay un tamaño de ventana de 16 bits en el protocolo TCP, que se utiliza para completar el tamaño de su propio búfer de entrada . Cuando el mensaje se transmite a la otra parte, la otra parte sabrá cuánto espacio queda en su búfer de entrada y podrá controlar la velocidad de envío de datos.
La existencia del tamaño de ventana de 16 bits permite a las partes en comunicación intercambiar capacidades de recepción y lograr control de flujo.
3.5 Seis bits de bandera del protocolo TCP (diferenciación de tipos de mensajes)
El servidor puede enfrentarse a muchos tipos diferentes de clientes, puede haber mensajes que inician conexiones y respuestas, etc. Para distinguir diferentes tipos de mensajes, el encabezado TCP está configurado con varios indicadores 01.
- URG: configurado, el campo del puntero de emergencia es válido
- ACK: Confirma que el segmento ha sido recibido
- PSH: insta al receptor a que permita que su capa superior elimine los datos del búfer de entrada (empuje) lo antes posible, incluso si el búfer no está lleno
- RST: restablecer, cerrar con fuerza una conexión anormal
- SYN: Solicitudes para establecer una conexión
- FIN: desconectar una conexión
4. Mecanismo de respuesta de confirmación (ACK)
TCP numera cada byte de datos. Ese es el número de serie. Cada ACK lleva un número de secuencia de confirmación correspondiente, lo que significa decirle al remitente qué datos he recibido y dónde comenzar a enviarlos la próxima vez.
5. Mecanismo de retransmisión por tiempo de espera
Una de las principales faltas de confiabilidad de la transmisión de la red es el problema de la pérdida de paquetes. La solución del protocolo TCP es exceder el tiempo de espera y retransmitir.
Si el host A envía datos a B y los paquetes se pierden debido a problemas de red, B, naturalmente, no responderá a A. Si el host A descubre que no ha recibido una respuesta de confirmación durante un período de tiempo, lo reenviará.
Si el host A envía el mensaje al host B y el host B recibe el mensaje pero se pierde la respuesta, el host A lo retransmitirá después de un período de tiempo.
De esta manera, el receptor recibirá dos mensajes idénticos y recibirá datos duplicados, lo que también refleja falta de confiabilidad. El receptor debe realizar una deduplicación basada en el número de secuencia de 32 bits.
Tiempo de retransmisión: dado que la transmisión de datos está relacionada con el entorno de red en ese momento, el tiempo de retransmisión no se puede establecer en un valor fijo, sino que el sistema operativo ajusta dinámicamente el tiempo de retransmisión.
Para garantizar una comunicación de alto rendimiento en cualquier entorno, TCP calcula dinámicamente este tiempo de espera máximo.
En Linux (lo mismo ocurre con BSD Unix y Windows), el tiempo de espera se controla en unidades de 500 ms, y el tiempo de espera para cada retransmisión de tiempo de espera es un múltiplo entero de 500 ms.
Si aún no recibe respuesta después de retransmitir una vez, espere 2*500 ms antes de retransmitir.
Si aún no hay respuesta, espere 4*500 ms para la retransmisión, y así sucesivamente, aumentando exponencialmente.
Cuando se acumula una cierta cantidad de retransmisiones, TCP considera que hay una anomalía en la red o en el host par y cierra la conexión a la fuerza.
6. Mecanismo de gestión de conexión.
El protocolo de enlace de tres vías es la base para crear una estructura de conexión TCP. La estructura de conexión TCP es una estructura de datos que mantiene la retransmisión de tiempo de espera, la llegada secuencial, el control de flujo, el estado de la conexión, etc. para garantizar la confiabilidad.
La naturaleza orientada a la conexión de TCP garantiza indirectamente la confiabilidad de la comunicación. Al mismo tiempo, debido a que el protocolo UDP no tiene conexión, no mantiene estructuras de datos como retransmisión de tiempo de espera, llegada secuencial y control de flujo, por lo que UDP no es confiable.
- CERRADO: Estado inicial, que indica que la conexión TCP no se ha establecido o ha finalizado.
- ESCUCHAR: Indica que el puerto TCP está esperando una solicitud de conexión.
- SYN-SENT: indica que la solicitud de conexión TCP se ha enviado al host remoto y está esperando la confirmación de la respuesta.
- SYN-RECEIVED: Indica que la solicitud de conexión TCP ha sido aceptada por el servidor y se ha enviado una respuesta para confirmar la solicitud de conexión.
- ESTABLECIDO: Indica que la conexión TCP se ha establecido exitosamente y que puede comenzar la transmisión de datos.
- FIN-WAIT-1: indica que la conexión TCP se ha cerrado, pero el punto final local aún puede enviar datos y esperar la confirmación del punto final remoto.
- CLOSE-WAIT: indica que la conexión TCP ha recibido la solicitud de cierre del par, el puerto local aún puede enviar datos y luego la conexión se cierra.
- FIN-WAIT-2: indica que la conexión TCP está lista para cerrarse, pero el punto final remoto aún tiene datos para transmitir y está esperando una solicitud de cierre del punto final remoto.
- LAST-ACK: Indica que la conexión TCP ha emitido una solicitud de cierre y recibió confirmación tanto en el puerto local como en el puerto remoto, y se envía la confirmación final para completar el cierre de la conexión.
- TIEMPO DE ESPERA: Indica que la conexión TCP se ha cerrado normalmente y está esperando que se borre todos los mensajes de red relacionados. Por lo general, toma un intervalo de tiempo fijo antes de ingresar al estado CERRADO.
6.1 Apretón de manos de tres vías (el establecimiento de la conexión lo inicia el cliente)
SYN_SENT es un estado en el protocolo TCP/IP que representa un cliente TCP que ha enviado una solicitud de conexión (SYN) y está esperando que la otra parte devuelva una confirmación de conexión (ACK). Durante el proceso de conexión de protocolo de enlace de tres vías TCP, cuando el cliente envía un paquete SYN, el estado TCP del cliente cambiará a SYN_SENT. En este estado, el cliente TCP continuará intentando enviar paquetes SYN al servidor hasta que reciba un paquete ACK devuelto por el servidor para establecer una conexión.
SYN_RECV, que es un estado en el protocolo TCP/IP. Durante el establecimiento de una conexión TCP, después de recibir el paquete SYN del cliente, el servidor envía un paquete ACK y SYN como respuesta, lo que indica que ha recibido con éxito la solicitud de conexión del cliente e inicia una solicitud de confirmación de conexión al cliente. En este momento, el estado TCP del servidor pasa a ser SYN_RECV. En este estado, el servidor esperará a que el paquete ACK del cliente complete el proceso de conexión de protocolo de enlace de tres vías TCP. No se preocupe si no recibe un paquete ACK del cliente dentro de un período de tiempo, el servidor pensará que su paquete ACK+SYN se ha perdido e iniciará una retransmisión por tiempo de espera.
El protocolo de enlace de tres vías se considera completo cuando el cliente envía un ACK durante el tercer protocolo de enlace. El servidor considera que el protocolo de enlace de tres vías está completo solo cuando recibe la respuesta ACK del cliente. Existe una diferencia en el tiempo de finalización del protocolo de enlace de tres vías entre el cliente y el servidor. El protocolo de enlace de tres vías no necesariamente tiene que ser exitoso, especialmente porque el cliente no sabe si se perdió el último ACK del cliente, pero tenemos retransmisión de tiempo de espera y otros mecanismos para resolver este problema.
¿Por qué es necesario dar la mano tres veces?
Debido a que TCP se encuentra en la capa de transporte y es administrado por el sistema operativo, mantener conexiones TCP tiene costos de tiempo y espacio.
Si el número de apretones de manos es solo una vez y el cliente solo envía SYN una vez para establecer la conexión con éxito, entonces algunos elementos maliciosos pueden usar el cliente para conectarse como locos para iniciar una conexión. Hay un costo para el servidor para mantener la conexión. lo que hará que la cantidad de conexiones disponibles en el servidor aumente Menos (inundación SYN).
Si el número de apretones de manos es dos. Es lo mismo que el protocolo de enlace único: después de que el cliente envía SYN y el servidor devuelve SYN + ACK, el servidor considera que la conexión se ha establecido correctamente. También provocará una inundación SYN.
¿Por qué utilizar un apretón de manos de tres vías? En primer lugar, TCP es un protocolo de comunicación full-duplex y el protocolo de enlace de tres vías es el costo mínimo para verificar si la comunicación full-duplex es normal. En segundo lugar, para evitar la inundación de SYN, la última vez que el cliente inicia la conexión en el protocolo de enlace de tres vías, la última vez que el cliente envía ACK, significa que la conexión fue exitosa. Si el cliente desea establecer una conexión en el servidor , debe establecer la conexión en el cliente. Si el cliente quiere lanzar un ataque de inundación SYN, también sufrirá el mismo consumo. El protocolo de enlace de tres vías puede evitar eficazmente ataques SYN en un solo host. (Sin embargo, cabe señalar que el protocolo TCP no resuelve la prevención de ataques de inundación SYN. ¡La tarea principal del protocolo TCP es la comunicación de red!)
Si el número de apretones de manos es cuatro, no funcionará. Después de que el servidor envíe una respuesta ACK por última vez, establecerá una conexión aquí. Siempre que el cliente encuentre una manera de no recibir esta conexión, la relación de conexión no se puede establecer en el cliente. Existe riesgo de ataque de inundación SYN.
Si el número de apretones de manos es un número impar mayor que tres, tres apretones de manos ya pueden cumplir con los requisitos y no es necesario aumentar el número de apretones de manos para hacer perder el tiempo a ambas partes.
6.2 Saludar cuatro veces (la desconexión es cuestión de ambas partes)
La desconexión es un asunto de ambas partes y requiere el consentimiento de ambas partes.
Durante las cuatro fases de oleada, tanto el cliente como el servidor pueden iniciar activamente una desconexión.
Cuando una parte quiere desconectarse, es posible que la otra parte también quiera desconectarse, lo que puede hacer que cuatro ondas se conviertan en tres ondas.
El estado final de la parte que se desconecta activamente es TIME_WAIT, y la parte que se desconecta pasivamente entrará en el estado CLOSE_WAIT después de saludar dos veces. Si aparece una gran cantidad de estados CLOSE_WAIT en la parte desconectada, o el servidor está bajo demasiada presión y no tiene tiempo para ejecutar el cierre (el servidor todavía tiene datos que aún no se han enviado), o su cierre simplemente se ha olvidado.
Después de que se completen cuatro oleadas, la parte que se desconecte activamente mantendrá TIME_WAIT durante un período de tiempo.
Cuánto tiempo mantener: este tiempo es el doble del MSL (MSL: el tiempo de supervivencia más largo de un segmento TCP en la red. Después de este tiempo, el segmento se descartará. El valor predeterminado de MSL es 2 minutos (CentOS7 es 1 minuto) .)
Por qué es necesario mantenerlo durante un período de tiempo: 1. Porque el iniciador no puede confirmar si la otra parte ha recibido la última respuesta ACK de las cuatro ondas y necesita esperar un período de tiempo. Si la parte pasiva reenvía el Mensaje FIN de la tercera ola, luego la parte activa Luego puede reenviar el mensaje de respuesta ACK para la cuarta ola, tratando de garantizar el éxito de la cuarta ola. 2. Cuando ambas partes se desconectan, todavía quedan paquetes en la red y deben esperar a que se borre todos los paquetes de red relevantes. (De lo contrario, si el servidor se reinicia inmediatamente, puede recibir datos tardíos del proceso anterior, pero es probable que estos datos sean incorrectos);
Si el servidor se apaga primero y se reinicia dentro de un período de tiempo, ya no podrá vincular el último puerto vinculado. Debe esperar hasta que el último estado del servidor cambie a CERRADO antes de que ese puerto pueda reutilizarse para las conexiones. . Para un servidor con una gran cantidad de visitas, si se bloquea, una gran cantidad de puertos no se pueden volver a vincular durante un período de tiempo, por lo que esto no es razonable. El uso de setsockopt() permite la creación de descriptores de socket con el mismo número de puerto pero diferentes direcciones IP.
GETSOCKOPT(2)
#include <sys/types.h> /* See NOTES */
#include <sys/socket.h>
int getsockopt(int sockfd, int level, int optname,
void *optval, socklen_t *optlen);
int setsockopt(int sockfd, int level, int optname,
const void *optval, socklen_t optlen);int opt=1;
setsockopt(listenfd,SOL_SOCKET,SO_REUSEADDR,&opt,sizeof(opt));7. control de flujo
Como se mencionó en el capítulo anterior, hay un tamaño de ventana de 16 bits en el mensaje TCP. De hecho, la opción de 40 bytes en el encabezado TCP también contiene un factor de expansión de ventana M. El tamaño real de la ventana es el valor de la ventana. campo desplazado a la izquierda en M bits. Se utiliza para intercambiar el tamaño de los buffers de recepción de ambas partes. Durante el protocolo de enlace de tres vías, las dos partes completaron incidentalmente el intercambio del tamaño del búfer de recepción en el mensaje TCP.
Cuando el búfer de recepción esté lleno, habrá dos estrategias: 1. Cuando la capa superior del extremo receptor elimine los datos, el extremo receptor enviará una notificación de actualización de ventana al remitente; 2. El extremo emisor le preguntará al receptor finalice el tamaño de la ventana de vez en cuando.
8. Ventana corrediza/mecanismo de retransmisión rápida
8.1 La naturaleza de las ventanas correderas.
La ventana deslizante es esencialmente una parte del búfer de envío, y la parte del búfer de envío que se envió pero no respondió se llama ventana deslizante.
El movimiento de la ventana deslizante es esencialmente el movimiento del subíndice de la matriz.
8.2 El papel de las ventanas correderas
- Control de flujo: el mecanismo de ventana deslizante de TCP permite al receptor controlar la velocidad de envío del remitente para garantizar que el receptor pueda recibir y procesar datos dentro de las capacidades de procesamiento. El receptor informa al remitente ajustando el tamaño de la ventana deslizante, y también puede ajustar dinámicamente el tamaño de la ventana deslizante en función de la potencia de procesamiento del receptor. La ventana deslizante mejora hasta cierto punto la eficiencia de transmisión de datos de TCP.
- Control de congestión: el mecanismo de ventana deslizante de TCP puede ayudar a controlar la congestión en la red. Cuando se produce una congestión en la red, el receptor puede reducir el tamaño de la ventana deslizante para ralentizar la velocidad de envío de datos, evitando así una mayor presión de carga en la red. Al ajustar dinámicamente el tamaño de la ventana deslizante, TCP puede controlar de forma adaptativa la velocidad de transmisión de datos según el grado de congestión de la red.
- Transmisión confiable: el mecanismo de ventana deslizante TCP proporciona una transmisión de datos confiable. El remitente solo enviará los datos de la siguiente ventana deslizante después de recibir los datos confirmados por el receptor, y el receptor también confirmará los datos recibidos al mismo tiempo. Si el remitente no recibe un acuse de recibo o el receptor recibe datos desordenados, el remitente puede retransmitir selectivamente los datos a través del mecanismo de ventana deslizante para garantizar una transmisión confiable de datos.
8.3 Algunas preguntas y respuestas sobre ventanas correderas
¿Cómo se establece el tamaño inicial de la ventana corredera? Cómo cambiará el futuro:
El tamaño de la ventana deslizante se refiere al tamaño máximo que puede enviar datos directamente sin esperar una respuesta de confirmación. El tamaño de la ventana en la imagen de arriba es de 4000 bytes (cuatro segmentos). El tamaño de la ventana deslizante está relacionado con la capacidad de recepción de la otra parte.
¿La ventana corredera tiene que deslizarse hacia la derecha? ¿Se deslizará hacia la izquierda?
La ventana deslizante puede deslizarse hacia la derecha o no moverse (el búfer de recepción de la otra parte está lleno y la ventana deslizante está suspendida). Pero nunca se deslizará hacia la izquierda , porque los datos de la izquierda han sido enviados y respondidos.
¿Cambiará el tamaño de la ventana corredera? Cómo cambiar:
La ventana deslizante cambia dinámicamente según la capacidad de recepción de la otra parte y puede aumentar o disminuir.
El orden en que los datos en la ventana deslizante reciben respuestas no es el mismo. Si los datos del medio o de la cola se confirman primero, ¿cómo se debe manejar la ventana deslizante?
El ACK de la ventana deslizante fuera de servicio no afecta la ventana deslizante, mientras llegue el ACK más a la izquierda, la ventana deslizante se moverá hacia la derecha.
El problema de pérdida de paquetes más temido es:
1. Si no se pierden los datos, pero sí el ACK. No tenga miedo de esto, porque hay un número de secuencia de confirmación de 32 bits en el protocolo TCP, por ejemplo, si se pierde el ACK del número de secuencia 1001-2000, siempre que el cliente reciba el ACK de la secuencia. número 2001-3000 (mayor que 2000), significa que se han recibido todos los mensajes anteriores, luego deslice la ventana directamente a 3001.
2. Si los datos se pierden (el servidor no recibe los datos y, por supuesto, no hay ACK), cuando el cliente recibe posteriormente tres paquetes ACK con el mismo número de secuencia, se activará el mecanismo de retransmisión rápida .
Qué hacer si no hay suficiente espacio detrás de ti si te deslizas hacia atrás:
El kernel del sistema operativo organiza el búfer de envío en una estructura de anillo. (Similar al modelo productor-consumidor de la estructura en anillo)
Dado que la ventana deslizante tiene en cuenta la capacidad de recepción del par, ¿por qué no se pueden enviar todos los datos de la ventana deslizante a la vez?
Esto se debe a que el protocolo de trama MAC de la capa de enlace de datos estipula que su carga útil no puede exceder los 1500 bytes, por lo que la carga útil máxima de una sola transmisión en la capa de transporte es de 1460 bytes. (Tamaño máximo de segmento MSS) Por supuesto, está bien si el tamaño de la carga útil de una sola transmisión en la capa de transporte excede los 1460 bytes, pero el protocolo IP necesita fragmentar y ensamblar mensajes excesivamente grandes, lo que aumenta la probabilidad de pérdida de paquetes.
9. Control de la congestión
Hay demasiados coches en la carretera, por lo que los atascos son inevitables. Lo mismo ocurre con la red: varios hosts que realizan comunicaciones TCP al mismo tiempo también provocarán congestión en la red. Cada host receptor experimenta repentinamente una gran pérdida de paquetes. Si una gran cantidad de paquetes perdidos se retransmite precipitadamente durante un tiempo de espera en este momento, sin duda empeorará la situación de la red.
Cuando se produce una congestión, TCP habilitará el mecanismo de inicio lento . Todos los hosts primero enviarán una pequeña cantidad de datos para explorar la ruta (reduciendo la cantidad de mensajes enviados al mismo tiempo, aliviando en gran medida la presión de la red) y luego aumentarán la velocidad de envío. después de comprender la condición de la red. Como se muestra abajo:
También hay un concepto de ventana de congestión (el tamaño cambia según el estado de la red) en la figura , que refleja la capacidad de almacenamiento de la red.
Mecanismo de inicio lento:
1. Cuando comience el envío, defina el tamaño de la ventana de congestión como 1;
2. Cada vez que se recibe una respuesta ACK, la ventana de congestión aumenta en 1 (se duplica, 1 se convierte en 2, 2 se convierte en 4, 4 se convierte en 8. Crecimiento exponencial. En la etapa inicial, el crecimiento exponencial se utiliza para realizar una ruta de inicio lento exploración. Si la exploración de la ruta es exitosa, significa que la red está bien y, al mismo tiempo, el índice explota rápidamente, restaurando rápidamente la velocidad de comunicación al máximo. No tiene sentido duplicar la ventana de congestión en el último período de crecimiento. , por lo que la ventana de congestión no se puede simplemente duplicar en el período posterior, y es necesario introducir un umbral llamado inicio lento. Cuando la ventana de congestión excede este umbral, ya no crece exponencialmente, sino linealmente)
3. El tamaño real de la ventana enviada = min (ventana de congestión, el tamaño de la ventana de 16 bits en el encabezado TCP proporcionado por el host par);
Explicación del tercer punto:
La capacidad de envío del remitente depende de las tres situaciones siguientes:
1. El tamaño de la ventana deslizante del remitente;
2. El tamaño de ventana de 16 bits en el encabezado TCP proporcionado por el host par. (Búfer de recepción de pares)
3. La ventana de congestión de la red actual.
1. Cuando se inicia TCP, el umbral de inicio lento es igual al valor máximo de la ventana (igual a 24 en la figura).
2. Durante cada tiempo de espera y retransmisión, el umbral de inicio lento se convertirá en la mitad del valor original y la ventana de congestión se restablecerá a 1 (el umbral en la figura se reduce de 24 a 12).
10. Respuesta retrasada
El extremo emisor envía un mensaje al búfer de recepción del extremo opuesto. Después de recibir el mensaje, el extremo opuesto descubre que todavía queda 1 M en el búfer de recepción. Si responde inmediatamente y le dice al extremo emisor que todavía queda 1 M en el búfer de recepción. el búfer de recepción y luego enviar. El final realizará el control de flujo de acuerdo con la capacidad de 1 M la próxima vez. Si el par adopta una respuesta retrasada, la capa superior tendrá la probabilidad de eliminar algunos mensajes en el búfer de recepción, de modo que pueda responder en un espacio mayor y reducir el número de respuestas (hay un número de secuencia de confirmación de 32 bits). en TCP, lo que puede garantizar que se haya recibido el mensaje con el número de secuencia anterior). Los reconocimientos retrasados pueden aumentar el rendimiento de la red .
Por supuesto, esto no significa que cada paquete se retrase en respuesta.
1. Límite de cantidad: responda una vez cada N paquetes;
2. Límite de tiempo: Responda una vez si se excede el tiempo máximo de retardo (debe ser menor que el tiempo de espera de retransmisión)
El número específico y el período de tiempo de espera varían según el sistema operativo; generalmente N es 2 y el período de tiempo de espera es 200 ms;
11. Aprovechar las respuestas
Un extremo envía un mensaje al otro extremo. Para reducir la transmisión de mensajes, el otro extremo establecerá el indicador ACK en 1 y transportará un número de secuencia de confirmación de 32 bits, más la carga útil y lo enviará al extremo opuesto. (La carga útil de transporte de respuesta, que también es un método de comunicación común en TCP, puede mejorar la eficiencia de la transmisión de mensajes)
12. Comprender la orientación del flujo de bytes de TCP y la orientación de datagramas de UDP
La esencia de la capa de aplicación que llama a escribir es copiar los datos al búfer de envío. Si los datos están llenos, se suspenderán. La esencia de la capa de aplicación que llama a leer es leer los datos del búfer de recepción. Si los datos está lleno, será suspendido. Dado que ambas partes tienen un búfer de lectura/escritura, TCP es un protocolo de comunicación full-duplex.
Para el protocolo TCP, no le importa la longitud de un mensaje en los datos proporcionados por la capa de aplicación. A sus ojos, todos los datos proporcionados por la capa de aplicación son bytes. Debido a la existencia del búfer, la lectura y escritura del protocolo TCP no necesitan coincidir. Cuánto da o quiere la capa superior y cómo combinar estos bytes en mensajes, a TCP no le importa en absoluto. Si quieres combínelos en mensajes, la aplicación piensa en una solución por su cuenta . Por ejemplo, la capa de aplicación puede llamar a escribir varias veces para escribir un total de 100 bytes, y el par puede llamar a leer una vez para leer 100 bytes. (UDP es para datagramas. Debe leerse una vez para enviarse. Cada vez que se recibe, debe ser un mensaje. Este mensaje se puede serializar y deserializar más tarde. La transmisión de este mensaje independiente se denomina orientada a datagramas)
13. Problema con la bolsa pegajosa
Como se mencionó anteriormente, a TCP no le importa la síntesis de mensajes y necesita la capa de aplicación para resolver el problema por sí sola.
La esencia de resolver el problema complicado es aclarar los límites entre los mensajes.
Cómo aclarar los límites:
1. Estrategia de lectura de longitud fija: para paquetes de longitud fija, asegúrese de que se lean en un tamaño fijo cada vez; por ejemplo, la estructura de solicitud anterior tiene un tamaño fijo, así que comience desde el principio del búfer y presione sizeof (Solicitar) en secuencia Recién leído;
2. Estrategia de longitud del paquete de acuerdo del encabezado del paquete : para paquetes de longitud variable, puede acordar un campo para la longitud total del paquete en la posición del encabezado del paquete, de modo que conozca la posición final del paquete;
3. Estrategia de separación de caracteres especiales : para paquetes de longitud variable, también se pueden utilizar delimitadores claros entre paquetes (el protocolo de la capa de aplicación lo determina el propio programador, siempre que el delimitador no entre en conflicto con el texto)
14. El problema del establecimiento anormal de una conexión TCP.
1. Uno o ambos clientes y servidores TCP cuelgan.
Antes de colgar, el cliente y el servidor TCP estaban conectados. Una vez que una de las partes cuelga, el sistema operativo saludará automáticamente cuatro veces y se desconectará normalmente. (No hay diferencia con llamar a cerrar manualmente)
2. Reinicie la máquina
El sistema operativo también envió el proceso. El sistema operativo saldrá del proceso antes de reiniciar, por lo que esta situación no es diferente de la salida normal del proceso.
3. La máquina está apagada o el cable de red está desconectado.
El extremo que se apagó no tuvo tiempo de enviar un mensaje al otro extremo antes de enviarlo. El otro extremo iniciará consultas periódicamente y se desconectará después de múltiples respuestas sin respuesta. (Para los mecanismos de administración de conexiones, la mayoría de ellos son administrados por la capa de aplicación (HTTP, HTTPS, etc.). Ciertos protocolos de la capa de aplicación también tienen algunos de estos mecanismos de detección, como las conexiones largas HTTP, que también detectarán periódicamente el estado de la otra parte. Por ejemplo, QQ Después de la desconexión, también intentará periódicamente reiniciar el protocolo de enlace de tres vías TCP para conectarse)
5. Resumen del protocolo UDP/TCP
1. Fiabilidad y rendimiento de TCP
fiabilidad:
Suma de comprobación, número de secuencia (llegada en orden), respuesta de confirmación, retransmisión de tiempo de espera, gestión de conexión, control de flujo, control de congestión
Mejorar el rendimiento:
Ventana deslizante, retransmisión rápida, respuesta retardada, respuesta superpuesta, control de flujo, control de congestión
2. Escenarios aplicables de los protocolos UDP y TCP
UDP se utiliza en campos de comunicación que requieren transmisión de alta velocidad y rendimiento en tiempo real, como transmisión en vivo, QQ temprano, transmisión de video, etc. Además, UDP se puede usar para transmisión.
TCP se utiliza para una transmisión confiable y se utiliza en escenarios como transferencia de archivos y actualizaciones de estado importantes;
El acuerdo a utilizar depende en última instancia de la dirección de la empresa.
3. Respecto al segundo parámetro de escucha.
int listen(int sockfd, int backlog);El protocolo TCP mantiene una cola de conexión completa para la capa superior. En la cola hay objetos a conectar que han completado el protocolo de enlace de tres vías. Esta cola no se puede dejar fuera. Su existencia es como salir a comer y necesitar hacer cola. . El último cliente se ha ido y la cola sigue ahí. Los usuarios pueden conectarse inmediatamente, lo que mejora enormemente la velocidad de TCP. Por supuesto, la cola no puede ser demasiado larga. ¿Estás dispuesto a esperar porque la cola es demasiado larga? Lo mismo Esto es cierto para TCP. No es necesario que la cola sea demasiado larga, porque el mantenimiento de esta cola requiere una sobrecarga. Esta cola de conexión completa se ve afectada por el segundo parámetro de escucha.
El segundo parámetro de escucha se establece en 2. Cuando se establece la conexión por cuarta vez (cliente 36648), puede ver que el cliente cree que ha establecido la conexión con éxito, pero en el lado del servidor, el estado del establecimiento de la conexión es SYN_RECV. (El cliente inicia una solicitud para establecer una conexión. Después de recibirla, el servidor está en el estado SYN_RECV y envía una respuesta SYN+ACK al cliente, lo que le permite establecer una conexión exitosa. Sin embargo, cuando el cliente inicia la tercera apretón de manos, ignorará el ACK del cliente, el servidor no establecerá una conexión cuando habla y todavía está en el estado SYN_RECV, lo que se denomina estado semiconectado )
La capa inferior de tcp permite como máximo una acumulación + 1 conexión completa, y todas las conexiones posteriores son medias conexiones. (Si la semiconexión no completa el protocolo de enlace lo antes posible, el servidor la cerrará automáticamente)
1. Cola de semivínculo (utilizada para guardar solicitudes en estado SYN_SENT y SYN_RECV)
2. Cola de conexión completa (cola aceptada) (se utiliza para guardar solicitudes que están en el estado establecido, pero la capa de aplicación no llama a aceptar)
(Nota: puede utilizar Wireshark para analizar el proceso de comunicación TCP )