{"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 utilmente il protocollo QUIC","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"HTTP
\n
\nQUIC (Quick UDP Internet Connections) \u00e8 un protocollo sopra UDP che supporta tutte le funzionalit\u00e0 di TCP, TLS e HTTP\/2, risolvendo la maggior parte dei loro problemi. \u00c8 spesso definito un protocollo nuovo o \"sperimentale\", ma \u00e8 gi\u00e0 da tempo al di l\u00e0 della fase di esperimento: lo sviluppo \u00e8 in corso da oltre 7 anni. Durante questo periodo, il protocollo non \u00e8 ancora diventato uno standard, ma ha comunque ottenuto una diffusione significativa. Ad esempio, QUIC \u00e8 utilizzato per accelerare il traffico e ridurre la latenza nelle reti mobili da giganti come Google e Facebook, mentre l'IETF ha dichiarato il suo fork del protocollo come base per lo standard HTTP\/3 (considerando che HTTP\/2 utilizza solo il 44.8%<\/a><\/noindex> dei siti).<\/a><\/noindex><\/p>\n

Concetto<\/h2>\n

\nQUIC \u00e8 stato sviluppato come sostituto del TCP obsoleto, che era originariamente progettato per reti cablate con una bassa percentuale di perdite. TCP consegna i pacchetti in ordine; pertanto, in caso di perdita di un pacchetto, l'intera coda si arresta (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 ampi buffer, il che porta a ridondanza e false reazioni negative del protocollo (bufferbloat<\/a><\/noindex>). Inoltre, il TCP richiede molto tempo per stabilire una connessione: le richieste SYN\/ACK e TLS vanno separate, richiedendo tre roundtrip invece di uno, come fa QUIC.<\/p>\n

\"HTTP
\n
\nPoich\u00e9 QUIC combina una sostituzione del TCP e l'implementazione di TLS 1.3, tutte le connessioni sono sempre crittografate, e decifrare tale traffico non \u00e8 pi\u00f9 semplice di quanto non lo sia se passasse attraverso HTTPS. Inoltre, QUIC \u00e8 implementato a livello applicativo, poich\u00e9 una sostituzione completa dello stack TCP richiederebbe un'eternit\u00e0.<\/i>.<\/p>\n

Nonostante il supporto per il multiplexing in HTTP\/2, il problema dell'head-of-line blocking \u00e8 rimasto a causa della necessit\u00e0 di consegnare i pacchetti in ordine. QUIC, essendo implementato su UDP, non ha mai questi blocchi e, affinch\u00e9 i pacchetti non vengano persi definitivamente, vengono numerati e possono contenere parti di \"vicini\", garantendo la ridondanza. Inoltre, QUIC suddivide 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

Utilizzo <\/h2>\n

\nInizialmente QUIC \u00e8 stato sviluppato all'interno di Google ed era in gran parte adattato 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, suggerendo ci\u00f2 che manca per le proprie esigenze. Il gruppo di lavoro dell'IETF organizza annualmente incontri in cui vengono approvati nuovi standard e si discute di novit\u00e0. Questa implementazione di QUIC \u00e8 considerata quella principale ed \u00e8 proprio su di essa che 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 concluso e quasi non \u00e8 supportato:<\/p>\n

\"HTTP
\n
\nTuttavia, QUIC pu\u00f2 essere implementato come trasporto tra applicazione e server, cosa che \u00e8 stata gi\u00e0 realizzata con successo in Uber:<\/p>\n

\n

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

\nPer integrare con successo QUIC e migliorare le prestazioni dell'app in condizioni di scarsa connettivit\u00e0, abbiamo sostituito il vecchio stack (HTTP\/2 sopra TLS\/TCP) con il protocollo QUIC. Abbiamo utilizzato la libreria di rete Cronet<\/a><\/noindex> da Progetti Chromium<\/a><\/noindex>, che contiene la versione originale e di Google del protocollo \u2013 gQUIC. Questa implementazione \u00e8 inoltre costantemente migliorata per seguire le ultime specifiche dell'IETF.<\/p>\n

Per prima cosa abbiamo integrato Cronet nelle nostre applicazioni Android per aggiungere supporto a QUIC. L'integrazione \u00e8 stata realizzata in modo da ridurre al minimo i costi di migrazione. Invece di sostituire completamente il vecchio stack di rete, che utilizzava la libreria OkHttp<\/a><\/noindex>, abbiamo integrato Cronet ALL'INTERNO del framework OkHttp API. Rendendo l'integrazione in questo modo, abbiamo evitato modifiche alle nostre chiamate di rete (che utilizzano Retrofit<\/a><\/noindex>) a livello di API.<\/p>\n

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

tratto da questa traduzione<\/a><\/noindex> dell'articolo Uber<\/i><\/p>\n

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

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

Nginx<\/h3>\n

\nNon molto tempo fa, CloudFlare ha provato a ibridare<\/a><\/noindex> nginx (che di default non supporta HTTP\/3) con il suo strumento Quiche. L'implementazione \u00e8 disponibile come unico file .patch, a cui \u00e8 allegato un tutorial per l'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 collegare 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 l'intestazione Alt-Svc per negoziare HTTP\/3.\n        add_header alt-svc 'h3-27=\"443\"; ma=86400';\n    }\n}<\/code><\/pre>\n
\nNei normali browser non \u00e8 possibile connettersi tramite HTTP\/3, ma puoi prendere Chrome Canary<\/a><\/noindex> e avviarlo con il flag --enable-quic<\/code>, collegarti al tuo server oppure, ad esempio, al sito quic.rocks e controllare il tipo di connessione negli Strumenti per sviluppatori:
\n\"HTTP
\nInvece di HTTP\/3 viene scritto http2+quic\/99<\/code>, ma in sostanza \u00e8 la stessa cosa.<\/p>\n
Altre tecnologie<\/h3>\n
<\/p>\n