Hablando del paquete de protocolo HTTP

Sabemos que el paquete http se divide principalmente en tres partes:

1. Línea de solicitud

Los métodos de solicitud, GET y POST son los métodos HTTP más comunes, además de DELETE, HEAD, OPTIONS, PUT, TRACE.
La dirección URL, que forma la URL de solicitud completa con el atributo Host del encabezado del mensaje.
Nombre del acuerdo y número de versión.

2. El encabezado de la solicitud (oyente)

Aceptar: especifique el tipo de contenido que puede recibir el cliente, que puede ser texto, imagen o video.
Aceptar codificación: especifique el formato de datos admitido por el navegador, incluidos gzip, br, etc.
Accept-Language: ejecuta el idioma de recepción, básicamente en, zh
Accept-Charset: especifique la codificación, generalmente utf-8
Longitud del contenido: longitud del contenido solicitado
Cookie: se utiliza para almacenar cierta información del usuario para que el servidor pueda identificar la identidad del usuario (la mayoría de los sitios web que necesitan iniciar sesión serán más comunes), por ejemplo, una cookie almacenará el nombre de usuario y la contraseña de algunos usuarios, y cuando el usuario inicia sesión, se generará una en el cliente.Las cookies se utilizan para almacenar información relevante, de modo que el navegador determinará que usted es un usuario legítimo después de leer la información de las cookies para verificar en el servidor, y le permitirán ver el página web correspondiente.
Host: especifique el nombre de dominio y el número de puerto del servidor solicitado
Origen: origen de la solicitud
Referer: se refiere a la solicitud de página web específica de la fuente de solicitud
User-Agent: Dígale al servidor HTTP, el nombre y la versión del sistema operativo y el navegador utilizado por el cliente, y el contenido contiene la información del usuario que realizó la solicitud.
Conexión: Indica el estado de la conexión. Generalmente, si abre una página, pero desea transmitir datos, como reproducir video, etc., debe mantener la conexión tcp abierta, por lo que se usa Keep-Alive (conexión larga). El cierre de conexión corto se usó antes.
Sec-Fetch-Dest: indica el destino de la solicitud, es decir, cómo utilizar los datos adquiridos;

Modo Sec-Fetch:

cors：跨域请求；XMLHttpRequest 或 Fetch 支持跨源请求。
no-cors：并不是代表请求不跨域，而是服务端不设置cors响应头，图片/脚本/样式表这些请求是容许跨域且不用设置跨域响应头的情况使用。
same-origin：同源请求， 表示不跨境，跟cors跟no-cors不一样，cors跟no-cors是要求服务端设置。
navigate：表示这是一个浏览器的页面切换请求(request)。 navigate请求仅在浏览器切换页面时创建，该请求应该返回HTML；
websocket：建立websocket连接；

Sec-Fetch-Site:

cross-site：跨域请求；
same-origin：发起和目标站点源完全一致；
same-site：有几种判定情况，详见说明；
none：如果用户直接触发页面导航，例如在浏览器地址栏中输入地址，点击书签跳转等，就会设置none；

3. Línea de respuesta

Nombre del acuerdo y número de versión

Código de estado y descripción

1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误
200 - 请求成功
301 - 资源（网页等）被永久转移到其它URL
404 - 请求的资源（网页等）不存在
500 - 内部服务器错误

4. Encabezado de respuesta

Access-Control-Allow-Credentials: establecido en verdadero, lo que significa que el servidor claramente permite que la cookie se incluya en la solicitud y se envíe al servidor en conjunto. Indica si la credencial se puede utilizar para realizar la solicitud real.
Access-Control-Expose-Headers:
Access-Control-Allow-Methods: método de solicitud
Access-Control-Allow-Origin: para las solicitudes que no requieren credenciales, el servidor utilizará "*" como comodín para permitir que todos los dominios tengan acceso a los recursos.
```
如需允许所有资源都可以访问您的资源，您可以如此设置：
Access-Control-Allow-Origin: *
如需允许https://developer.mozilla.org访问您的资源，您可以设置：
Access-Control-Allow-Origin: https://developer.mozilla.org
```
- Longitud del contenido: el tamaño en bytes devuelto
- Antigüedad: el encabezado del mensaje contiene la cantidad de tiempo que el objeto se almacena en el agente de caché
- Fecha y hora
- Set-Cookie: establezca la cookie asociada con la página y envíe la información de la cookie al cliente nuevamente

