Requisitos: A maioria dos sites atualmente usa principalmente os protocolos das versões Http/1.1 e Http/2.0; para sites que suportam apenas a versão do protocolo HTTP/2, usar o HttpClient para enviar requisições por padrão, isso gera System.Net.Http.Http.Http.HttpRequestException: Ocorreu um erro durante o envio da solicitação. ---> System.IO.IOException: Impossível ler dados da conexão de transporte: O software no seu host abortou uma conexão estabelecida. ---> System.Net.Sockets.SocketException (10053): O software do seu host aborta uma conexão estabelecida. at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, booleano forAsyncThrow).
Histórico do protocolo HTTP
Linha do tempo
HTTP/0.9
O obsoleto HTTP/0.9 foi a primeira versão do protocolo HTTP, nascido em 1989. É extremamente simples, permitindo que o cliente envie uma requisição GET e não suporta o cabeçalho da requisição. Como não há cabeçalho de protocolo, HTTP/0.9 só pode suportar um tipo de conteúdo - texto simples. O servidor só pode responder a strings em formato HTML, não em outros formatos. Quando o servidor termina de enviar, a conexão TCP é encerrada.
HTTP/0.9 apresenta uma típica apatridia, onde cada visita é processada independentemente e desconectada quando o processamento é concluído. Se a página solicitada não existir, nenhum código de erro é retornado.
HTTP/1
HTTP/1 é um termo coletivo para HTTP 1.0 e HTTP 1.1, que se refere às versões do protocolo HTTP que são 1.0 e 1.1, respectivamente.
O HTTP 1.0 foi a segunda versão do protocolo HTTP e ainda é amplamente adotado hoje. Ele fez uma série de melhorias e aprimoramentos baseados no HTTP/0.9, incluindo:
Mais formatos como imagens, vídeos e binários podem ser enviados além do texto
Além de e métodos de solicitação POST foram adicionados
Mudei o formato das requisições e respostas HTTP. Além da parte de dados, cada comunicação deve incluir um cabeçalho HTTP que descreva alguns metadados, ou seja, a informação do cabeçalho da requisição é adicionada
Foram adicionadas funções como código de status de resposta, suporte a múltiplos caracteres, autorização, cache e codificação de conteúdo
Embora ainda seja um protocolo sem estado, conexões longas podem ser suportadas adicionando o cabeçalho "Connection: keep-alive" à solicitação
HTTP 1.1
HTTP 1.1 é um protocolo padronizado, e HTTP 1.1 elimina muita ambiguidade e introduz várias melhorias.
peculiaridade
Processamento de cache, HTTP 1.1, introduz mais políticas de controle de cache, como etiqueta de entidade, If-Unmodified-Since, If-Match, If-None-Match, etc., e mais cabeçalhos de cache opcionais para controlar a política de cache.
A otimização de largura de banda e o uso de conexões de rede introduzem um intervalo no cabeçalho da requisição, que permite que apenas uma parte do recurso seja solicitada, ou seja, retornar o código de status 206, o que facilita para os desenvolvedores escolherem livremente usar ao máximo a largura de banda e os links, além de poder usar Range e Content-Range para criar uma função de retomada de ponto de interrupção.
Gerenciamento de notificações de erro, 24 novos códigos de status de erro foram adicionados no HTTP 1.1.
Adicionar o cabeçalho Host permite configurar diferentes nomes de domínio em servidores com o mesmo endereço IP.
Suporta conexões longas, HTTP 1.1 suporta conexões longas, múltiplas requisições e respostas HTTP podem ser transmitidas em uma conexão TCP, reduzindo o consumo e o atraso no estabelecimento e fechamento de conexões, e o Connection:keep-alive está ativado por padrão no HTTP 1.1, e navegadores gerais permitem que 6 links longos sejam estabelecidos ao mesmo tempo para o mesmo nome de domínio.
Adicionada tecnologia de pipeline para permitir que uma segunda solicitação seja enviada antes da primeira resposta ser totalmente enviada, a fim de melhorar o bloqueio de fila, mas a ordem das respostas ainda será retornada na ordem das solicitações.
Suporte ao segmentar a resposta, definindo a Transfer-Encoding: chunked for chunked response, permitindo que os dados da resposta sejam divididos em múltiplas partes, e o servidor pode liberar o buffer o mais rápido possível para obter uma velocidade de resposta mais rápida.
HTTP 2.0
O HTTP 2.0 tem melhor desempenho, e agora as páginas web estão se tornando cada vez mais complexas, e até evoluindo para aplicações únicas, a quantidade de reprodução de mídia, o tamanho dos scripts para melhorar a interação também aumentaram bastante, e mais dados são transmitidos por meio de requisições HTTP, então o HTTP 2.0 fez muitas otimizações para a eficiência da rede.
peculiaridade
Binary Frame Splitting, HTTP 2.0, é um protocolo binário, e não de texto, que divide todas as informações transmitidas em mensagens e quadros menores e os codifica em formato binário.
Multiplexando, requisições paralelas podem ser processadas no mesmo link, todos os acessos sob o mesmo nome de domínio vêm da mesma conexão TCP, as mensagens HTTP são divididas em quadros independentes, e o servidor remonta as mensagens de acordo com identificadores e cabeçalhos, removendo a ordem e bloqueando restrições no HTTP 1.1.
Comprimir cabeçalhos, que frequentemente são semelhantes em uma série de requisições, elimina o custo de duplicação e transmissão de dados duplicados.
No push do lado do servidor, o servidor pode enviar recursos proativamente para o cliente sem solicitação explícita do cliente.
HTTP 3.0
O HTTP 3.0 está atualmente em fase de formulação e testes, é um novo protocolo HTTP no futuro, o protocolo HTTP 3.0 roda sobre o protocolo QUIC, é baseado em UDP para alcançar transmissão confiável, compensação entre velocidade de transmissão e confiabilidade da transmissão e otimização, usando UDP para evitar problemas de bloqueio de fila TCP e acelerar a velocidade de transmissão da rede, mas também é necessário alcançar um mecanismo de transmissão confiável, HTTP 3.0 não é uma extensão do HTTP 2.0, HTTP O 3.0 será um protocolo completamente novo.
HttpClientHandler VS SocketsHttpHandler
O manipulador de mensagens padrão usado pelo HttpClient no .NET Framework e no .NET Core 2.0 e versões anteriores é o HttpClientHandler.
Começando com o .NET Core 2.1, as aulasO SocketsHttpHandler fornece uma classe de rede HTTP de nível superior(ex.: HttpClient). O uso do SocketsHttpHandler oferece muitas vantagens:
O desempenho melhorou significativamente em comparação com implementações anteriores.
Elimine dependências de plataforma para simplificar a implantação e o serviço. Por exemplo, o libcurl não depende mais do .NET Core para macOS e do .NET Core para Linux.
Comportamento consistente em todas as plataformas .NET.
No .NET 9, o HttpClientFactory usa o SocketsHttpHandler como o principal handler
O HttpClientFactory permite configurar pipelines HttpClient para objetos HttpMessageHandler nomeados e digitados. O manipulador mais interno, ou o manipulador que realmente envia requisições na rede, é chamado de manipulador mestre. Se não configurado, esse handler sempre foi um HttpClientHandler antes. Embora o handler mestre padrão seja o detalhe da implementação, há usuários que dependem dele. Por exemplo, alguns usuários conjuram o handler principal para as propriedades da configuração HttpClientHandler, como ClientCertificates, UseCookies e UseProxy.
Link:O login do hiperlink está visível.
A configuração global solicita a versão do protocolo HTTP
O código é o seguinte:
DefaultRequestVersionA configuração padrão é HttpVersion.Version11。
A propriedade DefaultRequestVersion especifica a versão HTTP padrão a ser usada para requisições enviadas usando essa instância do HttpClient, quando ela constrói a HttpRequestMessage a ser enviada, especificamente chamando 、、、GetStreamAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync e PutAsync.
Propriedade DefaultRequestVersionNão se aplica ao método SendAsync。 O parâmetro HttpRequestMessage passado para o método SendAsync como parâmetro possui sua própria propriedade Version que controla a versão HTTP usada para a solicitação.
Link:O login do hiperlink está visível.
Política de negociação HttpVersionPolicy
RequestVersionOrLower: Use a versão solicitada, ou faça downgrade para uma versão inferior (mas não superior à versão solicitada). Esse é o comportamento padrão. Em termos simples, a versão do protocolo mais usada é a atual, e se a versão atual não for suportada, ela será rebaixada.
SolicitarVersãoOuSuperior: Use a versão mais alta suportada pelo servidor, mas não inferior à versão solicitada. Ou seja, upgrades são permitidos, e downgrade abaixo da versão solicitada não são permitidos. Em termos simples, use protocolos de versão superior para comunicação sempre que possível.
RequestVersionExact: Use estritamente a versão solicitada, não são permitidos upgrades ou downgrades.
O HttpClient utiliza o protocolo de versão Http/2.0
O código do teste é o seguinte:
A solicitação usa a versão 1.1, e o cliente final e o servidor negociam para usar o protocolo 2.0 para se comunicar, então a resposta final é a versão 2.0, como mostrado na figura abaixo:
Referência:
O login do hiperlink está visível.
O login do hiperlink está visível.
O login do hiperlink está visível. |
Postado em 2025-8-31 21:16:47
|
|
|
|
Senhorio|
Postado em 2025-8-31 21:46:27
|
