Che cosa succede quando apri una pagina web

Con un viaggio di andata e ritorno di 50 ms, una pagina HTTPS ha bisogno di almeno 4 viaggi di andata e ritorno, 200 ms, prima che arrivi il primo byte di HTML. HTTP/3 ne toglie uno.

Le sette e quaranta del mattino. Una studentessa su un treno affollato tocca un link al menu della mensa scolastica con i dati mobili, e un attimo dopo compare il menu del giorno. (È una scena inventata.) In quell'attimo il telefono ha fatto tutto quello che c'è nelle ultime cinque unità: una ricerca DNS, una connessione TCP, una sessione cifrata e una richiesta HTTP a cui è arrivata una risposta con un codice di stato. Segui il telefono passo per passo e conta le attese.

Prima il telefono legge il link

Supponiamo che il link sia https://www.example.com/index.html. MDN divide un URL in parti. https è lo schema: usa HTTP su una connessione TLS cifrata, sulla porta 443 se non ne è scritta un'altra. www.example.com è l'host, il nome che il DNS trasformerà in un indirizzo. /index.html è il percorso, la risorsa richiesta su quel server. Un URL può anche portare una query dopo un punto interrogativo e un frammento dopo un cancelletto. Il frammento indica un punto dentro la pagina e non viene mai mandato al server.

Quattro viaggi di andata e ritorno prima del primo byte

Il tempo che serve perché un messaggio arrivi al server e la risposta torni indietro è il tempo di andata e ritorno (RTT). Conta i viaggi di andata e ritorno e vedrai da dove viene l'attesa. Uno: se il nome non è in cache, la ricerca DNS costa circa un viaggio fino al resolver. Due: l'handshake TCP, SYN in uscita e SYN-ACK di ritorno. Tre: TLS 1.3 (RFC 8446) concorda le chiavi in un viaggio di andata e ritorno, e l'ultimo messaggio di handshake del client può viaggiare insieme alla richiesta HTTP. Quattro: la richiesta parte e la risposta torna. Con un RTT di 50 ms fanno 200 ms prima del primo byte del menu, anche se il server risponde all'istante.

HTTP/3 (RFC 9114) funziona su QUIC (RFC 9000) invece che su TCP. QUIC sta sopra UDP e stabilisce insieme la connessione e le chiavi TLS, quindi il viaggio separato di TCP sparisce: DNS, un viaggio di andata e ritorno per l'handshake, poi la richiesta, tre in tutto. L'HTTP semplice sulla porta 80 salta TLS e ne richiede anch'esso tre, ma allora chiunque stia lungo il percorso, per esempio chi gestisce il Wi-Fi di un bar, può leggere o modificare la pagina. Il lucchetto nella barra degli indirizzi significa che la connessione con quel dominio è cifrata. Non significa che il sito in sé sia onesto.

Il menu arriva con un numero davanti

La risposta comincia con un codice di stato di tre cifre. La RFC 9110 raggruppa i codici secondo la prima cifra: 1xx informativi, 2xx successo, 3xx reindirizzamento, 4xx errore del client e 5xx errore del server. Quelli che incontrerai più spesso sono 200 OK, 301 Moved Permanently (la pagina ha un nuovo indirizzo), 404 Not Found e 500 Internal Server Error. Se la scuola avesse spostato la pagina del menu, il telefono riceverebbe prima un 301 e poi chiederebbe di nuovo al nuovo indirizzo. Un 404 vuol dire che il server ha risposto e non aveva niente a quel percorso, quindi la rete in sé funzionava.

Una pagina, tanti file

L'HTML è raramente tutta la pagina. Supponiamo che citi un foglio di stile, uno script e cinque immagini. Se il telefono aprisse una nuova connessione per ognuno, ogni file pagherebbe di nuovo i viaggi di andata e ritorno di TCP e TLS. Il browser invece tiene aperta la connessione e manda le richieste successive su quella, e con HTTP/2 e HTTP/3 più richieste viaggiano sulla stessa connessione contemporaneamente. I browser hanno anche una loro cache. Quando una risposta dice che può essere riusata per un certo tempo, alla visita successiva quel file si carica dalla memoria senza mandare nessuna richiesta. Solo quando i file sono arrivati il browser impagina e disegna quello che vedi. Ecco perché la pagina del menu che la studentessa apre ogni mattina compare più in fretta di un sito aperto per la prima volta, anche sulla stessa rete.