Hebben webservers maar één website?

Wanneer u voor het eerst leert hoe domeinnamen, IP-adressen, webservers en websites allemaal passen en samenwerken, kan het soms een beetje verwarrend of overweldigend zijn. Hoe is alles ingesteld om zo soepel te werken? De SuperUser Q & A-post van vandaag biedt de antwoorden op de vragen van een nieuwsgierige lezer.

De Question & Answer-sessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een gemeenschapsgedreven groep 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 maar één website kan bevatten? Als webservers meerdere websites hebben, hoe wordt alles dan opgelost, zodat ik zonder problemen of verwisselingen toegang kan krijgen tot de website die ik wil??

Hebben webservers maar één website, of bevatten ze meer?

Het antwoord

SuperUser-bijdrager Bob heeft het antwoord voor ons:

Kort gezegd bevat de browser de domeinnaam in het HTTP-verzoek, zodat de webserver weet welk domein is aangevraagd en dienovereenkomstig kan reageren.

HTTP-verzoeken

Hier ziet u hoe uw typische HTTP-aanvraag gebeurt:

1. De gebruiker biedt een URL in de vorm http: // host: poort / pad.

2. De browser extraheert het host (domein) deel van de URL en vertaalt deze naar een IP-adres (indien nodig) in een proces dat naamomzetting wordt genoemd. Deze vertaling kan via DNS gebeuren, maar dat hoeft niet (het lokale hosts-bestand op gewone besturingssystemen omzeilt bijvoorbeeld DNS).

3. De browser opent een TCP-verbinding naar de opgegeven poort of standaard naar poort 80 op dat IP-adres.

4. De browser verzendt een HTTP-aanvraag. 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 spec, maar sommige servers ondersteunen het toch.

Vanaf hier heeft de webserver verschillende 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, vanuit de TCP-socket (het IP-adres van de client is ook beschikbaar, maar dit wordt zelden gebruikt en soms voor blokkeren / filteren)
• De gevraagde poort, vanuit de TCP-socket
• De aangevraagde hostnaam, zoals opgegeven in de hostheader door de browser in het HTTP-verzoek
• Het gevraagde pad
• Alle andere headers (cookies, etc.)

Zoals je waarschijnlijk gemerkt hebt, plaatst de meest gebruikte shared hosting-opstelling tegenwoordig meerdere websites op één IP-adres: poortcombinatie, waardoor alleen de host hoeft te differentiëren tussen websites.

Dit staat bekend als een op naam gebaseerde virtuele host in Apache-land, terwijl Nginx ze servernamen noemt 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 de totstandkoming van de TCP-verbinding, maar daarna moet een gecodeerde TLS-tunnel tot stand worden gebracht. Het doel is om geen informatie over het verzoek te lekken.

Om te controleren of de webserver daadwerkelijk eigenaar is van dit domein, moet de webserver een certificaat verzenden dat is ondertekend door een vertrouwde derde partij. De browser zal dit certificaat vervolgens vergelijken met het domein dat het heeft aangevraagd.

Dit levert een probleem op. Hoe weet de webserver welk host / website-certificaat moet worden verzonden als dit moet voordat de HTTP-aanvraag is ontvangen??

Traditioneel werd dit opgelost door een specifiek IP-adres (of poort) te hebben voor elke website die HTTPS nodig heeft. Vanzelfsprekend is dit problematisch geworden omdat we geen IPv4-adressen meer hebben.

Voer SNI in (servernaam indicatie). De browser geeft nu de hostnaam door tijdens de TLS-onderhandelingen, dus de webserver heeft deze informatie vroeg genoeg om het juiste certificaat te verzenden. Aan de zijde van de webserver lijkt de configuratie sterk op hoe HTTP virtuele hosts zijn geconfigureerd.

Het nadeel is dat de hostnaam nu wordt doorgegeven als platte tekst vóór versleuteling, en in wezen informatie is die wordt gelekt. Dit wordt meestal als een acceptabele afweging beschouwd, aangezien de hostnaam normaal gesproken in een DNS-query wordt weergegeven.

Wat als u een website uitsluitend via 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. Doorgaans is er een opgegeven "standaard", "catch-all" of "terugval" -website die antwoorden biedt op alle verzoeken die niet expliciet een host specificeren.

Deze standaardwebsite kan zijn eigen onafhankelijke website zijn (vaak met een foutmelding), of het kan een van de andere websites op de webserver zijn, afhankelijk van de voorkeuren van de beheerder van de webserver.

Heb je iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk hier de volledige discussiethread.