Compañía Cloudflare para proporcionar soporte para o protocolo HTTP/3 en NGINX. O módulo está deseñado como un complemento para a biblioteca desenvolvida por Cloudflare coa implantación do protocolo de transporte QUIC e HTTP/3. O código quiche está escrito en Rust, pero o propio módulo NGINX está escrito en C e accede á biblioteca mediante ligazóns dinámicas. Desenvolvementos baixo a licenza BSD.
Para montar, só tes que descargar a nginx 1.16 e quiche, despois reconstruír nginx coas opcións “—with-http_v3_module —with-quiche=../quiche”. Ao crear, a compatibilidade con TLS debería basearse na biblioteca BoringSSL ("--with-openssl=../quiche/deps/boringssl"), o uso de OpenSSL aínda non é compatible. Para aceptar conexións, cómpre engadir a directiva listen coa marca "quic" á configuración (por exemplo, "listen 443 quic reuseport").
No software do cliente, xa se engadiu compatibilidade con HTTP/3 ás versións experimentais de Chrome Canary e á utilidade curl. No lado do servidor, ata agora era necesario utilizar separado, limitado . A capacidade de procesar HTTP/3 en nginx simplificará significativamente a implantación de servidores con soporte HTTP/3 e fará que a implementación de proba do novo protocolo sexa máis accesible. A aparición do soporte estándar para HTTP/3 en nginx na rama 1.17.x durante 6-12 meses.
Lembre que HTTP/3 estandariza o uso do protocolo QUIC como transporte para HTTP/2. Protocolo (Quick UDP Internet Connections) foi desenvolvida por Google desde 2013 como unha alternativa á combinación TCP+TLS para a Web, resolvendo problemas con longos tempos de configuración e negociación para conexións en TCP e eliminando os atrasos cando se perden paquetes durante a transferencia de datos. QUIC é unha extensión do protocolo UDP que admite a multiplexación de varias conexións e proporciona métodos de cifrado equivalentes a TLS/SSL.
O principal RÁPIDO:
- Alta seguridade semellante a TLS (esencialmente QUIC ofrece a posibilidade de usar TLS sobre UDP);
- Control de integridade do fluxo, evitando a perda de paquetes;
- A capacidade de establecer unha conexión instantáneamente (0-RTT, en aproximadamente o 75% dos casos os datos pódense transmitir inmediatamente despois de enviar o paquete de configuración da conexión) e proporcionar atrasos mínimos entre o envío dunha solicitude e a recepción dunha resposta (RTT, Tempo de ida e volta);
- Non utilizar o mesmo número de secuencia ao retransmitir un paquete, o que evita a ambigüidade na identificación dos paquetes recibidos e elimina os tempos de espera;
- A perda dun paquete afecta só á entrega do fluxo asociado a el e non detén a entrega de datos en fluxos paralelos transmitidos a través da conexión actual;
- Funcións de corrección de erros que minimizan os atrasos debidos á retransmisión de paquetes perdidos. Uso de códigos especiais de corrección de erros a nivel de paquetes para reducir as situacións que requiren a retransmisión de paquetes de datos perdidos.
- Os límites dos bloques criptográficos están aliñados cos límites dos paquetes QUIC, o que reduce o impacto das perdas de paquetes na decodificación do contido dos paquetes posteriores;
- Non hai problemas co bloqueo da fila TCP;
- Soporte para o identificador de conexión, que reduce o tempo necesario para establecer unha reconexión para os clientes móbiles;
- Posibilidade de conectar mecanismos avanzados de control de conxestión da conexión;
- Utiliza técnicas de previsión de rendemento por dirección para garantir que os paquetes se envían a velocidades óptimas, evitando que se conxestionen e causen a perda de paquetes;
- Perceptible rendemento e rendemento en comparación co TCP. Para servizos de vídeo como YouTube, demostrouse que QUIC reduce nun 30 % as operacións de rebuffer ao ver vídeos.
Fonte: opennet.ru