{"id":81847,"date":"2020-05-17T01:42:34","date_gmt":"2020-05-16T23:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic"},"modified":"2020-05-17T01:42:34","modified_gmt":"2020-05-16T23:42:34","slug":"http-po-udp-ispolzuem-s-polzoj-protokol-quic","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic","title":{"rendered":"HTTP su UDP \u2014 utilizziamo il protocollo QUIC con saggezza","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"HTTP
\n
\nQUIC (Quick UDP Internet Connections) \u00e8 un protocollo basato su UDP che supporta tutte le funzionalit\u00e0 di TCP, TLS e HTTP\/2, risolvendo la maggior parte dei loro problemi. Spesso viene definito un protocollo nuovo o \"sperimentale\", ma \u00e8 in fase di sviluppo da oltre 7 anni. Sebbene non sia ancora diventato uno standard, ha gi\u00e0 guadagnato una vasta diffusione. Ad esempio, QUIC viene utilizzato per velocizzare il traffico e ridurre la latenza nelle reti mobili da giganti come Google e Facebook, e l'IETF ha dichiarato il suo fork come base per lo standard HTTP\/3 (mentre HTTP\/2 \u00e8 usato solo sul 44.8%<\/a><\/noindex> dei siti web).<\/a><\/noindex><\/p>\n

Concetto<\/h2>\n

\nQUIC \u00e8 stato sviluppato come sostituto del obsoleto TCP, originariamente progettato per reti cablate con basse percentuali di perdita. TCP consegna i pacchetti in ordine, quindi, in caso di perdita di un pacchetto, l'intera coda si ferma (head-of-line blocking<\/a><\/noindex>), il che influisce negativamente sulla qualit\u00e0 e stabilit\u00e0 della connessione. Per evitare perdite massicce, le reti cellulari ricorrono all'uso di buffer grandi, il che porta a ridondanza e false reazioni negative del protocollo (bufferbloat<\/a><\/noindex>). Inoltre, TCP impiega molto tempo per stabilire una connessione: le richieste SYN\/ACK e TLS sono separate, richiedendo tre roundtrip anzich\u00e9 uno, come fa QUIC.<\/p>\n

\"HTTP
\n
\nPoich\u00e9 QUIC combina la sostituzione di TCP con l'implementazione di TLS 1.3, tutte le connessioni sono sempre crittografate; decifrare questo traffico non \u00e8 pi\u00f9 semplice che se viaggiasse su HTTPS. Inoltre, QUIC \u00e8 implementato a livello applicativo, poich\u00e9 una sostituzione totale dello stack TCP richiederebbe un'eternit\u00e0<\/i>.<\/p>\n

Nonostante il supporto al multiplexing in HTTP\/2, il problema del blocco head-of-line rimane a causa della necessit\u00e0 di consegnare i pacchetti in ordine. QUIC \u00e8 implementato sopra UDP, quindi non ha blocchi in linea di principio. Per garantire che i pacchetti non vengano persi irrimediabilmente, vengono numerati e possono contenere parti di \"vicini\", fornendo ridondanza. Inoltre, QUIC divide la coda monolitica in pi\u00f9 flussi per diversi tipi di richieste all'interno di una singola connessione. In questo modo, in caso di perdita di un pacchetto, i problemi possono sorgere solo in una coda (ad esempio, per la trasmissione di un file specifico):<\/p>\n

\"HTTP
\n<\/p>\n

L'utilizzo di <\/h2>\n

\nOriginariamente, QUIC \u00e8 stato sviluppato all'interno di Google ed era in gran parte progettato per l'uso interno dell'azienda. Nel 2013, \u00e8 stato trasferito all'IETF per la standardizzazione (che \u00e8 ancora in corso), e ora chiunque pu\u00f2 partecipare allo sviluppo del protocollo, proponendo ci\u00f2 di cui ha bisogno. Il gruppo di lavoro dell'IETF organizza annualmente incontri in cui viene approvato il nuovo standard e si discute delle innovazioni. Questa implementazione di QUIC \u00e8 considerata principale e sulla sua base viene certificato lo standard HTTP\/3.<\/p>\n

Per ora non si parla di includere HTTP\/3 come protocollo principale, poich\u00e9 non \u00e8 ancora completo e quasi non \u00e8 supportato:<\/p>\n

\"HTTP
\n
\nTuttavia, QUIC pu\u00f2 essere implementato come mezzo di trasporto tra l'applicazione e il server, come fatto con successo da Uber:<\/p>\n

\n

Commento di Uber sull'implementazione di QUIC<\/i><\/h3>\n

\nPer integrare con successo QUIC e migliorare le prestazioni dell'applicazione in condizioni di connessione scadente, abbiamo sostituito il vecchio stack (HTTP\/2 sopra TLS\/TCP) con il protocollo QUIC. Abbiamo utilizzato la libreria di rete Cronet<\/a><\/noindex> di Chromium Projects<\/a><\/noindex>, che contiene la versione originale del protocollo Google \u2013 gQUIC. Questa implementazione \u00e8 costantemente migliorata per seguire l'ultima specifica IETF.<\/p>\n

Inizialmente, abbiamo integrato Cronet nelle nostre applicazioni Android per aggiungere il supporto per QUIC. L'integrazione \u00e8 stata effettuata in modo da ridurre al minimo i costi di migrazione. Invece di sostituire completamente lo stack di rete esistente che utilizzava la libreria OkHttp<\/a><\/noindex>, abbiamo integrato Cronet SOTTO il framework OkHttp API. Effettuando l'integrazione in questo modo, abbiamo evitato modifiche alle nostre chiamate di rete (utilizzate da Retrofit<\/a><\/noindex>) a livello API.<\/p>\n

Analogamente all'approccio per i dispositivi Android, abbiamo implementato Cronet nelle applicazioni Uber per iOS, intercettando il traffico HTTP dalle reti API<\/a><\/noindex>, utilizzando NSURLProtocol<\/a><\/noindex>. Questa astrazione, fornita da iOS Foundation, gestisce i dati URL specifici del protocollo e garantisce che possiamo integrare Cronet nelle nostre applicazioni iOS senza costi di migrazione significativi.<\/p><\/blockquote>\n

preso da questa traduzione<\/a><\/noindex> articolo di Uber<\/i><\/p>\n

Sul backend, catturavano le connessioni QUIC attraverso il Google Cloud lb, che supporta il protocollo<\/a><\/noindex> sin dal 2018.<\/p>\n

Non sorprende che Google Cloud funzioni perfettamente con un protocollo sviluppato da Google, ma quali sono le alternative?<\/p>\n

Nginx<\/h3>\n

\nNon molto tempo fa, CloudFlare ha provato a incrociare<\/a><\/noindex> nginx (che di default non supporta HTTP\/3) con il suo strumento Quiche. L'implementazione \u00e8 disponibile come un singolo file .patch, corredato da un tutorial all'installazione:<\/p>\n

curl -O https:\/\/nginx.org\/download\/nginx-1.16.1.tar.gz\ntar xvzf nginx-1.16.1.tar.gz\ngit clone --recursive https:\/\/github.com\/cloudflare\/quiche\ncd nginx-1.16.1\npatch -p01 < ..\/quiche\/extras\/nginx\/nginx-1.16.patch<\/code><\/pre>\n
\nQui puoi connettere i tuoi moduli se necessario<\/p>\n
.\/configure                          \t\n   \t--prefix=$PWD                       \t\n   \t--with-http_ssl_module              \t\n   \t--with-http_v2_module               \t\n   \t--with-http_v3_module               \t\n   \t--with-openssl=..\/quiche\/deps\/boringssl \n   \t--with-quiche=..\/quiche\n make<\/code><\/pre>\n
\nRimane solo da abilitare il supporto per HTTP\/3<\/p>\n
events {\n    worker_connections  1024;\n}\n\nhttp {\n    server {\n        # Abilita QUIC e HTTP\/3.\n        listen 443 quic reuseport;\n\n        # Abilita HTTP\/2 (opzionale).\n        listen 443 ssl http2;\n\n        ssl_certificate      cert.crt;\n        ssl_certificate_key  cert.key;\n\n        # Abilita tutte le versioni TLS (TLSv1.3 \u00e8 richiesta per QUIC).\n        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;\n\n        # La richiesta di buffering non \u00e8 attualmente supportata per HTTP\/3.\n        proxy_request_buffering off;\n\n        # Aggiungi intestazione Alt-Svc per negoziare HTTP\/3.\n        add_header alt-svc 'h3-27=":443"; ma=86400';\n    }\n}<\/code><\/pre>\n
\nNei browser normali, non sar\u00e0 possibile connettersi tramite HTTP\/3, ma puoi prendere Chrome Canary<\/a><\/noindex> e avviare con il flag --enable-quic<\/code>, accedi al tuo server o, ad esempio, al sito quic.rocks e controlla il tipo di connessione negli Strumenti per sviluppatori:
\n\"HTTP
\nAl posto di HTTP\/3 viene indicato http2+quic\/99<\/code>, ma in sostanza \u00e8 la stessa cosa.<\/p>\n
Alte tecnologie<\/h3>\n
<\/p>\n