Falando sobre o pacote de protocolo HTTP

Sabemos que o pacote http é principalmente dividido em três partes:

1. Solicitar linha

Os métodos de solicitação, GET e POST são os métodos HTTP mais comuns, além de DELETE, HEAD, OPTIONS, PUT, TRACE.
O endereço URL, que forma a URL de solicitação completa com o atributo Host do cabeçalho da mensagem.
Nome do contrato e número da versão.

2. O cabeçalho da solicitação (ouvinte)

Aceitar: especifique o tipo de conteúdo que o cliente pode receber, que pode ser texto, imagem ou tipo de vídeo.
Aceitar-Codificação: especifique o formato de dados compatível com o navegador, incluindo gzip, br, etc.
Accept-Language: executa a linguagem receptora, basicamente en, zh
Accept-Charset: especifica a codificação, geralmente utf-8
Comprimento do conteúdo: comprimento do conteúdo solicitado
Cookie: usado para armazenar algumas informações do usuário para que o servidor possa identificar a identidade do usuário (a maioria dos sites que precisam fazer o login serão mais comuns), por exemplo, um cookie irá armazenar o nome de usuário e a senha de alguns usuários, e quando o usuário fizer login, ele irá gerar um no cliente. Os cookies são usados para armazenar informações relevantes, de modo que o navegador irá determinar que você é um usuário legítimo após ler as informações do cookie para verificar no servidor e permitir que você visualize o página da web correspondente.
Host: especifique o nome de domínio e o número da porta do servidor solicitado
Origem: fonte do pedido
Referer: refere-se à solicitação de página da web específica da fonte da solicitação
User-Agent: informe ao servidor HTTP, o nome e a versão do sistema operacional e do navegador utilizado pelo cliente, e o conteúdo contém as informações do usuário que fez a solicitação.
Conexão: Indica o status da conexão.Geralmente, se você abre uma página, mas deseja transmitir dados, como reprodução de vídeo, etc., você deve manter a conexão tcp não fechada, então keep-alive (conexão longa) é usado. O fechamento de conexão curta foi usado antes.
Sec-Fetch-Dest: indica o destino da solicitação, ou seja, como utilizar os dados adquiridos;

Sec-Fetch-Mode:

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. Linha de resposta

Nome do contrato e número da versão

Código de status e descrição

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

4. Cabeçalho de resposta

Access-Control-Allow-Credentials: definido como verdadeiro, o que significa que o servidor permite claramente que o cookie seja incluído na solicitação e enviado ao servidor em conjunto. Indica se a credencial pode ser usada para fazer a solicitação real.
Access-Control-Expose-Headers:
Access-Control-Allow-Methods: Método de solicitação
Access-Control-Allow-Origin: Para solicitações que não exigem credenciais, o servidor usará "*" como curinga para permitir que todos os domínios tenham acesso aos recursos.
```
如需允许所有资源都可以访问您的资源，您可以如此设置：
Access-Control-Allow-Origin: *
如需允许https://developer.mozilla.org访问您的资源，您可以设置：
Access-Control-Allow-Origin: https://developer.mozilla.org
```
- Content-Length: o tamanho em bytes retornados
- Idade: O cabeçalho da mensagem contém o período de tempo que o objeto é armazenado no agente de cache
- Data hora
- Set-Cookie: define o cookie associado à página e envia as informações do cookie ao cliente novamente

Bolacha

Como o protocolo HTTP não tem estado, ou seja, o servidor não sabe o que o usuário fez da última vez, o que dificulta gravemente a implementação de aplicativos da Web interativos. Em um cenário típico de compra online, um usuário navega várias páginas e compra uma caixa de biscoitos e duas garrafas de bebidas. No final do checkout, devido à natureza sem estado do HTTP, o servidor não sabe o que o usuário comprou sem meios adicionais, então os cookies são um dos "meios extras" usados para contornar a falta de estado do HTTP. O servidor pode definir ou ler as informações contidas nos Cookies para manter o estado do usuário na conversa com o servidor.

Na cena de compras agora, quando o usuário compra o primeiro item, o servidor envia um cookie para o usuário enquanto envia a página da web para o usuário, gravando as informações desse item. Quando o usuário visitar outra página, o navegador enviará o Cookie para o servidor, para que o servidor saiba o que comprou antes. O usuário continua a comprar bebidas e o servidor adiciona novas informações do produto ao cookie original. No checkout, o servidor pode ler o cookie enviado.

Outra aplicação típica de cookies é ao fazer login em um site, o site muitas vezes pede ao usuário para inserir um nome de usuário e uma senha, e o usuário pode marcar "Efetuar login automaticamente na próxima vez". Se marcada, na próxima vez que o usuário visitar o mesmo site, o usuário descobrirá que efetuou login sem inserir o nome de usuário e a senha. Isso ocorre porque o servidor enviou um cookie contendo credenciais de login (uma forma criptografada de nome de usuário e senha) para o disco rígido do usuário durante o login anterior. Ao efetuar login pela segunda vez, se o cookie não tiver expirado, o navegador enviará o cookie e o servidor verificará as credenciais, para que o usuário possa efetuar o login sem inserir o nome de usuário e a senha.

sessão

Mas o problema é que também sabemos que muitos sites atuais têm funções complexas e envolvem muita interação de dados. Por exemplo, a função de carrinho de compras dos sites de comércio eletrônico tem uma grande quantidade de informações e uma estrutura complicada. Não pode ser transmitida através de um mecanismo de cookie simples. Mais informações, e você deve saber que o campo do cookie é armazenado no cabeçalho HTTP. Mesmo que ele possa transportar essas informações, ele consumirá muita largura de banda e recursos de rede.
A sessão pode trabalhar com cookies para resolver este problema. Por exemplo, um cookie armazena essa variável sessionID = xxxx, apenas passa esse cookie para o servidor e, em seguida, o servidor encontra a sessão correspondente por meio desse ID. Esta sessão é uma estrutura de dados em que armazena Com informações detalhadas como o carrinho de compras do usuário, o servidor pode utilizar as informações para retornar a página personalizada do usuário, resolvendo efetivamente o problema de rastreamento do usuário.
Uma sessão é uma estrutura de dados projetada pelo desenvolvedor do site, para que possa transportar vários dados. Desde que um ID de sessão exclusivo seja passado do cookie do cliente, o servidor pode encontrar a sessão correspondente e reconhecer o cliente.
Claro, como a sessão é armazenada no servidor, ela definitivamente consumirá os recursos do servidor, então a sessão geralmente tem um tempo de expiração. O servidor geralmente verifica e exclui a sessão expirada periodicamente. Se o usuário acessar o servidor novamente mais tarde, ele pode enfrentar um novo login. Aguarde algumas medidas e, em seguida, o servidor cria uma nova sessão e transmite o ID da sessão ao cliente na forma de um cookie.