conexión corta
El protocolo HTTP era originalmente (0.9/1.0) un protocolo muy simple, y el proceso de comunicación también adoptó un método simple de "solicitud-respuesta".
Su transmisión de datos subyacente se basa en TCP/IP. Antes de enviar una solicitud, debe establecer una conexión con el servidor y cerrará la conexión inmediatamente después de recibir el mensaje de respuesta.
Debido a que todo el proceso de conexión entre el cliente y el servidor es muy breve y no permanecerá conectado al servidor durante mucho tiempo, se denomina "conexiones de corta duración". El protocolo HTTP inicial también se conocía como un protocolo "sin conexión".
Por ejemplo:
Suponga que su empresa compró una máquina de tarjeta de tiempo y la colocó en la recepción. Debido a que esta máquina es relativamente costosa, se hizo una cubierta protectora especial para cubrirla. La compañía requiere que abra la cubierta cada vez que registre su entrada y salida. fuera del trabajo Cierre la tapa.
Pero esta cubierta es muy fuerte y se necesita mucho esfuerzo para abrirla y cerrarla. Puede que solo tome 1 segundo perforar la tarjeta, pero toma de cuatro a cinco segundos abrir y cerrar la cubierta. La mayor parte del tiempo se desperdicia en la operación sin sentido de abrir y cerrar la tapa.
Es concebible que, por lo general, sea fácil decir que habrá una larga cola frente a la máquina de tarjetas de tiempo en el momento del viaje, y todos deben repetir los tres pasos de "abrir - perforar - cerrar la cubierta". Don No te preocupes si lo dices.
En esta metáfora, la máquina de la tarjeta de tiempo es equivalente al servidor, el interruptor de la tapa es la conexión y el cierre de TCP, y cada persona que perfora la tarjeta es una solicitud HTTP. Obviamente, la deficiencia de la conexión corta restringe seriamente la capacidad de servicio del servidor, por lo que no puede manejar más solicitudes.
Conexión larga
En respuesta a las deficiencias expuestas por las conexiones cortas, el protocolo HTTP propone un método de comunicación de "conexión larga", también llamado "conexiones persistentes", "mantener vivo" y "reutilización de conexiones". ).
De hecho, la solución también es muy simple, utilizando la idea de "costo compartido". Dado que la conexión y el cierre de TCP consumen mucho tiempo, entonces el costo de tiempo se asigna desde la "solicitud-respuesta" original a múltiples "solicitud-respuesta". "superior".
Aunque esto no puede mejorar la eficiencia de la conexión de TCP, según el "efecto del denominador", el tiempo inválido de cada "solicitud-respuesta" se reducirá mucho y también mejorará la eficiencia general de la transmisión.
Diagrama comparativo de conexión corta y conexión larga
Continuando con la analogía de la máquina de fichaje de hace un momento, la empresa también consideró que esta operación repetida de "abrir-fichar-cerrar" era demasiado "antihumana", por lo que se emitió una nueva regulación. Después de abrir la tapa por la mañana, no hay necesidad de cerrarlo.Pulsa y cierra la tapa cuando salgas del trabajo.
De esta forma, se ha mejorado mucho la eficiencia del fichaje (es decir, la capacidad de servicio), antes se tardaba cinco o seis segundos en fichar una vez, pero ahora solo se tarda un segundo. el trabajo se ha ido para siempre, y todo el mundo está feliz.
Campos de encabezado relacionados con la conexión
Dado que el efecto de mejora del rendimiento de la conexión larga es muy significativo, la conexión en HTTP/1.1 habilitará la conexión larga de forma predeterminada. No es necesario utilizar ningún campo de encabezado especial para especificar, siempre que la primera solicitud se envíe al servidor, las solicitudes posteriores reutilizarán la conexión TCP abierta por primera vez, es decir, una conexión larga, y enviarán y recibirán datos. en esta conexión.
Por supuesto, también podemos solicitar explícitamente el uso del mecanismo de conexión larga en el encabezado de la solicitud, el campo utilizado es Conexión y el valor es "mantener vivo".
Sin embargo, independientemente de si el cliente requiere explícitamente una conexión larga, si el servidor admite una conexión larga, siempre colocará un campo "Conexión: mantener vivo" en el mensaje de respuesta, diciéndole al cliente: "Soy compatible con la conexión larga, el siguiente use este TCP para enviar y recibir datos todo el tiempo".
Sin embargo, la conexión larga también tiene algunas pequeñas deficiencias, el problema radica en su palabra "larga".
Debido a que la conexión TCP no se cierra durante mucho tiempo, el servidor debe guardar su estado en la memoria, lo que consume recursos del servidor. Si hay una gran cantidad de conexiones largas inactivas que no se envían de forma continua, los recursos del servidor se agotarán rápidamente, lo que provocará que el servidor no pueda brindar servicios a los usuarios que realmente los necesitan.
Por lo tanto, la conexión larga también debe cerrarse en el momento adecuado, y la conexión con el servidor no se puede mantener para siempre, lo que se puede hacer en el cliente o en el servidor.
En el lado del cliente, puede agregar el campo "Conexión: cerrar" al encabezado de la solicitud para decirle al servidor: "Cierre la conexión después de esta comunicación". Cuando el servidor ve este campo, sabe que el cliente cerrará activamente la conexión, por lo que también agrega este campo al mensaje de respuesta y llama a la API de Socket para cerrar la conexión TCP después del envío.
El lado del servidor generalmente no cierra activamente la conexión, pero también se pueden usar algunas estrategias. Tome Nginx como ejemplo, tiene dos métodos:
1. Use el comando "keepalive_timeout" para establecer el período de tiempo de espera para conexiones largas. Si no se envían ni reciben datos en la conexión durante un período de tiempo, desconectará activamente el conexión para evitar que las conexiones inactivas ocupen recursos del sistema.
2. Use el comando "keepalive_requests" para establecer la cantidad máxima de solicitudes que se pueden enviar en una conexión larga. Por ejemplo, si se establece en 1000, cuando Nginx procese 1000 solicitudes en esta conexión, también se desconectará activamente.
Además, tanto el cliente como el servidor pueden agregar el campo de encabezado general "Keep-Alive: timeout=value" al mensaje para limitar el período de tiempo de espera de la conexión larga. Sin embargo, la fuerza vinculante de este campo no es fuerte y es posible que las dos partes de la comunicación no la cumplan, por lo que no es muy común.
bloqueo de cabeza de línea
Después de leer la conexión corta y la conexión larga, el siguiente paso es hablar del famoso "head-of-line blocking" (bloqueo de cabeza de línea, también llamado "head-of-line blocking").
El "bloqueo de cabecera de línea" no tiene nada que ver con conexiones cortas y largas, sino que es causado por el modelo básico de "solicitud-respuesta" de HTTP.
Debido a que HTTP estipula que los mensajes deben "enviarse y recibirse", esto forma una cola "en serie" de primero en entrar, primero en salir. Las solicitudes en la cola no tienen prioridad, solo el orden de ingreso a la cola, y la solicitud en la parte superior se procesa con la prioridad más alta.
Si la solicitud que encabeza la cola retrasa el tiempo porque se procesa con demasiada lentitud, entonces todas las solicitudes subsiguientes en la cola tienen que esperar juntas, y el resultado es que otras solicitudes soportan costos de tiempo indebidos.
O use una máquina de tarjetas perforadas como analogía. En el momento del trabajo, todos estaban haciendo cola para fichar, pero en este momento, la persona que estaba al frente encontró una falla en la máquina de la tarjeta del reloj y no pudo marcar con éxito sin importar qué, y estaba sudando profusamente. Cuando alguien arregla la máquina de tarjetas de tiempo, todos los que están detrás llegan tarde.
optimización del rendimiento
Debido a que el modelo de "solicitud-respuesta" no se puede cambiar, el problema del "bloqueo de cabecera de línea" no se puede resolver en HTTP/1.1, sino que solo se puede paliar. ¿Qué se puede hacer?
La empresa puede comprar unas cuantas máquinas más para marcar la entrada y colocarlas en la recepción, de modo que no sea necesario amontonar a todos en una fila y fichar por separado. No importa si una fila se bloquea de vez en cuando, y puede cambiar a otras líneas sin bloqueo.
Se trata de "conexiones simultáneas" en HTTP, es decir, iniciar múltiples conexiones largas a un nombre de dominio al mismo tiempo y usar la cantidad para resolver problemas de calidad.
Pero este enfoque también tiene fallas. Si cada cliente quiere ser rápido y establecer muchas conexiones, el número de usuarios × el número de conexiones simultáneas será un número astronómico. Los recursos del servidor no pueden soportarlo en absoluto, o se considera un ataque malicioso por parte del servidor, que en su lugar provocará una "denegación de servicio".
Por lo tanto, el protocolo HTTP recomienda que los clientes utilicen la simultaneidad, pero no "abusar" de la simultaneidad. RFC2616 limita claramente cada cliente a un máximo de 2 conexiones simultáneas. Sin embargo, la práctica ha demostrado que este número es demasiado pequeño y muchos navegadores "ignoraron" el estándar y elevaron el límite superior a 6~8. El RFC7230 revisado más tarde también "empujó el barco en el camino" y canceló la restricción "2".
La empresa se está desarrollando demasiado rápido, con más y más empleados, el fichaje de entrada y salida del trabajo se ha convertido en un problema inminente. El espacio en la recepción es limitado y no hay espacio para más máquinas de tarjetas de tiempo ¿Qué debo hacer? Luego, abra algunos lugares más para registrarse y coloque tres o cuatro máquinas de registro en cada piso y en la entrada del área de oficinas para desviar aún más a las personas, de modo que no vayan todos a la recepción.
Esta es la tecnología de "fragmentación de dominios", o la idea de usar la cantidad para resolver la calidad.
¿El protocolo HTTP y los navegadores no limitan el número de conexiones simultáneas? Bien, abriré algunos nombres de dominio más, como shard1.chrono.com, shard2.chrono.com, y todos estos nombres de dominio apuntan al mismo servidor www.chrono.com, de modo que la cantidad de conexiones largas reales aumentará de nuevo, realmente "Hermoso". Sin embargo, en realidad es un poco como "hay políticas en la parte superior y contramedidas en la parte inferior".
resumen
- El primer protocolo HTTP usaba una conexión corta y la cerraba inmediatamente después de recibir la respuesta, lo cual era muy ineficiente;
- HTTP/1.1 permite conexiones largas de forma predeterminada, enviando y recibiendo múltiples respuestas de solicitud en una conexión, mejorando la eficiencia de la transmisión;
- El servidor enviará el campo "Conexión: keep-alive" para indicar que la conexión larga está habilitada;
- Si hay "Conexión: cerrar" en el encabezado, significa que la conexión larga está a punto de cerrarse;
- Demasiadas conexiones largas ocuparán los recursos del servidor, por lo que el servidor utilizará algunas estrategias para cerrar conexiones largas de forma selectiva;
- El problema del "bloqueo de cabeza de línea" conducirá a una degradación del rendimiento, que puede aliviarse mediante tecnologías de "conexiones simultáneas" y "fragmentación de nombres de dominio".