La versione preliminare di nginx con supporto per QUIC e HTTP/3

Azienda NGINX ha annunciato sull'inizio dei test realizzazione dei protocolli QUIC e HTTP/3 nel server HTTP e proxy nginx. L'implementazione si basa su 27 bozza della specifica IETF-QUIC ed è disponibile attraverso un repository separato, derivato dalla versione 1.19.0. Il codice è distribuito sotto licenza BSD e non si sovrappone a quella proposta in precedenza implementazione di HTTP/3 per nginx da parte di Cloudflare, che è un progetto separato.

Il supporto di HTTP/3 in nginx è contrassegnato come sperimentale, poiché non tutte le funzionalità del protocollo sono implementate. Tuttavia, nginx può già essere utilizzato per inviare risposte a semplici richieste HTTP/3 su QUIC e per caricare/servire file di grandi dimensioni. Tra le funzionalità attualmente assenti del protocollo ci sono i meccanismi di negoziazione della versione del protocollo, ECN e controllo della congestione, log strutturati, modalità di recupero (QUIC recovery, gestione del flusso e congestione), NAT Rebinding, indirizzi mobili, Server push, allegato di dati (trailer). È inoltre offerto solo un supporto di base per la gestione dei pacchetti ACK e della gestione del flusso, che richiede miglioramenti. Non sono stati rispettati tutti i requisiti dello standard.

Per attivare HTTP/3 è necessario compilare nginx con il modulo http_v3_module e aggiungere una direttiva aggiuntiva
«listen» con il flag «http3» per creare un socket UDP in ascolto. Ad esempio:

server {
listen 443 ssl; # socket TCP per HTTP/1.1
listen 443 http3 reuseport; # socket UDP per QUIC+HTTP/3

ssl_protocols TLSv1.3; # in QUIC è obbligatorio TLS 1.3
ssl_certificate ssl/www.example.com.crt;
ssl_certificate_key ssl/www.example.com.key;

add_header Alt-Svc ‘quic=»:443’’; # indicatore di disponibilità di QUIC
add_header QUIC-Status $quic; # Intestazione con stato di utilizzo di QUIC
}

Ricordiamo che HTTP/3 standardizza l'uso del protocollo QUIC come trasporto per HTTP/2. Il protocollo QUIC (Quick UDP Internet Connections) è in sviluppo da parte di Google dal 2013 come alternativa al pacchetto TCP+TLS per il Web, risolvendo problemi di lungo tempo di instaurazione e negoziazione delle connessioni in TCP e alleviando ritardi in caso di perdita di pacchetti durante la trasmissione dei dati. QUIC è un'estensione del protocollo UDP, che supporta il multiplexing di più connessioni e fornisce metodi di crittografia equivalenti a quelli di TLS/SSL. Sul lato del software client, il supporto sperimentale per HTTP/3 è già stato aggiunto in Curl, Firefox e Chromium.

Principali di rendering tramite WebGL e Canvas, QUIC:

• Elevata sicurezza, simile a TLS (in sostanza QUIC offre la possibilità di utilizzare TLS 1.3 su UDP);
• Controllo dell'integrità del flusso, che previene la perdita di pacchetti;
• Possibilità di stabilire immediatamente una connessione (0-RTT, in circa il 75% dei casi i dati possono essere trasferiti subito dopo l'invio del pacchetto di apertura connessione) e garantire latenze minime tra l'invio della richiesta e la ricezione della risposta (RTT, Round Trip Time);
  
• Non utilizzo, durante la ritrasmissione, dello stesso numero di sequenza del pacchetto, il che consente di evitare ambiguità nella determinazione dei pacchetti ricevuti e di eliminare i timeout;
• La perdita di pacchetti influisce solo sulla consegna del flusso a essi associato e non interrompe la consegna dei dati nei flussi trasmessi parallelamente attraverso l'attuale connessione;
• Strumenti di correzione degli errori, che minimizzano i ritardi dovuti alla ritrasmissione dei 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 perso.
• I confini dei blocchi crittografici sono allineati con i confini dei pacchetti QUIC, riducendo l'impatto delle perdite di pacchetti sulla decodifica del contenuto dei pacchetti successivi;
• Assenza di problemi di blocco della coda TCP;
• Supporto per l'identificatore di connessione, che consente di ridurre i tempi per stabilire una nuova connessione per i clienti mobili;
• Possibilità di connettere meccanismi avanzati di controllo del sovraccarico della connessione;
• Utilizzo di tecniche di previsione della larghezza di banda in entrambe le direzioni per garantire un'intensità ottimale di invio dei pacchetti, evitando di scivolare in uno stato di sovraccarico, caratterizzato dalla perdita di pacchetti;
• Notevole incremento della performance e della capacità, rispetto a TCP. Per i servizi video, come YouTube, l'applicazione di QUIC ha mostrato una riduzione delle operazioni di ri-buffering durante la visione dei video del 30%.

Fonte: opennet.ru