Galleta

Debido a que el protocolo HTTP no tiene estado, es decir, el servidor no sabe qué hizo el usuario la última vez, lo que dificulta gravemente la implementación de aplicaciones web interactivas. En un escenario típico de compras en línea, un usuario navega por varias páginas y compra una caja de galletas y dos botellas de bebidas. Al final del proceso de pago, debido a la naturaleza sin estado de HTTP, el servidor no sabe qué compró el usuario sin medios adicionales, por lo que las cookies son uno de los "medios adicionales" que se utilizan para eludir la falta de estado de HTTP. El servidor puede configurar o leer la información contenida en las Cookies para mantener el estado del usuario en la conversación con el servidor.

En la escena de compras en este momento, cuando el usuario compra el primer artículo, el servidor envía una cookie al usuario mientras envía la página web al usuario, registrando la información de ese artículo. Cuando el usuario visita otra página, el navegador enviará la Cookie al servidor, para que el servidor sepa qué compró antes. El usuario continúa comprando bebidas y el servidor agrega nueva información de producto a la cookie original. Al finalizar la compra, el servidor puede leer la cookie enviada.

Otra aplicación típica de las cookies es al iniciar sesión en un sitio web, el sitio web a menudo le pide al usuario que ingrese un nombre de usuario y una contraseña, y el usuario puede marcar "Iniciar sesión automáticamente la próxima vez". Si está marcado, la próxima vez que el usuario visite el mismo sitio web, el usuario encontrará que ha iniciado sesión sin ingresar el nombre de usuario y la contraseña. Esto se debe a que el servidor envió una cookie que contenía las credenciales de inicio de sesión (una forma cifrada de nombre de usuario y contraseña) al disco duro del usuario durante el inicio de sesión anterior. Al iniciar sesión por segunda vez, si la cookie no ha caducado, el navegador enviará la cookie y el servidor verificará las credenciales, para que el usuario pueda iniciar sesión sin ingresar el nombre de usuario y la contraseña.

sesión

Pero el problema es que también sabemos que muchos sitios web actuales tienen funciones complejas e involucran mucha interacción de datos. Por ejemplo, la función de carrito de compras de los sitios web de comercio electrónico tiene una gran cantidad de información y una estructura complicada. No se puede transmitir a través de un simple mecanismo de cookies. Más información, y debe saber que el campo de la cookie se almacena en el encabezado HTTP. Incluso si puede llevar esta información, consumirá mucho ancho de banda y consumirá recursos de la red.
La sesión puede trabajar con cookies para resolver este problema. Por ejemplo, una cookie almacena una variable sessionID = xxxx, solo pasa esta cookie al servidor, y luego el servidor encuentra la sesión correspondiente a través de esta ID. Esta sesión es una estructura de datos en que almacena Con información detallada, como el carrito de compras del usuario, el servidor puede utilizar la información para devolver la página web personalizada del usuario, resolviendo eficazmente el problema de seguimiento del usuario.
Una sesión es una estructura de datos diseñada por el desarrollador del sitio web, por lo que puede transportar varios datos. Siempre que se pase un ID de sesión único desde la cookie del cliente, el servidor puede encontrar la sesión correspondiente y reconocer al cliente.
Por supuesto, dado que la sesión se almacena en el servidor, definitivamente consumirá los recursos del servidor, por lo que la sesión generalmente tiene un tiempo de caducidad. El servidor generalmente verifica y elimina la sesión caducada periódicamente. Si el usuario vuelve a acceder al servidor más tarde, Es posible que se enfrente a un nuevo inicio de sesión. Espere las medidas, y luego el servidor crea una nueva sesión y transmite el ID de la sesión al cliente en forma de cookie.