Estúpidamente confundido acerca de TCP keepalive y HTTP keepalive
TCP keepalive es el temporizador de mantenimiento de actividad de TCP. En términos sencillos, TCP tiene una tarea programada para la cuenta regresiva. Después del tiempo de espera, la tarea se activará. El contenido es enviar un mensaje de detección al par para determinar si está vivo. (Piensa en un argumento: "Si no sabes nada de mí en 2 horas, huye".)
Como dice el concepto, se utiliza para detectar si el compañero está vivo, evitando así que conexión esté en estado "a mitad de camino".
El llamado medio abierto significa que uno de los dos extremos de la conexión de red se ha desconectado, mientras que el otro extremo sigue conectado.
(Figura 1) Diagrama de flujo de TCP keepalive
Mientras los dos extremos de la conexión se comunican, hay una tarea programada A. Cada vez que se transmite un mensaje, se restablecerá el tiempo Tarea A. Si no hay transmisión de mensajes nuevos dentro del límite de tiempo de la tarea programada tcp_keepalive_time, se activará la tarea programada A para enviar un mensaje de detección de supervivencia al par. Según las diferentes situaciones del mensaje de respuesta, existen diferentes ramas de operación, como se muestra en la figura anterior.
La tarea programada B se ejecutará cíclicamente. La lógica específica es: si el mensaje de detección de la tarea programada A no recibe un mensaje de respuesta, la tarea programada B comienza a ejecutarse. El contenido de la tarea B también es enviar mensajes de sonda, pero la diferencia es que B ejecutará tcp_keepalive_probes veces con un intervalo de tiempo de tcp_keepalive_intvl. El mensaje de detección de B también restablece la tarea programada A después de recibir el mensaje de respuesta para mantener el estado de la conexión.
Los tres parámetros mencionados anteriormente existen en el archivo del sistema y las rutas específicas son las siguientes:
Hay un archivo como búfer de datos en ambos extremos de la comunicación, y el El otro extremo lo envía a la corriente local. Los datos del puerto se almacenarán en este archivo. La "desconexión" mencionada anteriormente significa cerrar el archivo. Después de cerrarlo, todos los datos enviados al puerto actual no se almacenarán en el búfer, es decir, los datos se descartarán.
Pase el comando lsof -i :8080 y cambie 8080 a su número de puerto para ver este archivo buffer.
HTTP keepalive se refiere a conexiones persistentes y enfatiza la reutilización de conexiones TCP. (Escenario similar: siempre hacer preguntas antes de colgar el teléfono, colgar si no pasa nada, ampliar la duración de la llamada para confirmar que no hay nuevos temas)
Ampliar la duración de la conexión TCP, desde la creación al cierre de una conexión TCP Se pueden transferir más datos.
(Figura 2) Diagrama de flujo de mantenimiento de actividad HTTP
Mientras ambos extremos de la conexión de comunicación se comunican, hay una tarea programada de mantenimiento de actividad a nivel HTTP. Cuando el cliente inicia una Solicitud y recibe la Respuesta, se activa la tarea programada. La tarea programada comenzará a cronometrar y, después de alcanzar la distancia de tiempo de mantenimiento de actividad, la conexión se cerrará. Si durante el período de tiempo, el cliente inicia una Solicitud nuevamente y recibe una Respuesta, la tarea programada se restablecerá y cronometrará desde el principio.
La Figura 2 utiliza la biblioteca de sockets de Python como ejemplo para ilustrar cómo HTTP keepalive (o conexión persistente HTTP) actúa en el proceso de liberación de conexión en el nivel inferior durante el proceso de "solicitud-respuesta" HTTP. tiempo de conexión.
¿Por qué no utilizar la biblioteca de solicitudes de Python para dar un ejemplo? La capa inferior de solicitudes también es la gestión de conexiones de socket. La diferencia es que las solicitudes admiten el protocolo HTTP y pueden analizar varias partes de la información del socket HTTP. De manera similar, los elementos internos de los objetos Solicitud y Respuesta en varios marcos web siguen siendo la gestión de conexiones de socket. Solo mencionar el socket puede eliminar mucha información que interfiere.
Descripción del descarte de datos después del tiempo de espera de mantenimiento de actividad HTTP del lado del servidor.
Los estudiantes que recién están comenzando pueden estar confundidos como yo: el servidor descartará los datos recibidos después de que expire el tiempo de mantenimiento, entonces, ¿cómo puede el servidor recibir los datos del puerto en el futuro?
Tenemos que mencionar el modelo de bifurcación del servidor: el proceso principal del servidor escucha el puerto y, cuando llegan los datos, se entregan al proceso secundario para su procesamiento, y el proceso principal continúa escuchando el puerto en un bucle.
Específicamente, cuando llegan los datos, el proceso principal primero crea un nuevo identificador de conexión de socket (la esencia es generar un descriptor de archivo de socket y colocarlo en el disco, y los datos del puerto se almacenarán y almacenarán en el buffer). el archivo). Luego, bifurca el proceso hijo; el proceso principal cierra el nuevo identificador de socket y el proceso hijo mantiene la conexión del identificador de socket (cuando se cierra un identificador de socket en todos los procesos, TCP comenzará a agitarse cuatro veces); , el proceso hijo se hace cargo de la comunicación con los clientes.
Al igual que en el ejemplo de la (Figura 3), el proceso principal bifurcará muchos procesos secundarios que A y B están conectados a solicitudes de diferentes clientes. El descriptor del archivo de socket a no afectará los datos de b. Leer y escribir.
(Figura 3) El proceso de transferencia de identificadores de socket bajo el modelo fork
La conclusión es que cada conexión de socket establecida entre el servidor y el mundo exterior tiene un descriptor de archivo independiente y un independiente El proceso hijo se comunica con el cliente. La desconexión del lado del servidor significa cerrar la lectura y escritura de un determinado descriptor de archivo, no cerrar el intercambio de datos de todo el puerto y no afecta la comunicación entre otras conexiones de socket. En cuanto al descarte, significa que si todavía hay datos enviados a este descriptor de archivo de socket desde el mundo exterior, se descartarán, porque se ha inhabilitado la escritura de este descriptor de archivo, por lo que, naturalmente, los datos no se pueden descargar.
TCP keepalive es más como un mecanismo de respaldo para garantizar que el sistema funcione de manera ordenada, asegurando que el sistema eventualmente pueda recuperar la conexión de socket medio abierta; de lo contrario, ya no podrá recibir más solicitudes después de una operación a largo plazo (el número máximo de conexiones de socket del sistema).
HTTP keepalive es una operación de la capa de aplicación que permite que la aplicación del servidor decida de forma independiente la liberación del socket. Debido a que el valor de cuenta regresiva predeterminado de TCP keepalive es muy largo, una determinada conexión del servicio web. Por lo general, no es necesario esperar tanto. Para decirlo sin rodeos, TCP tiene un temporizador, y HTTP también puede configurar su propio temporizador. Si el temporizador de HTTP caduca primero, también tiene derecho a permitir que TCP entre en el proceso de onda de cuatro ondas.
Después de que se transmite un determinado paquete de datos, existen dos tareas programadas de mantenimiento de actividad al mismo tiempo y entran juntas en el estado de cuenta regresiva. Una es un programa relacionado con el código TCP del núcleo del sistema y la otra es un programa de alto nivel. Lenguaje de programación de nivel (Python/Java/Go, etc.) Programas de código de marco web, se ejecutan juntos sin conflictos.
HTTP keepalive es algo en la capa de aplicación. Las aplicaciones que brindan servicios externos durante la producción tendrán parámetros keepalive, como keepalive de Gunicorn y keepalive_timeout de Nginx. A través de este parámetro, podemos controlar el tiempo de espera para los siguientes datos en un nivel más avanzado.
Además, si hay N servicios web en el mismo servidor, el parámetro TCP keepalive surte efecto globalmente y es difícil de ajustar.
Si su estructura de red es similar a cliente-nginx-servidor web, entonces también debe considerar la cuestión de hacer coincidir los tamaños de los parámetros keepalive de nginx y el servidor web. Aquí están las sugerencias de Gunicorn para el uso de parámetros keepalive. :
Suponiendo que el tiempo de espera de la web es mucho más corto que el de nginx y que la conexión cliente-nginx todavía está ahí, nginx-web se ha desconectado y la web perderá algunos datos. Para los clientes, puedo. No lo entiendo. Los resultados son intolerables. Por lo tanto, es mejor coordinar con el tiempo de espera de nginx, para no diferir demasiado (ni demasiado corto ni demasiado largo).
Una cosa más que decir sobre no tardar demasiado.
Si espera mucho tiempo, el servicio web acumulará y mantendrá muchas conexiones, por lo que no podrán llegar nuevas solicitudes y es posible que las conexiones que se mantienen no se utilicen en gran medida (tal vez el código del cliente esté en el punto de interrupción, o el cliente puede haber sido cerrado hace mucho tiempo). El resultado es que el servidor netstat muestra un montón de conexiones y todas las solicitudes nuevas se suspenden o incluso se descartan.