prefacio
El protocolo HTTP es uno de los protocolos más importantes de Internet, aunque parezca sencillo, pero en la práctica a menudo se encuentra con problemas, y lo hemos encontrado varias veces. Hay conexiones largas y análisis de paquetes. No puedes saber nada sobre el protocolo HTTP, debes entenderlo a fondo. Así que escribí esta serie para compartir los problemas y experiencias del protocolo HTTP.
El protocolo HTTP tiene un encabezado y un cuerpo para los paquetes de solicitud y respuesta, y el cuerpo es el recurso que quieres obtener, como una página html, una imagen jpeg, y el encabezado se usa para hacer ciertas convenciones. Por ejemplo, el cliente y el servidor acuerdan algunos formatos de transmisión, y el cliente primero recibe la cabecera, conoce cierta información de formato y luego empieza a leer el cuerpo.
Cliente: Accept-Encoding:gzip (comprime para mí, estoy usando tráfico, descárgalo primero y luego descomprime poco a poco)
Servidor 1: Codificación de contenido: null (Sin encabezado de codificación de contenido.) No doy compresión, la CPU no es libre, ¿la quieres?)
Servidor 2: Codificación de contenido: gzip (guarda tráfico para ti, comprésalo) Cliente: Conexión: keep-alive (Hermano mayor, por fin hemos construido una conexión TCP, la usaremos la próxima vez)
Servidor 1: Conexión: mantener vivo (no es fácil, sigue usándolo)
Servidor 2: Conexión: cerrar (quien siga usándolo contigo, nuestro TCP es de una sola vez, y tendremos que reconectarnos la próxima vez que lo encontremos) El protocolo HTTP no tiene tres apretones de mano, y cuando un cliente solicita recursos al servidor, prevalecerá el lado del servidor. También hay algunos encabezados que no tienen un proceso de negociación, pero el servidor le dice directamente al cliente qué hacer. Por ejemplo, la longitud de contenido anterior es lo que el servidor le indica al cliente qué tamaño tiene el cuerpo. ¡Pero! El camarero puede no poder decirte exactamente qué tamaño tiene el cuerpo de antemano. El servidor tiene que escribir primero la cabecera y luego el cuerpo; si quieres escribir el cuerpo en la cabecera, tienes que conocer el tamaño del cuerpo de antemano. Si el cuerpo se genera dinámicamente, el servidor terminará y empezará a escribir el encabezado, lo que requiere mucho sobrecarga adicional, por lo que puede que no haya una longitud de contenido en el encabezado.
¿Cómo sabe el cliente el tamaño del cuerpo? El camarero te lo dice de tres maneras.
1. El servidor ya conoce el tamaño del recurso y te lo comunica a través del encabezado de contenido de longitud.
Content-Length:1076(body的大小是1076B,你读取1076B就可以完成任务了)
Transfer-Encoding: null
2. El servidor no puede conocer el tamaño del recurso de antemano, o no está dispuesto a gastar recursos para calcular el tamaño del recurso de antemano, por lo que añadirá un encabezado al mensaje de respuesta http llamado Transfer-Encoding:chunked, que significa transferencia de bloques. Cada bloque utiliza un formato fijo, con el tamaño del bloque delante, los datos detrás y el último bloque con un tamaño 0. De este modo, cuando el cliente analiza, debe prestar atención a eliminar algunos campos inútiles.
Content-Length:null
Transfer-Encoding:chunked (接下来的body我要一块一块的传,每一块开始是这一块的大小,等我传到大小为0的块时,就没了)
3. El servidor no conoce el tamaño del recurso y no soporta el modo de transmisión fragmentada, por lo que no existe ni la cabecera de longitud de contenido ni la cabecera de codificación de transferencia. En ese momento, la cabecera devuelto por el servidor debe estar cerca.
Content-Length:null
Transfer-Encoding:null
Connection:close(我不知道大小,我也用不了chunked,啥时候我关了tcp连接,就说明传输结束了)
|