In questo articolo Indice dei contenuti 2 sezioni
Basta digitare un indirizzo nella barra degli indirizzi di Chrome, Firefox o Edge e premere Invio perché, una frazione di secondo dopo, la pagina compaia sullo schermo. Il browser contatta un server, scarica i contenuti e li mostra. Detta così sembra una cosa semplice, eppure dietro quel gesto quotidiano si muove una catena di decisioni ben più articolata. Prima ancora di aprire una connessione il programma deve capire cosa è stato scritto, se si tratta di un sito o di una ricerca, quale protocollo adottare e quale sistema remoto raggiungere. Poi entrano in scena la risoluzione DNS, la scelta tra IPv4 e IPv6, la negoziazione crittografica, il trasferimento dei dati e l’elaborazione di HTML, CSS e JavaScript. Non tutto si ripete a ogni visita, però. Alcuni passaggi vengono saltati grazie alle cache, altri si svolgono in parallelo e qualcuno parte addirittura prima che il dito tocchi il tasto.
Ricerca o sito web, e poi la scelta di HTTPS
Oggi quel campo in alto non serve soltanto a inserire URL. È anche una casella di ricerca, una porta d’accesso alla cronologia e uno strumento che suggerisce completamenti in base ai siti già frequentati. Quando riconosce la forma di un nome di dominio lo tratta come destinazione web, mentre una frase scritta come in un motore di ricerca viene girata a Google, Bing, DuckDuckGo o al servizio preferito dall’utente.
La distinzione non è sempre immediata. Un server locale, un nome host aziendale o una parola che contiene un punto possono richiedere regole specifiche, soprattutto in presenza di reti intranet e domini configurati in casa. Dopo l’Invio il programma ricava l’URL effettivo e ne isola host, porta, percorso e le altre componenti. C’è poi il frammento che segue il simbolo #, cioè una posizione logica dentro la pagina. Questo pezzo non viaggia nella richiesta HTTP verso il server: resta a disposizione del browser per saltare a una sezione o degli script della pagina.
Se non viene specificato il protocollo, la tendenza attuale è privilegiare HTTPS. Quando il dominio usa HSTS (HTTP Strict Transport Security) il browser sa già, grazie a una regola memorizzata in una visita precedente o integrata al suo interno, che deve collegarsi solo in modo cifrato. È il server web a inviare questa indicazione nelle risposte HTTPS, stabilendo per quanto tempo vale ed eventualmente estendendola ai sottodomini. In assenza di HSTS il browser può comunque tentare prima la via sicura, e l’eventuale ripiego su HTTP dipende dalle impostazioni. La differenza conta: nel primo caso la decisione è locale e non serve alcun contatto preliminare, nel secondo arriva un vero reindirizzamento dal server, per esempio con codice 301 o 308.
Il DNS, le CDN e perché cambiare resolver non fa miracoli
Per raggiungere un servizio remoto serve il suo indirizzo IP, e qui interviene il resolver DNS, che traduce il nome mnemonico nell’indirizzo pubblico della destinazione. Non sempre parte una richiesta verso un server lontano: la risposta può arrivare dalla cache del browser, del sistema operativo o del resolver ricorsivo, oppure da configurazioni locali come il file HOSTS o regole aziendali. L’ordine dei controlli varia da implementazione a implementazione. Se il resolver non conosce la risposta la recupera risalendo l’infrastruttura fino ai server autorevoli, ottenendo indirizzi IPv4 tramite record A o IPv6 tramite record AAAA.
Molti appassionati cercano il resolver più veloce, e un piccolo guadagno in effetti c’è. Ma la risoluzione del nome è solo una fetta del tempo di caricamento. Se il server del sito è lento, la rete ha una latenza alta o la pagina usa JavaScript pesante, i benefici diventano trascurabili. C’è anche un altro aspetto: il DNS può restituire IP diversi in base alla posizione dell’utente o del resolver, quindi cambiarlo può portare a un nodo CDN più vicino o più lontano.
Del resto l’IP non indica per forza la macchina che ospita il sito. CDN, reverse proxy e bilanciatori di carico fanno sì che spesso risponda un nodo periferico, che applica controlli di sicurezza e recupera i contenuti dal server di origine. Lo stesso indirizzo può ospitare molti siti, ed è per questo che il nome di dominio resta parte integrante della richiesta HTTP. Nel frattempo la tabella di routing sceglie interfaccia e gateway, ARP per IPv4 e Neighbor Discovery per IPv6 raggiungono il dispositivo successivo e i router instradano i pacchetti verso la destinazione, che grazie a CDN e accordi tra operatori può trovarsi in un data center vicino.
Infine va scelto il trasporto. Con HTTP/1.1 e HTTP/2 su HTTPS il browser usa TCP, che apre la connessione con uno scambio di tre messaggi: richiesta di avvio, conferma del server e completamento. TCP garantisce un flusso ordinato e affidabile gestendo ritrasmissioni, perdite e congestione. Con HTTP/3 invece tutto cambia, perché il protocollo si appoggia a QUIC, costruito sopra UDP con propri meccanismi di affidabilità, controllo della congestione, gestione dei flussi e protezione crittografica. QUIC unisce l’avvio della connessione alla negoziazione TLS 1.3, riducendo in molte circostanze il numero di scambi iniziali necessari.
Fonte: TecnoAndroid