Empresa Cloudflare para fornecer suporte para o protocolo HTTP/3 no NGINX. O módulo foi desenvolvido como um complemento à biblioteca desenvolvida pela Cloudflare com a implementação do protocolo de transporte QUIC e HTTP/3. O código quiche é escrito em Rust, mas o próprio módulo NGINX é escrito em C e acessa a biblioteca usando vinculação dinâmica. Desenvolvimentos sob a licença BSD.
Para montar basta baixar para nginx 1.16 e bibliotecas quiche e, em seguida, reconstrua o nginx com as opções “—with-http_v3_module —with-quiche=../quiche”. Ao construir, o suporte TLS deve ser baseado na biblioteca BoringSSL (“--with-openssl=../quiche/deps/boringssl”), o uso de OpenSSL ainda não é suportado. Para aceitar conexões, você precisa adicionar a diretiva listen com o sinalizador “quic” às configurações (por exemplo, “listen 443 quic reuseport”).
No software cliente, o suporte HTTP/3 já foi adicionado às compilações experimentais do Chrome Canary e ao utilitário curl. Do lado do servidor, até agora era necessário usar recursos separados e limitados . A capacidade de processar HTTP/3 no nginx simplificará significativamente a implantação de servidores com suporte HTTP/3 e tornará a implementação de teste do novo protocolo mais acessível. O surgimento do suporte padrão para HTTP/3 no nginx na filial 1.17.x por 6 a 12 meses.
Lembre-se de que HTTP/3 padroniza o uso do protocolo QUIC como transporte para HTTP/2. Protocolo (Quick UDP Internet Connections) é desenvolvido pelo Google desde 2013 como uma alternativa à combinação TCP+TLS para a Web, resolvendo problemas com longos tempos de configuração e negociação de conexões em TCP e eliminando atrasos quando pacotes são perdidos durante a transferência de dados. QUIC é uma extensão do protocolo UDP que suporta multiplexação de múltiplas conexões e fornece métodos de criptografia equivalentes a TLS/SSL.
O principal RÁPIDO:
- Alta segurança, semelhante ao TLS (na verdade, o QUIC fornece a capacidade de usar TLS sobre UDP);
- Controle de integridade de fluxo para evitar perda de pacotes;
- A capacidade de estabelecer instantaneamente uma conexão (0-RTT, em cerca de 75% dos casos, os dados podem ser transmitidos imediatamente após o envio de um pacote de configuração de conexão) e garantir atrasos mínimos entre o envio de uma solicitação e o recebimento de uma resposta (RTT, Round Trip Time) ;
- Não use o mesmo número de sequência ao retransmitir um pacote, o que permite evitar ambigüidades na determinação dos pacotes recebidos e eliminar os tempos limite;
- A perda de pacotes afeta apenas a entrega do stream associado a ele e não interrompe a entrega de dados em streams transmitidos em paralelo na conexão atual;
- Ferramentas de correção de erros que minimizam atrasos devido à retransmissão de pacotes perdidos. Uso de códigos especiais de correção de erros no nível do pacote para reduzir situações que requerem retransmissão de dados perdidos do pacote.
- Os limites dos blocos criptográficos estão alinhados com os limites dos pacotes QUIC, o que reduz o impacto das perdas de pacotes na decodificação do conteúdo dos pacotes subsequentes;
- Sem problemas com o bloqueio da fila TCP;
- Suporte de ID de conexão para reduzir o tempo de reconexão para clientes móveis;
- Possibilidade de conectar mecanismos avançados para controle de sobrecarga de conexão;
- Utilizar técnicas de previsão de largura de banda em cada direção para garantir a intensidade ótima de envio de pacotes, evitando rolar para um estado de congestionamento, no qual há perda de pacotes;
- Perceptível desempenho e taxa de transferência em comparação com o TCP. Para serviços de vídeo como o YouTube, o QUIC demonstrou reduzir as operações de rebuffering de vídeo em 30%.
Fonte: opennet.ru