Azienda Cloudflare per fornire supporto per il protocollo HTTP/3 in NGINX. Il modulo è progettato come componente aggiuntivo della libreria sviluppata da Cloudflare con l'implementazione del protocollo di trasporto QUIC e HTTP/3. Il codice quiche è scritto in Rust, ma il modulo NGINX stesso è scritto in C e accede alla libreria utilizzando il collegamento dinamico. Sviluppi sotto licenza BSD.
Per assemblarlo, basta scaricare a nginx 1.16 e librerie quiche, quindi ricostruire nginx con le opzioni “—with-http_v3_module —with-quiche=../quiche”. Durante la creazione, il supporto TLS dovrebbe essere basato sulla libreria BoringSSL (“--with-openssl=../quiche/deps/boringssl”), l'uso di OpenSSL non è ancora supportato. Per accettare le connessioni è necessario aggiungere alle impostazioni la direttiva listen con il flag “quic” (ad esempio “listen 443 quic reuseport”).
Nel software client, il supporto HTTP/3 è già stato aggiunto alle build sperimentali di Chrome Canary e all'utilità curl. Lato server, fino ad ora era necessario un utilizzo separato, limitato . La capacità di elaborare HTTP/3 in nginx semplificherà notevolmente l’implementazione dei server con supporto HTTP/3 e renderà più accessibile l’implementazione dei test del nuovo protocollo. L'emergere del supporto standard per HTTP/3 in nginx nel ramo 1.17.x per 6-12 mesi.
Ricordiamo che HTTP/3 standardizza l'uso del protocollo QUIC come trasporto per HTTP/2. Protocollo (Quick UDP Internet Connections) è stato sviluppato da Google dal 2013 come alternativa alla combinazione TCP+TLS per il Web, risolvendo problemi legati ai lunghi tempi di setup e negoziazione delle connessioni in TCP ed eliminando i ritardi dovuti alla perdita di pacchetti durante il trasferimento dei dati. QUIC è un'estensione del protocollo UDP che supporta il multiplexing di connessioni multiple e fornisce metodi di crittografia equivalenti a TLS/SSL.
Il principale VELOCE:
- Sicurezza elevata simile a TLS (sostanzialmente QUIC offre la possibilità di utilizzare TLS su UDP);
- Controllo dell'integrità del flusso, prevenendo la perdita di pacchetti;
- La capacità di stabilire istantaneamente una connessione (0-RTT, in circa il 75% dei casi i dati possono essere trasmessi immediatamente dopo l'invio del pacchetto di configurazione della connessione) e di garantire ritardi minimi tra l'invio di una richiesta e la ricezione di una risposta (RTT, Round Trip Time);
- Non utilizzare lo stesso numero di sequenza durante la ritrasmissione di un pacchetto, il che evita ambiguità nell'identificazione dei pacchetti ricevuti ed elimina i timeout;
- La perdita di un pacchetto influisce solo sulla consegna del flusso ad esso associato e non interrompe la consegna dei dati nei flussi paralleli trasmessi attraverso la connessione corrente;
- Funzionalità di correzione degli errori che riducono al minimo i ritardi dovuti alla ritrasmissione di pacchetti persi. Utilizzo di codici speciali di correzione degli errori a livello di pacchetto per ridurre le situazioni che richiedono la ritrasmissione dei dati del pacchetto persi.
- I confini dei blocchi crittografici sono allineati ai confini dei pacchetti QUIC, il che riduce l'impatto delle perdite di pacchetti sulla decodifica del contenuto dei pacchetti successivi;
- Nessun problema con il blocco della coda TCP;
- Supporto per l'identificatore di connessione, che riduce il tempo necessario per stabilire una riconnessione per i client mobili;
- Possibilità di collegare meccanismi avanzati di controllo della congestione delle connessioni;
- Utilizza tecniche di previsione del throughput per direzione per garantire che i pacchetti vengano inviati a velocità ottimali, evitando che si congestionino e causino la perdita di pacchetti;
- Percettibile prestazioni e throughput rispetto a TCP. Per i servizi video come YouTube, è stato dimostrato che QUIC riduce le operazioni di rebuffering durante la visione di video del 30%.
Fonte: opennet.ru