{"id":52181,"date":"2019-11-02T00:00:00","date_gmt":"2019-11-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/http-3-razrushenie-osnov-i-divnyj-novyj-mir"},"modified":"2020-02-18T13:59:51","modified_gmt":"2020-02-18T10:59:51","slug":"http-3-razrushenie-osnov-i-divnyj-novyj-mir","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: distruzione delle basi e un mondo meraviglioso","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Da oltre 20 anni visualizziamo pagine web tramite il protocollo HTTP. La maggior parte degli utenti non si chiede nemmeno cosa sia e come funzioni. Altri sanno che sotto HTTP c'\u00e8 TLS, e sotto questo TCP, seguito da IP e cos\u00ec via. E poi ci sono i dissententi, che ritengono che TCP sia obsoleto e desiderano qualcosa di pi\u00f9 veloce, affidabile e sicuro. Tuttavia, nei loro tentativi di inventare un nuovo protocollo perfetto, sono tornati alle tecnologie degli anni '80 e cercano di costruire su di esse il loro meraviglioso nuovo mondo.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: distruzione delle basi e un mondo meraviglioso\" src=\"\/wp-content\/uploads\/2019\/11\/869bd86cc0b47c6c42f315cf20640018.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Un po' di storia: HTTP\/1.1<\/h2>\n<p>\nNel 1997, il protocollo di scambio di informazioni testuali HTTP versione 1.1 ha ottenuto il suo RFC. A quel tempo, il protocollo era gi\u00e0 utilizzato dai browser da diversi anni, e il nuovo standard \u00e8 rimasto in vigore per altri quindici. Il protocollo funzionava solo secondo il principio richiesta-risposta ed era destinato principalmente alla trasmissione di informazioni testuali.<\/p>\n<p>L'HTTP \u00e8 stato progettato per funzionare sopra il protocollo TCP, che garantisce la consegna affidabile dei pacchetti al destinatario. Il funzionamento del TCP si basa sull'instaurazione e sul mantenimento di una connessione sicura tra i punti finali e sulla suddivisione del traffico in segmenti. I segmenti hanno un numero sequenziale e una somma di controllo. Se uno dei segmenti non arriva o arriva con una somma di controllo errata, la trasmissione si fermer\u00e0 finch\u00e9 non verr\u00e0 ripristinato il segmento mancante.<\/p>\n<p>In HTTP\/1.0 la connessione TCP veniva chiusa dopo ogni richiesta. Questo era estremamente inefficiente, poich\u00e9 l'instaurazione di una connessione TCP (3-Way-Handshake) non \u00e8 un processo rapido. In HTTP\/1.1 \u00e8 stato introdotto un meccanismo di keep-alive, che consente di riutilizzare una connessione per pi\u00f9 richieste. Tuttavia, poich\u00e9 ci\u00f2 pu\u00f2 facilmente diventare un collo di bottiglia, in diverse implementazioni di HTTP\/1.1 \u00e8 consentita l'apertura di pi\u00f9 connessioni TCP a un unico host. Ad esempio, in Chrome e nelle ultime versioni di Firefox, sono consentite fino a sei connessioni.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: distruzione delle basi e un mondo meraviglioso\" src=\"\/wp-content\/uploads\/2019\/11\/b1c131da8e62ace741f3064f2fb96c60.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nIl protocollo di crittografia doveva essere affidato anche ad altri protocolli, e per questo motivo il protocollo TLS ha iniziato ad essere utilizzato sopra TCP, garantendo una protezione adeguata dei dati, ma aumentando ulteriormente il tempo necessario per stabilire la connessione. Alla fine, il processo di handshake \u00e8 diventato simile a questo:<br \/>\n <img decoding=\"async\" alt=\"HTTP\/3: distruzione delle basi e un mondo meraviglioso\" src=\"\/wp-content\/uploads\/2019\/11\/2fdccf56e0ed29444557836fdc65351b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustrazione di Cloudflare<\/i><\/p>\n<p>Cos\u00ec HTTP\/1.1 presentava una serie di problemi:<\/p>\n<ul>\n<li>Stabilire una connessione lenta.<\/li>\n<li>I dati vengono trasmessi in formato testo, il che significa che la trasmissione di immagini, video e altre informazioni non testuali \u00e8 inefficace.<\/li>\n<li>Una connessione TCP viene utilizzata per una singola richiesta, il che significa che le altre richieste devono trovare un'altra connessione o attendere che la richiesta corrente la rilasci.<\/li>\n<li>Supporta solo il modello pull. Non c'\u00e8 nulla nello standard riguardo al server-push.<\/li>\n<li>Le intestazioni vengono trasmesse in testo.<\/li>\n<\/ul>\n<p>\nSe il server-push viene implementato in modo approssimativo utilizzando il protocollo WebSocket, le altre problematiche dovevano essere affrontate in maniera pi\u00f9 radicale.<\/p>\n<h2>Un po' di modernit\u00e0: HTTP\/2<\/h2>\n<p>\nNel 2012, Google ha iniziato a lavorare sul protocollo SPDY (pronunciato \"spidi\"). Questo protocollo era progettato per risolvere le principali problematiche di HTTP\/1.1, mantenendo per\u00f2 la compatibilit\u00e0 all\u2019indietro. Nel 2015, il gruppo di lavoro IETF ha presentato la specifica di HTTP\/2, basata su SPDY. Ecco quali sono state le differenze in HTTP\/2:<\/p>\n<ul>\n<li>Serializzazione binaria.<\/li>\n<li>Multiplexing di pi\u00f9 richieste HTTP in una sola connessione TCP.<\/li>\n<li>Server push integrato (senza WebSocket).<\/li>\n<\/ul>\n<p>\nIl protocollo ha rappresentato un grande passo avanti. Ha notevolmente <noindex><a rel=\"nofollow\" href=\"https:\/\/http2.akamai.com\/demo\">vinto rispetto alla prima versione in termini di velocit\u00e0<\/a><\/noindex> e non richiede la creazione di pi\u00f9 connessioni TCP: tutte le richieste verso un unico host vengono multiplexate in una sola. In altre parole, in una connessione ci sono pi\u00f9 stream, ognuno dei quali ha il proprio ID. Come bonus, c'\u00e8 il server push integrato.<\/p>\n<p>Tuttavia, la multiplexing porta a un altro problema cruciale. Immagina di eseguire 5 richieste a un unico server in modo asincrono. Utilizzando HTTP\/2, tutte queste richieste verranno eseguite all'interno di una sola connessione TCP; significa che, se uno dei segmenti di qualsiasi richiesta si perde o arriva in modo errato, la trasmissione di tutte le richieste e le risposte si fermer\u00e0 finch\u00e9 non sar\u00e0 ripristinato il segmento mancante. \u00c8 evidente che maggiore \u00e8 la scadente qualit\u00e0 della connessione, pi\u00f9 lento sar\u00e0 HTTP\/2. <noindex><a rel=\"nofollow\" href=\"https:\/\/http3-explained.haxx.se\/en\/why-tcphol.html\">Secondo Daniel Stenberg,<\/a><\/noindex>, in condizioni in cui i pacchetti persi rappresentano il 2% del totale, HTTP\/1.1 in un browser si comporta meglio di HTTP\/2 grazie al fatto che apre 6 connessioni invece di una.<\/p>\n<p>Questo problema \u00e8 chiamato \"head-of-line blocking\" e, sfortunatamente, non \u00e8 possibile risolverlo utilizzando TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: distruzione delle basi e un mondo meraviglioso\" src=\"\/wp-content\/uploads\/2019\/11\/234a6dc218a9acf8d2212fbdf28f2188.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustrazione di Daniel Steinberg<\/i><\/p>\n<p>In conclusione, gli sviluppatori dello standard HTTP\/2 hanno svolto un lavoro enorme e hanno fatto praticamente tutto ci\u00f2 che era possibile a livello applicativo del modello OSI. \u00c8 giunto il momento di scendere al livello di trasporto e inventare un nuovo protocollo di trasporto.<\/p>\n<h2>Abbiamo bisogno di un nuovo protocollo: UDP vs TCP<\/h2>\n<p>\n\u0414\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0431\u044b\u0441\u0442\u0440\u043e \u0441\u0442\u0430\u043b\u043e \u043f\u043e\u043d\u044f\u0442\u043d\u043e, \u0447\u0442\u043e \u0432\u043d\u0435\u0434\u0440\u0438\u0442\u044c \u0441\u043e\u0432\u0441\u0435\u043c \u043d\u043e\u0432\u044b\u0439 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b \u0442\u0440\u0430\u043d\u0441\u043f\u043e\u0440\u0442\u043d\u043e\u0433\u043e \u0443\u0440\u043e\u0432\u043d\u044f \u2013 \u0437\u0430\u0434\u0430\u0447\u0430 \u0432 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0445 \u0440\u0435\u0430\u043b\u0438\u044f\u0445 \u043d\u0435\u0440\u0435\u0448\u0430\u0435\u043c\u0430\u044f. \u0414\u0435\u043b\u043e \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u043e \u0442\u0440\u0430\u043d\u0441\u043f\u043e\u0440\u0442\u043d\u043e\u043c \u0443\u0440\u043e\u0432\u043d\u0435 \u0437\u043d\u0430\u044e\u0442 \u0436\u0435\u043b\u0435\u0437\u043a\u0438 \u0438\u043b\u0438 middle-boxes (\u0440\u043e\u0443\u0442\u0435\u0440\u044b, \u0444\u0430\u0439\u0440\u0432\u043e\u043b\u044b, NAT-\u0441\u0435\u0440\u0432\u0435\u0440\u044b&#8230;), \u0430 \u043d\u0430\u0443\u0447\u0438\u0442\u044c \u0438\u0445 \u0447\u0435\u043c\u0443-\u0442\u043e \u043d\u043e\u0432\u043e\u043c\u0443 \u043a\u0440\u0430\u0439\u043d\u0435 \u043d\u0435\u043f\u0440\u043e\u0441\u0442\u0430\u044f \u0437\u0430\u0434\u0430\u0447\u0430. \u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0430 \u0442\u0440\u0430\u043d\u0441\u043f\u043e\u0440\u0442\u043d\u044b\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0437\u0430\u0448\u0438\u0442\u0430 \u0432 \u044f\u0434\u0440\u043e \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c, \u0430 \u044f\u0434\u0440\u0430 \u0442\u043e\u0436\u0435 \u043c\u0435\u043d\u044f\u044e\u0442\u0441\u044f \u043d\u0435 \u0442\u043e \u0447\u0442\u043e\u0431\u044b \u043e\u0447\u0435\u043d\u044c \u043e\u0445\u043e\u0442\u043d\u043e.<\/p>\n<p>A questo punto si potrebbe mollare tutto e dire \u00abCerto, inventeremo un nuovo HTTP\/3 con affetto e cortigiane, ma ci vorranno 10-15 anni prima che venga adottato (circa il tempo necessario per sostituire la maggior parte delle apparecchiature)\u00bb, ma c'\u00e8 un'altra opzione, non cos\u00ec ovvia: utilizzare il protocollo UDP. S\u00ec, proprio quel protocollo con cui ci scambiavamo file in rete locale negli anni '90 e nei primi anni 2000. Praticamente tutte le apparecchiature di oggi possono lavorare con esso.<\/p>\n<p>Quali sono i vantaggi di UDP rispetto a TCP? In primo luogo, non abbiamo una sessione a livello di trasporto riconosciuta dall'hardware. Questo ci permette di definire autonomamente le sessioni nei punti finali e di gestire i conflitti che sorgono. Non siamo quindi limitati a una o poche sessioni (come in TCP), ma possiamo crearne tante quante ne abbiamo bisogno. In secondo luogo, la trasmissione dei dati tramite UDP avviene pi\u00f9 rapidamente rispetto a TCP. Pertanto, in teoria, possiamo superare l'attuale limite di velocit\u00e0 raggiunto con HTTP\/2. <\/p>\n<p>Tuttavia, UDP non garantisce l'affidabilit\u00e0 nella trasmissione dei dati. In effetti, stiamo semplicemente inviando pacchetti, sperando che dall'altra parte vengano ricevuti. Non li hanno ricevuti? Beh, non \u00e8 andata bene\u2026 Questo \u00e8 stato sufficiente per la trasmissione di video per adulti, ma per cose pi\u00f9 serie \u00e8 necessaria affidabilit\u00e0, il che significa che dovremo sovrapporre qualcosa a UDP.<\/p>\n<p>Come nel caso di HTTP\/2, il lavoro per la creazione di un nuovo protocollo \u00e8 iniziato in Google nel 2012, cio\u00e8 pi\u00f9 o meno contemporaneamente all'inizio dei lavori su SPDY. Nel 2013, Jim Roskind ha presentato al pubblico <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34\/edit\">il protocollo QUIC (Quick UDP Internet Connections)<\/a><\/noindex>, e gi\u00e0 nel 2015 \u00e8 stata presentata una Internet Draft per la standardizzazione presso l'IETF. Gi\u00e0 a quel tempo, il protocollo sviluppato da Roskind in Google differiva notevolmente dallo standard proposto, perci\u00f2 la versione di Google venne chiamata gQUIC.<\/p>\n<h4>Che cos'\u00e8 QUIC<\/h4>\n<p>\nInnanzitutto, come gi\u00e0 detto, \u00e8 un involucro sopra UDP. Sopra UDP si stabilisce una connessione QUIC, in cui, analogamente a HTTP\/2, possono esistere pi\u00f9 stream. Questi stream esistono solo sui punti finali e vengono gestiti in modo indipendente. Se si verifica una perdita di pacchetti in uno stream, gli altri non ne saranno affetti.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: distruzione delle basi e un mondo meraviglioso\" src=\"\/wp-content\/uploads\/2019\/11\/0a64aa26d9b8216db56d389fa48578a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustrazione di Daniel Steinberg<\/i><\/p>\n<p>In secondo luogo, la crittografia non \u00e8 pi\u00f9 implementata come un livello separato, ma \u00e8 integrata nel protocollo. Questo consente di stabilire una connessione e scambiare chiavi pubbliche con un'unica operazione di handshake, oltre a permettere l'uso del meccanismo avanzato del 0-RTT handshake, eliminando cos\u00ec i ritardi durante l'handshake. Inoltre, ora \u00e8 possibile crittografare pacchetti dati singoli. Ci\u00f2 consente di avviare la decrittazione dei pacchetti ricevuti senza dover attendere il completamento della ricezione dei dati dallo stream. Questa modalit\u00e0 di funzionamento era completamente impossibile in TCP, poich\u00e9 TLS e TCP operavano in modo indipendente, e TLS non poteva sapere come i dati sarebbero stati frammentati da TCP. Pertanto, non era in grado di preparare i propri segmenti in modo che corrispondessero ai segmenti TCP uno a uno, permettendo una decrittazione indipendente. Tutti questi miglioramenti consentono a QUIC di ridurre la latenza rispetto a TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: distruzione delle basi e un mondo meraviglioso\" src=\"\/wp-content\/uploads\/2019\/11\/cb3c522636f7a052a0f5988fe7ea3a65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nIn terzo luogo, il concetto di stream leggeri consente di scollegare la connessione dall'indirizzo IP del cliente. Questo \u00e8 importante, ad esempio, quando un cliente passa da un punto di accesso Wi-Fi a un altro, cambiando il proprio IP. In questo caso, l'uso di TCP comporta un lungo processo in cui le connessioni TCP esistenti scadono e nuove connessioni vengono create con il nuovo IP. Con QUIC, il cliente continua semplicemente a inviare pacchetti al server dal nuovo IP con il vecchio ID dello stream. Poich\u00e9 l'ID dello stream \u00e8 ora unico e non viene riutilizzato, il server comprende che il cliente ha cambiato IP, invia i pacchetti mancanti e prosegue la comunicazione all'indirizzo nuovo.<\/p>\n<p>In quarto luogo, QUIC viene implementato a livello di applicazione, e non del sistema operativo. Questo, da un lato, consente di apportare modifiche pi\u00f9 rapidamente al protocollo, poich\u00e9 per ricevere un aggiornamento \u00e8 sufficiente aggiornare la libreria, senza dover aspettare una nuova versione del sistema operativo. D'altra parte, ci\u00f2 porta a un forte aumento del consumo della CPU.<\/p>\n<p>E infine, parliamo degli header. La compressione degli header \u00e8 uno degli aspetti che differisce tra QUIC e gQUIC. Non ha senso dedicare molto tempo a questo, quindi dir\u00f2 solo che nella versione proposta per la standardizzazione la compressione degli header \u00e8 stata resa il pi\u00f9 simile possibile a quella di HTTP\/2. Puoi leggere di pi\u00f9 in dettaglio. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">qui<\/a><\/noindex>.<\/p>\n<h4>Quanto \u00e8 pi\u00f9 veloce?<\/h4>\n<p>\n\u00c8 una domanda complessa. Il fatto \u00e8 che finch\u00e9 non abbiamo uno standard, non c'\u00e8 molto da misurare. Forse, l'unico dato statistico di cui disponiamo \u00e8 quello di Google, che utilizza gQUIC dal 2013 e nel 2016 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ietf.org\/proceedings\/96\/slides\/slides-96-quic-3.pdf\">ha riferito all'IETF<\/a><\/noindex>, che circa il 90% del traffico verso i loro server da Chrome ora utilizza QUIC. Nella stessa presentazione affermano che con gQUIC le pagine si caricano circa il 5% pi\u00f9 velocemente, mentre nel video in streaming si registrano il 30% in meno di buffering rispetto a TCP. <\/p>\n<p>Nel 2017, un gruppo di ricercatori guidato da Arash Molavi Kakhki ha pubblicato <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">un ampio lavoro<\/a><\/noindex> sullo studio delle performance di gQUIC rispetto a TCP. <br \/>\nLo studio ha rivelato alcune debolezze di gQUIC, come l'instabilit\u00e0 nella miscelazione dei pacchetti di rete, la scarsa equit\u00e0 nella gestione della larghezza di banda e un trasferimento pi\u00f9 lento di oggetti di piccole dimensioni (fino a 10 KB). Tuttavia, quest'ultimo pu\u00f2 essere compensato utilizzando il 0-RTT. In tutti gli altri casi esaminati, gQUIC ha mostrato un incremento della velocit\u00e0 rispetto a TCP. Le cifre specifiche sono difficili da fornire. \u00c8 meglio consultare <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">lo studio stesso<\/a><\/noindex> o <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.apnic.net\/2018\/01\/29\/measuring-quic-vs-tcp-mobile-desktop\/\">un breve post<\/a><\/noindex>.<\/p>\n<p>Qui \u00e8 importante sottolineare che questi dati riguardano specificamente gQUIC e non sono attuali per lo standard in fase di sviluppo. Cosa accadr\u00e0 per QUIC: per ora \u00e8 un mistero, ma c'\u00e8 speranza che le debolezze emerse in gQUIC vengano considerate e risolte.<\/p>\n<h2>Un po' di futuro: e per HTTP\/3?<\/h2>\n<p>\nQui \u00e8 tutto chiaro: l'API non cambier\u00e0 affatto. Rimarr\u00e0 esattamente come era in HTTP\/2. E se l'API rimane invariata, la transizione a HTTP\/3 dovr\u00e0 avvenire tramite l'uso di una versione aggiornata della libreria sul backend, che supporta il trasporto tramite QUIC. Tuttavia, dovremo mantenere un fallback per le versioni precedenti di HTTP per un lungo periodo, poich\u00e9 attualmente Internet non \u00e8 pronta per una transizione totale a UDP.<\/p>\n<h4>Chi gi\u00e0 supporta<\/h4>\n<p>\nEcco <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/quicwg\/base-drafts\/wiki\/Implementations\">lista<\/a><\/noindex> le implementazioni esistenti di QUIC. Nonostante l'assenza di uno standard, la lista \u00e8 piuttosto buona. <\/p>\n<p>Nessun browser attualmente supporta QUIC nella versione produzione. Recentemente si \u00e8 saputo che in Chrome \u00e8 stata attivata la supporto per HTTP\/3, ma solo nella versione Canary. <\/p>\n<p>Tra i backend, solo <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/caddyserver\/caddy\">Caddy<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/http3-the-past-present-and-future\/\">Cloudflare<\/a><\/noindex>, ma ancora in modo sperimentale. NGINX alla fine della primavera 2019 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/nginx-1-16-1-17-released\/\">hanno annunciato<\/a><\/noindex>, che stanno lavorando per supportare HTTP\/3, ma non hanno ancora completato.<\/p>\n<h4>Quali problemi ci sono?<\/h4>\n<p>\nViviamo in un mondo reale, dove nessuna grande tecnologia pu\u00f2 affermarsi senza incontrare resistenza, e QUIC non fa eccezione.<\/p>\n<p>La cosa pi\u00f9 importante \u00e8 che dobbiamo spiegare al browser che \u201chttps:\/\/\u201d ora non \u00e8 necessariamente collegato alla porta TCP 443. Potrebbe non esserci affatto TCP. A questo serve l'intestazione Alt-Svc. Essa consente di informare il browser che questo sito web \u00e8 disponibile anche su un certo protocollo a un certo indirizzo. In teoria, dovrebbe funzionare senza intoppi, ma nella pratica ci imbatteremo nel fatto che UDP pu\u00f2 essere, ad esempio, bloccato dal firewall per evitare attacchi DDoS.<\/p>\n<p>Tuttavia, anche se UDP non \u00e8 vietato, il client potrebbe trovarsi dietro un router NAT configurato per mantenere la sessione TCP tramite indirizzo IP. Poich\u00e9 utilizziamo UDP, che non ha una sessione hardware, il NAT non manterr\u00e0 la connessione e la sessione QUIC <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">si interromper\u00e0 costantemente<\/a><\/noindex>. <\/p>\n<p>Tutti questi problemi sono legati al fatto che UDP non \u00e8 stato utilizzato in passato per la trasmissione di contenuti Internet, quindi i produttori di hardware non potevano prevedere che ci\u00f2 potesse accadere. Analogamente, gli amministratori delle reti non comprendono ancora bene come configurare correttamente le proprie reti per supportare QUIC. Questa situazione cambier\u00e0 lentamente e, in ogni caso, tali cambiamenti richiederanno meno tempo rispetto all'implementazione di un nuovo protocollo di trasporto. <\/p>\n<p>Inoltre, come gi\u00e0 accennato, QUIC aumenta notevolmente l'uso della CPU. Daniel Stenberg <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=idViw4anA6E\">ha stimato<\/a><\/noindex> un aumento dell'utilizzo della CPU fino a tre volte.<\/p>\n<h4>Quando arriver\u00e0 HTTP\/3<\/h4>\n<p>\nStandard <noindex><a rel=\"nofollow\" href=\"https:\/\/datatracker.ietf.org\/wg\/quic\/about\/\">si spera venga adottato<\/a><\/noindex> entro maggio 2020, ma considerando che attualmente i documenti previsti per luglio 2019 non sono ancora completati, si pu\u00f2 dire che la data verr\u00e0 probabilmente posticipata.<\/p>\n<p>Google utilizza la sua implementazione di gQUIC dal 2013. Se si osserva una richiesta HTTP inviata al motore di ricerca di Google, si pu\u00f2 notare questo:<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: distruzione delle basi e un mondo meraviglioso\" src=\"\/wp-content\/uploads\/2019\/11\/af422268eb85b488c7be1b70c6d33fad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Conclusioni<\/h2>\n<p>\nQUIC appare attualmente come una tecnologia piuttosto grezza ma molto promettente. Considerando che negli ultimi 20 anni tutte le ottimizzazioni dei protocolli a livello di trasporto si sono principalmente concentrate su TCP, QUIC, che nella maggior parte dei casi offre migliori prestazioni, sembra gi\u00e0 ora davvero interessante. <\/p>\n<p>Tuttavia, rimangono ancora problemi irrisolti che dovremo affrontare nei prossimi anni. Il processo potrebbe richiedere pi\u00f9 tempo a causa dell'hardware coinvolto, che nessuno ama aggiornare, ma tutte le problematiche sembrano comunque risolvibili e, prima o poi, tutti noi avremo HTTP\/3. <\/p>\n<p>Il futuro \u00e8 alle porte!<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/473930\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442. \u0414\u0440\u0443\u0433\u0438\u0435 \u0437\u043d\u0430\u044e\u0442, \u0447\u0442\u043e \u0433\u0434\u0435-\u0442\u043e \u043f\u043e\u0434 HTTP \u0435\u0441\u0442\u044c TLS, \u0430 \u043f\u043e\u0434 \u043d\u0438\u043c TCP, \u043f\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u044b\u043c IP \u0438 \u0442\u0430\u043a \u0434\u0430\u043b\u0435\u0435. \u0410 \u0442\u0440\u0435\u0442\u044c\u0438 \u2013 \u0435\u0440\u0435\u0442\u0438\u043a\u0438 \u2013 \u0441\u0447\u0438\u0442\u0430\u044e\u0442, \u0447\u0442\u043e TCP \u2013 \u044d\u0442\u043e \u043f\u0440\u043e\u0448\u043b\u044b\u0439 \u0432\u0435\u043a, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52181","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442. \u0414\u0440\u0443\u0433\u0438\u0435 \u0437\u043d\u0430\u044e\u0442, \u0447\u0442\u043e \u0433\u0434\u0435-\u0442\u043e \u043f\u043e\u0434 HTTP \u0435\u0441\u0442\u044c TLS, \u0430 \u043f\u043e\u0434 \u043d\u0438\u043c TCP, \u043f\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u044b\u043c IP \u0438 \u0442\u0430\u043a \u0434\u0430\u043b\u0435\u0435. \u0410 \u0442\u0440\u0435\u0442\u044c\u0438 \u2013 \u0435\u0440\u0435\u0442\u0438\u043a\u0438 \u2013 \u0441\u0447\u0438\u0442\u0430\u044e\u0442, \u0447\u0442\u043e TCP \u2013 \u044d\u0442\u043e \u043f\u0440\u043e\u0448\u043b\u044b\u0439 \u0432\u0435\u043a,\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47HTTP\/3: \u0440\u0430\u0437\u0440\u0443\u0448\u0435\u043d\u0438\u0435 \u043e\u0441\u043d\u043e\u0432 \u0438 \u0434\u0438\u0432\u043d\u044b\u0439 \u043d\u043e\u0432\u044b\u0439 \u043c\u0438\u0440 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442. \u0414\u0440\u0443\u0433\u0438\u0435 \u0437\u043d\u0430\u044e\u0442, \u0447\u0442\u043e \u0433\u0434\u0435-\u0442\u043e \u043f\u043e\u0434 HTTP \u0435\u0441\u0442\u044c TLS, \u0430 \u043f\u043e\u0434 \u043d\u0438\u043c TCP, \u043f\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u044b\u043c IP \u0438 \u0442\u0430\u043a \u0434\u0430\u043b\u0435\u0435. \u0410 \u0442\u0440\u0435\u0442\u044c\u0438 \u2013 \u0435\u0440\u0435\u0442\u0438\u043a\u0438 \u2013 \u0441\u0447\u0438\u0442\u0430\u044e\u0442, \u0447\u0442\u043e TCP \u2013 \u044d\u0442\u043e \u043f\u0440\u043e\u0448\u043b\u044b\u0439 \u0432\u0435\u043a,\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-01T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T10:59:51+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47HTTP\/3: distruzione delle fondamenta e un meraviglioso nuovo mondo | ProHoster","description":"Da oltre 20 anni visualizziamo pagine web tramite il protocollo HTTP. La maggior parte degli utenti non si rende nemmeno conto di cosa sia e come funzioni. Altri sanno che sotto HTTP c'\u00e8 TLS, sotto di esso TCP, e sotto TCP c'\u00e8 IP, e cos\u00ec via. E ci sono quelli, eretici, che credono che TCP appartenga al passato.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47HTTP\/3: \u0440\u0430\u0437\u0440\u0443\u0448\u0435\u043d\u0438\u0435 \u043e\u0441\u043d\u043e\u0432 \u0438 \u0434\u0438\u0432\u043d\u044b\u0439 \u043d\u043e\u0432\u044b\u0439 \u043c\u0438\u0440 | ProHoster","og:description":"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442. \u0414\u0440\u0443\u0433\u0438\u0435 \u0437\u043d\u0430\u044e\u0442, \u0447\u0442\u043e \u0433\u0434\u0435-\u0442\u043e \u043f\u043e\u0434 HTTP \u0435\u0441\u0442\u044c TLS, \u0430 \u043f\u043e\u0434 \u043d\u0438\u043c TCP, \u043f\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u044b\u043c IP \u0438 \u0442\u0430\u043a \u0434\u0430\u043b\u0435\u0435. \u0410 \u0442\u0440\u0435\u0442\u044c\u0438 \u2013 \u0435\u0440\u0435\u0442\u0438\u043a\u0438 \u2013 \u0441\u0447\u0438\u0442\u0430\u044e\u0442, \u0447\u0442\u043e TCP \u2013 \u044d\u0442\u043e \u043f\u0440\u043e\u0448\u043b\u044b\u0439 \u0432\u0435\u043a,","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-01T21:00:00+00:00","article:modified_time":"2020-02-18T10:59:51+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52181","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 02:46:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:48:31","updated":"2026-01-24 02:46:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/52181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=52181"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/52181\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=52181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=52181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=52181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}