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? Today's SuperUser Q & A post heeft de antwoorden op vragen van nieuwsgierige lezers.

De vraag van vandaag &Antwoord sessie komt naar ons met dank aan SuperUser-een onderverdeling van Stack Exchange, een community-gestuurde groepering van Q & A-websites.

Foto met dank aan Rosmarie Voegtli( Flickr).

De vraag

SuperUser-lezer user3407319 wil weten of webservers maar één website hebben:

Gebaseerd op 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 elkwebserver kan maar één website bevatten? Als webservers meerdere websites hebben, hoe wordt dit allemaal opgelost zodat ik zonder problemen of verwisselingen toegang heb tot de website die ik wil?

Hebben webservers slechts één website, of hebben ze meer?

Het antwoord

SuperUser-bijdrager Bob heeft het antwoord voor ons:

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

HTTP-aanvragen

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 in een IP-adres( indien nodig) in een proces dat bekend staat als naamomzetting. 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 met de opgegeven poort of standaard op poort 80 op dat IP-adres.

4. De browser verzendt een HTTP-verzoek. Voor HTTP / 1.1 ziet het er als volgt uit:

De hostheader is standaard en vereist in HTTP / 1.1.Het was niet opgegeven in de HTTP / 1.0-specificatie, maar sommige servers ondersteunen het toch.

Vanaf hier heeft de webserver verschillende gegevens die kunnen worden gebruikt 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 blokkeren / filteren)
• De aangevraagde poort, van de TCP-socket
• De gevraagde hostnaam, zoalsgespecificeerd in de hostheader door de browser in het HTTP-verzoek
• Het gevraagde pad
• Andere headers( cookies, etc.)

Zoals u waarschijnlijk gemerkt heeft, plaatst de meest gebruikte shared hosting-opstelling tegenwoordig meerdere websites op één IP-adres: poortcombinatie, waarbij alleen de host de kans krijgt om 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 de voorkeur geeft aan Virtual 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 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 zal dit certificaat vervolgens vergelijken met het domein dat het heeft aangevraagd.

Dit levert een probleem op. Hoe weet de webserver welk certificaat van een host / website 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 te weinig IPv4-adressen 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 is gelekte informatie. Dit wordt meestal als een acceptabele afweging beschouwd, aangezien de hostnaam normaal toch 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.

Heeft u 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 de volledige discussiethread hier.