Fondamentalmente: il browser include il nome di dominio nella richiesta HTTP, quindi il server web sa quale dominio è stato richiesto e può rispondere di conseguenza.
Richieste HTTP
Ecco come avviene la tua tipica richiesta HTTP:
L'utente fornisce un URL, nel modulo http://host:port/path
.
Il browser estrae la parte host (dominio) dell'URL e, se necessario, lo traduce in un indirizzo IP, in un processo noto come risoluzione dei nomi . Questa traduzione può avvenire tramite DNS, ma non è necessario (ad esempio, il hosts
file locale su sistemi operativi comuni ignora il DNS).
Il browser apre una connessione TCP alla porta specificata o, per impostazione predefinita, porta 80, su quell'indirizzo IP.
Il browser invia una richiesta HTTP. Per HTTP / 1.1, è simile al seguente:
GET /path HTTP/1.1
Host: example.com
(L' Host
intestazione è standard e richiesta in HTTP / 1.1. Non è stato specificato nelle specifiche HTTP / 1.0, ma alcuni server lo supportano comunque.)
Da qui, il server web ha diverse informazioni che può usare per decidere quale dovrebbe essere la risposta. Si noti che è possibile che un singolo server web sia associato a più indirizzi IP.
- L'indirizzo IP richiesto, dal socket TCP
- È anche disponibile l'indirizzo IP del client, ma questo viene usato raramente, a volte per bloccare / filtrare
- La porta richiesta, dal socket TCP
- Il nome host richiesto, come specificato
Host
nell'intestazione dal browser nella richiesta HTTP.
- Il percorso richiesto
- Qualsiasi altra intestazione (cookie, ecc.)
Come sembra aver notato, la configurazione di hosting condiviso più comune in questi giorni mette più siti Web su un unico indirizzo IP: combinazione di porte, lasciando solo la Host
differenziazione tra i siti Web.
Questo è noto come Host virtuale basato sul nome in Apache-land, mentre Nginx li chiama Server Names in Server Blocks e IIS preferisce Virtual Server .
Che dire di HTTPS?
HTTPS è un po 'diverso. Tutto è identico alla creazione della connessione TCP, ma successivamente deve essere stabilito un tunnel TLS crittografato. L'obiettivo è quello di non perdere alcuna informazione sulla richiesta.
Per verificare che il server sia effettivamente proprietario di questo dominio, il server deve inviare un certificato firmato da una terza parte attendibile. Il browser confronterà quindi questo certificato con il dominio richiesto.
Questo presenta un problema. Come fa il server a sapere quale certificato host (sito Web) inviare, se deve farlo prima di ricevere la richiesta HTTP?
Tradizionalmente, questo è stato risolto con un indirizzo IP (o porta) dedicato per ogni sito Web che richiede HTTPS. Ovviamente, questo diventa problematico quando iniziamo a rimanere senza indirizzi IPv4.
Immettere SNI (Indicazione nome server). Il browser ora passa il nome host durante le negoziazioni TLS, quindi il server ha queste informazioni abbastanza presto per inviare il certificato corretto. Sul lato server, la configurazione è molto simile alla configurazione degli host virtuali HTTP.
Il rovescio della medaglia è che il nome host è ora passato come testo normale prima della crittografia, ed è essenzialmente informazioni trapelate. Questo di solito è considerato un compromesso accettabile, considerando comunque il nome host normalmente esposto in una query DNS.
Cosa succede se si richiede un sito solo per indirizzo IP?
Cosa fa il server quando non sa quale host specifico hai richiesto dipende dall'implementazione e dalla configurazione del server. In genere, è stato specificato un sito "predefinito", "catchall" o "fallback" che fornirà le risposte a tutte le richieste che non specificano esplicitamente un host.
Questo sito predefinito può essere un sito indipendente (che spesso mostra un messaggio di errore) oppure può essere uno qualsiasi degli altri siti sul server, a seconda delle preferenze dell'amministratore del server.
Host:
nell'intestazione. In caso di hosting condiviso, il server Web può essere configurato dal provider per gestirlo in diversi modi (ad es. Avere un predefinito, reindirizzare al provider ecc.).