Mejora del rendimiento del protocolo de enlace de tres vías TCP
El proceso de protocolo de enlace de tres vías representa más del 10% del tiempo promedio de una solicitud HTTP, por lo que para usar correctamente los parámetros del protocolo de enlace de tres vías, debe usar el comando netstat para verificar qué etapa del protocolo de enlace tiene un problema. La optimización del cliente que inicia la conexión es relativamente simple, pero el servidor necesita monitorear el puerto, que es una parte de conexión pasiva, y mantiene muchos estados intermedios durante el proceso, y el método de optimización es relativamente complicado.
Optimización del cliente
Ajustar los tiempos de retransmisión de paquetes SYN
El objetivo principal del protocolo de enlace de tres vías para establecer una conexión es "sincronizar el número de serie". Solo los números de secuencia síncronos se pueden transmitir de manera confiable, y el nombre completo de SYN es Sincronizar números de secuencia (números de secuencia sincronizados).
Como parte que inicia la conexión, el cliente envía primero un paquete SYN, por lo que la conexión del cliente estará en el estado SYN_SENT. Si el cliente no recibe el ACK+SYN del servidor, retransmitirá el SYN. El número de retransmisiones está controlado por el parámetro tcp_syn_retries . El valor predeterminado es 5 veces; cada tiempo de espera es el doble que la vez anterior. De acuerdo con la estabilidad de la red y la ocupación del servidor de destino, se puede modificar el número de retransmisiones SYN y se puede ajustar el límite superior del tiempo de protocolo de enlace de tres vías del cliente.
Optimización del lado del servidor
Ajustar la longitud de la cola de semiunión SYN
Si desea aumentar la cola de semiconexión, no puede simplemente aumentar el valor de tcp_max_syn_backlog, sino que también debe aumentar somaxconn y el backlog juntos, es decir, aumentar la cola de aceptación. De lo contrario, simplemente aumentar tcp_max_syn_backlog no es válido.
Si la cola de semiconexión SYN está llena, ¿solo se puede interrumpir la conexión?
Activar la función syncookies puede establecer con éxito una conexión sin utilizar la cola de semiconexión SYN.
Ajustar el número de retransmisiones de paquetes SYN+ACK
Después de recibir el ACK + SYN del servidor, el cliente restaura el ACK al servidor y el estado de la conexión del cliente cambia de SYN-SENT a ESTABLELISHED, lo que indica que la conexión se estableció exitosamente. El servidor necesita recibir el ACK del servidor. el cliente cambiará a ESTABLELISHED, si no se recibe. El ACK del cliente retransmitirá ACK+SYN y permanecerá en el estado SYN_RCV.
Cuando la red está ocupada e inestable, la pérdida de paquetes será grave y en este momento se debe aumentar el número de retransmisiones. De lo contrario, se puede reducir el número de retransmisiones. La forma de modificar el número de retransmisiones es ajustar el parámetro tcp_synack_retries.
Ajustar la longitud de la cola de aceptación
Después de que el servidor recibe el ACK, la conexión se establece con éxito. En este momento, el kernel eliminará la conexión de la cola de semiconexión, luego creará una nueva conexión completa, la agregará a la cola de aceptación y esperará a que el proceso finalice. Llame a la función de aceptación para desconectar la conexión.
Si el proceso no puede llamar a la función de aceptación a tiempo, hará que la cola de aceptación (también llamada cola de conexión completa) se desborde y, finalmente, se descartará la conexión TCP establecida.
Cómo comprobar que la cola de aceptación de conexión está llena
Netstat -s se puede ejecutar cada pocos segundos. Si el número sigue aumentando, significa que la cola de aceptación de conexión ocasionalmente está llena.
Cómo evitar el protocolo de enlace de tres vías
La función TCP Fast Open debe ser compatible tanto con el cliente como con el servidor para que sea efectiva, lo que reduce el tiempo de las solicitudes HTTP en 1 RTT.
Resumen de la optimización del protocolo de enlace de tres vías de TCP
Mejora del rendimiento de TCP de cuatro ondas.
Para la optimización del lado activo, generalmente hay dos formas de cerrar la conexión: cerrar el mensaje RST y cerrar el mensaje FIN.
¿Cuál es la diferencia entre la función de cierre y la función de apagado?
Llamar a la función de cierre significa que la conexión está completamente desconectada. La desconexión completa no solo significa que no se pueden transmitir datos, sino que tampoco se pueden enviar datos. En este momento, la conexión de la parte que llamó a la función de cierre se denomina "conexión huérfana". Si usa el comando netstat -p, encontrará que el nombre del proceso correspondiente a la conexión está vacío.
No es elegante cerrar una conexión usando la función de cierre. Por lo tanto, existe una shutdown función para cerrar correctamente la conexión, que puede controlar la conexión en una sola dirección :
Optimización del lado activo
Ajustar los tiempos de retransmisión de paquetes FIN
Salude por primera vez, ajuste el parámetro tcp_orphan_retries, reduzca
Ajustar el tiempo del estado FIN WAIT2
Después de recibir el ACK, la parte activa ingresa al estado FIN-WAIT2, lo que indica que el canal de envío de la parte activa se ha cerrado, y luego espera a que la otra parte envíe un mensaje FIN para cerrar el canal de envío de la otra parte.
Si la conexión se cierra usando la función de apagado en este momento, la conexión siempre puede estar en el estado FIN-WAIT2, porque puede continuar enviando o recibiendo datos. Pero para la conexión huérfana cerrada por la función de cierre, dado que ya no se pueden enviar ni recibir datos, este estado no puede durar demasiado y tcp_fin_timeout controla la duración de la conexión en este estado , y el valor predeterminado es 60 segundos:
Ajustar el límite superior de conexiones huérfanas
Cuando el proceso llama a la función de cierre para cerrar la conexión, la conexión será una conexión huérfana en este momento, porque ya no puede enviar ni recibir datos, hay un parámetro de número de conexiones huérfanas tcp_max_orphans, si es mayor que él, no irá a tcp cuatro veces y directamente RST restablece el mensaje para cerrar.
El papel del tiempo de espera.
①: Evite que los datos de conexión históricos sean recibidos incorrectamente por la misma conexión cuádruple: 2 MSL es tiempo suficiente para que se descarten los paquetes de datos históricos en ambas direcciones, de modo que los paquetes de datos de conexión originales desaparezcan naturalmente en la red. Los datos que reaparecen deben ser generado por la conexión recién establecida.
②: Asegúrese de que la parte que cierra pasivamente la conexión pueda cerrarse correctamente: espere un tiempo suficiente para que la parte cerrada pasivamente reciba el ACK, lo que ayudará a que se cierre correctamente.
Ajustar el límite superior del estado de espera de tiempo.
Parámetro tcp_max_tw_buckets, cuando el número de conexiones TIME_WAIT excede este parámetro, la conexión recién cerrada ya no experimentará TIME_WAIT y se cerrará directamente, y la concurrencia aumentará. Este número se puede aumentar adecuadamente y cuanto mayor sea, mejor, los recursos son limitado.
Conexiones multiplex en estado time_wait
Cuando tcp_tw_reuse y tcp_timestamps se establecen en 1, solo se aplica a la función de conexión, es decir, el cliente, y el puerto en el estado TIME_WAIT se reutiliza como una nueva conexión del cliente, que solo se aplica al cliente.
Optimización del lado pasivo
El número de estados close_wait
La parte pasiva comienza a ingresar al estado close_wait después de recibir FIN, esperando que el proceso llame a la función de cierre para cerrar la conexión. Por lo tanto, hay una gran cantidad de conexiones en el estado CLOSE_WAIT.
Reducir la cantidad de retransmisiones de paquetes FIN,
Resumen de la mejora del rendimiento de TCP con cuatro manos agitadas
Mejoras de rendimiento para transferencias de datos TCP
Ampliar el tamaño de la ventana
TCP proporciona un método que permite al remitente controlar la cantidad de datos enviados de acuerdo con la capacidad de recepción real de la ventana deslizante del receptor.
Cuando el kernel recibe los mensajes, debe usar el búfer para almacenarlos, de modo que el espacio restante del búfer se vuelva más pequeño y la ventana de recepción se vuelva más pequeña;
El proceso llama a la función de lectura, el mensaje se lee en el espacio de la memoria, se borra la memoria caché del kernel, el host puede recibir más mensajes y la ventana es grande.
El receptor coloca el tamaño del paquete en el campo de ventana del encabezado del paquete TCP.
tcp_window_scaling El valor máximo predeterminado de la ventana deslizante es de solo 64 KB, lo que no cumple con los requisitos de la red de alta velocidad actual. Para aumentar la velocidad de envío, se debe aumentar el límite superior de la ventana deslizante. Esto se hace configurando en Linux, el valor máximo puede ser de hasta 1 GB en este momento .
Ajustar el rango del búfer de envío
El búfer de envío es autoajustable . Cuando se confirman los datos enviados por el remitente y no hay datos nuevos para enviar, se liberará la memoria del búfer de envío.
Ajustar el rango del buffer de recepción
El búfer de recepción puede ajustar la ventana de recepción según el tamaño de la memoria libre del sistema:
La función de ajuste del búfer de envío se habilita automáticamente, mientras que el búfer de recepción debe configurarse con tcp_moderate_rcvbuf como 1 para habilitar la función de ajuste.
Recibir ajuste dinámico del buffer
, debemos establecer el límite superior del búfer para que sea el producto de retardo de ancho de banda. La función de ajuste del búfer de envío se habilita automáticamente, mientras que el búfer de recepción debe habilitarse configurando tcp_moderate_rcvbuf en 1. Entre ellos, el ajuste se basa en el rango de memoria TCP tcp_mem.
Ajustar el rango de memoria
Configurado a través de tcp_mem Generalmente, estos valores se calculan en función de la cantidad de memoria del sistema cuando se inicia el sistema.