Wanneer u voor het eerst leert hoe domeinnamen, IP-adressen, webservers en websites allemaal passen en samenwerken, kan dit soms een beetje verwarrend of overweldigend zijn. Hoe zit het allemaal zo soepel? De SuperUser Q & A-post van vandaag bevat de antwoorden op de vragen van nieuwsgierige lezers.
De vraag- en antwoordsessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een community-gedreven groepering van Q & A-websites.
Foto met dank aan Rosmarie Voegtli (Flickr) .
De vraag
SuperUser-lezer user3407319 wil weten of webservers elk slechts één website bevatten:
Op basis van wat ik begrijp over DNS en het koppelen van een domeinnaam aan het IP-adres van de webserver waarop een website is opgeslagen, betekent dit dat elke webserver slechts één website kan bevatten? Als webservers meer dan één website bevatten, hoe wordt dit dan allemaal opgelost, zodat ik zonder problemen of verwisselingen toegang kan krijgen tot de website die ik wil?
Hebben webservers elk maar één website, of hebben ze er meer?
Het antwoord
SuperUser-bijdrager Bob heeft het antwoord voor ons:
In principe neemt de browser de domeinnaam op in het HTTP-verzoek, zodat de webserver weet welk domein is aangevraagd en dienovereenkomstig kan reageren.
HTTP-verzoeken
Hier is hoe uw typische HTTP-verzoek gebeurt:
1. De gebruiker geeft een URL op in de vorm http: // host: poort / pad.
2. De browser extraheert het host- (domein) gedeelte van de URL en vertaalt dit naar een IP-adres (indien nodig) in een proces dat bekend staat als naamomzetting. Deze vertaling kan plaatsvinden via DNS, maar dat hoeft niet (het lokale hosts-bestand op gewone besturingssystemen omzeilt DNS bijvoorbeeld).
3. De browser opent een TCP-verbinding met de opgegeven poort, of standaard poort 80 op dat IP-adres.
4. De browser verzendt een HTTP-verzoek. Voor HTTP / 1.1 ziet het er als volgt uit:
De host-header is standaard en vereist in HTTP / 1.1. Het was niet gespecificeerd in de HTTP / 1.0-specificatie, maar sommige servers ondersteunen het toch.
Vanaf hier heeft de webserver verschillende soorten informatie die hij kan gebruiken om te beslissen wat de reactie moet zijn. Merk op dat het mogelijk is dat een enkele webserver aan meerdere IP-adressen is gebonden.
- Het gevraagde IP-adres, van de TCP-socket (het IP-adres van de client is ook beschikbaar, maar dit wordt zelden gebruikt, en soms voor blokkering / filtering)
- De gevraagde poort, van de TCP-socket
- De gevraagde hostnaam, zoals gespecificeerd in de hostheader door de browser in het HTTP-verzoek
- Het gevraagde pad
- Alle andere headers (cookies, etc.)
Zoals je lijkt te hebben gemerkt, plaatst de meest voorkomende shared hosting-setup tegenwoordig meerdere websites op één IP-adres: poortcombinatie, waardoor alleen de host onderscheid kan maken tussen websites.
Dit staat bekend als een Op naam gebaseerde virtuele host in Apache-land, terwijl Nginx ze belt Servernamen in serverblokken , en IIS geeft de voorkeur aan Virtuele server .
Hoe zit het met HTTPS?
HTTPS is een beetje anders. Alles is identiek tot aan het tot stand brengen van de TCP-verbinding, maar daarna moet een versleutelde TLS-tunnel tot stand worden gebracht. Het doel is om geen informatie over het verzoek te lekken.
Om te verifiëren dat de webserver daadwerkelijk eigenaar is van dit domein, moet de webserver een certificaat verzenden dat is ondertekend door een vertrouwde derde partij. De browser vergelijkt dit certificaat vervolgens met het aangevraagde domein.
Dit levert een probleem op. Hoe weet de webserver welk certificaat van de host / website moet worden verzonden als dit nodig is voordat het HTTP-verzoek wordt ontvangen?
Traditioneel werd dit opgelost door een speciaal IP-adres (of poort) te hebben voor elke website die HTTPS nodig had. Dit is duidelijk problematisch geworden omdat we bijna geen IPv4-adressen meer hebben.
Enter SNI (Servernaam-indicatie). De browser geeft nu de hostnaam door tijdens de TLS-onderhandelingen, zodat de webserver deze informatie vroeg genoeg heeft om het juiste certificaat te verzenden. Aan de kant van de webserver lijkt de configuratie sterk op hoe virtuele HTTP-hosts zijn geconfigureerd.
Het nadeel is dat de hostnaam nu wordt doorgegeven als platte tekst vóór codering en in wezen gelekte informatie is. Dit wordt meestal als een acceptabele afweging beschouwd, hoewel de hostnaam toch normaal gesproken in een DNS-query wordt weergegeven.
Wat als u een website alleen op IP-adres aanvraagt?
Wat de webserver doet als hij niet weet welke specifieke host u heeft aangevraagd, hangt af van de implementatie en configuratie van de webserver. Meestal is er een "standaard", "catch-all" of "fall back" -website gespecificeerd die antwoorden zal geven op alle verzoeken die niet expliciet een host specificeren.
Deze standaardwebsite kan een eigen, onafhankelijke website zijn (die vaak een foutmelding geeft), of het kan een van de andere websites op de webserver zijn, afhankelijk van de voorkeuren van de webserverbeheerder.
Iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden lezen van andere technisch onderlegde Stack Exchange-gebruikers? Bekijk hier de volledige discussiethread .
