Wanneer u voor het eerst leert hoe domeinnamen, IP-adressen, webservers en websites allemaal in elkaar passen en samenwerken, kan het een beetje verwarrend zijn of soms overweldigend. 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 vraag- en antwoordsessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een community-driven groep van Q & A-websites.

Foto's 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 een domeinnaam koppelen 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 kan dit dan allemaal worden opgelost zodat ik zonder problemen of verwisselingen de website kan openen?

Hebben webservers maar één website, of houden ze meer vast? ?

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 waarop kan worden gereageerd.

HTTP-aanvragen

Hier ziet u hoe uw typische HTTP-aanvraag gebeurt:

1.

De gebruiker geeft een URL op in de vorm // host: poort / pad. 2.

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 hostbestand op gewone besturingssystemen omzeilt bijvoorbeeld DNS). 3.

De browser opent een TCP-verbinding met de opgegeven poort of standaardinstellingen naar 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 spec, maar sommige servers ondersteunen het toch.

Vanaf hier heeft de webserver verschillende stukjes informatie die hij kan gebruiken om te beslissen wat de reactie zou moeten 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, vanuit de TCP-socket
• De aangevraagde hostnaam, zoals gespecificeerd in de hostheader door de browser in het HTTP-verzoek
• Het gevraagde pad
• Andere headers (cookies , enz.)
• Zoals je waarschijnlijk gemerkt hebt, plaatst de meest gebruikte shared hosting-opstelling tegenwoordig meerdere websites op één IP-adres: poortcombinatie, waardoor alleen de host tussen websites kan onderscheiden.

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 wordt ontvangen?

Traditioneel is dit opgelost door een speciaal IP-adres (of poort) te hebben voor elke website waarvoor HTTPS is vereist. Vanzelfsprekend is dit problematisch geworden omdat we geen IPv4-adressen meer hebben.

Voer SNI in (servernaamindicatie). 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 via alleen IP-adres aanvraagt?

Wat de webserver doet als deze 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 hier de volledige discussiethread

Hoe Free Music en Video Streaming van T-Mobile werkt

Gegevens zijn gegevens ... behalve wanneer dat niet het geval is. T-Mobile maakt het een beetje verwarrend door u een bepaalde hoeveelheid gegevens te geven en vervolgens onbeperkte muziek- en videostreaming toe te staan ​​die niet meetelt voor de vergoeding, maar alleen voor bepaalde services. De meeste T-Mobile-abonnementen bevatten deze functies Gebruikt u T-Mobile als uw mobiele provider?

(how-to)

Verrassing: Macs zijn niet noodzakelijk duurder dan Windows-pc's

De algemene wijsheid is dat Mac's duurder zijn dan Windows-pc's. Dit klopt, als je een Windows-laptop van $ 250 vergelijkt met een MacBook die begint bij $ 899. Maar gezien vergelijkbare hardware zijn Macs niet per se duurder dan pc's. Dit is eigenlijk vergelijkbaar met telefoons. Natuurlijk is een iPhone duurder dan goedkope Android- en Windows-telefoons, maar een iPhone is vergelijkbaar geprijsd met high-end Android-telefoons van bijvoorbeeld Samsung en HTC.

(how-to)