{"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 nuovo mondo meraviglioso","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sono gi\u00e0 passati pi\u00f9 di 20 anni da quando visualizziamo pagine web tramite il protocollo HTTP. La maggior parte degli utenti non si \u00e8 mai realmente interrogata su cosa sia e come funzioni. Altri sanno che sotto HTTP c'\u00e8 TLS, e sotto di esso TCP, e a sua volta IP e cos\u00ec via. Ma ci sono anche degli eretici che considerano TCP un concetto obsoleto, desiderando qualcosa di pi\u00f9 veloce, affidabile e sicuro. Tuttavia, nei loro tentativi di inventare un nuovo protocollo ideale, sono tornati alle tecnologie degli anni '80 e cercano di costruire su di esse il loro meraviglioso nuovo mondo.
\n\"HTTP\/3:
\n<\/a><\/noindex><\/p>\n

Un po' di storia: HTTP\/1.1<\/h2>\n

\nNel 1997, il protocollo di scambio di informazioni testuali HTTP versione 1.1 ottenne 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 esclusivamente secondo il principio richiesta-risposta e era principalmente destinato alla trasmissione di informazioni testuali.<\/p>\n

HTTP \u00e8 stato progettato per funzionare sopra il protocollo TCP, il quale garantisce la consegna affidabile dei pacchetti al destinatario. Il funzionamento di TCP si basa sull'instaurazione e il mantenimento di una connessione sicura tra i punti finali e sulla suddivisione del traffico in segmenti. I segmenti hanno un proprio numero sequenziale e un checksum. Se uno dei segmenti non arriva o arriva con un checksum errato, il trasferimento si interromper\u00e0 finch\u00e9 non sar\u00e0 recuperato il segmento mancante.<\/p>\n

In HTTP\/1.0, la connessione TCP veniva chiusa dopo ogni richiesta. Questo era estremamente dispendioso, poich\u00e9 l'instaurazione di una connessione TCP (3-Way Handshake) non \u00e8 un processo rapido. In HTTP\/1.1 \u00e8 stato introdotto il meccanismo keep-alive, che consente di riutilizzare una singola connessione per pi\u00f9 richieste. Tuttavia, poich\u00e9 questo pu\u00f2 facilmente diventare un collo di bottiglia, in diverse implementazioni di HTTP\/1.1 \u00e8 consentita l'apertura di pi\u00f9 connessioni TCP verso un singolo host. Ad esempio, in Chrome e nelle ultime versioni di Firefox, sono consentite fino a sei connessioni.
\n\"HTTP\/3:
\nLa crittografia era prevista anche per essere delegata ad altri protocolli, e a tale scopo, sopra TCP veniva utilizzato il protocollo TLS, che proteggeva i dati in modo piuttosto affidabile, ma aumentava ulteriormente il tempo necessario per stabilire una connessione. Alla fine, il processo di handshake \u00e8 apparso in questo modo:
\n \"HTTP\/3:
\nIllustrazione Cloudflare<\/i><\/p>\n

Pertanto, HTTP\/1.1 presentava una serie di problemi:<\/p>\n