no.phhsnews.com


no.phhsnews.com / Når du først begynner å lære hvordan domenenavn, IP-adresser, webservere og nettsteder passer alle sammen og jobber sammen, kan det være litt forvirrende eller overveldende til tider. Hvordan er det satt opp for å fungere så jevnt? Dagens SuperUser Q & A-post har svar på spørsmål fra en nysgjerrig leser.

Når du først begynner å lære hvordan domenenavn, IP-adresser, webservere og nettsteder passer alle sammen og jobber sammen, kan det være litt forvirrende eller overveldende til tider. Hvordan er det satt opp for å fungere så jevnt? Dagens SuperUser Q & A-post har svar på spørsmål fra en nysgjerrig leser.


Foto Rosmarie Voegtli (Flickr).

Spørsmålet

SuperUser leser user3407319 vil vite om webservere bare har ett nettsted hver:

Basert på hva jeg forstår om DNS og kobler et domenenavn til IP-adressen til webserver et nettsted lagres på, betyr det at hver webserver kun kan holde ett nettsted? Hvis webservere holder mer enn ett nettsted, så hvordan blir det løst slik at jeg får tilgang til nettstedet jeg vil ha uten problemer eller blandingsoppdateringer?

Har webservere bare ett nettsted hver, eller holder de mer

Svaret

SuperUser-bidragsyter Bob har svaret for oss:

I utgangspunktet inneholder nettleseren domenenavnet i HTTP-forespørselen, slik at webserveren vet hvilket domene som ble forespurt og kan svare tilsvarende.

HTTP-forespørsler

Her er hvordan den typiske HTTP-forespørselen skjer:

1.

Brukeren gir en nettadresse, i form // vert: port / bane.

2. Den nettleseren trekker ut verten (domene) delen av nettadressen og oversetter den til en IP-adresse (om nødvendig) i en prosess kjent som navnoppløsning. Denne oversettelsen kan forekomme via DNS, men det behøver ikke (for eksempel vil den lokale vertsfilen på vanlige operativsystemer bypass DNS).

3. Nettleseren åpner en TCP-tilkobling til den angitte porten eller standardinnstillinger til port 80 på den IP-adressen.

4. Nettleseren sender en HTTP-forespørsel. For HTTP / 1.1 ser det slik ut:

Vertsoverskriften er standard og kreves i HTTP / 1.1. Det var ikke spesifisert i HTTP / 1.0-spesifikasjonen, men noen servere støtter det uansett. Herfra har webserveren flere biter av informasjon som den kan bruke til å bestemme hva svaret skal være. Merk at det er mulig for en enkelt webserver å være bundet til flere IP-adresser.

Den forespurte IP-adressen fra TCP-kontakten (klientens IP-adresse er også tilgjengelig, men dette brukes sjelden, og noen ganger for blokkering / filtrering)

Den forespurte porten, fra TCP-kontakten

  • Det forespurte vertsnavnet, som angitt i vertsoverskriften av nettleseren i HTTP-forespørselen
  • Den forespurte banen
  • Eventuelle andre overskrifter (informasjonskapsler , osv.).
  • Som du ser ut til å ha lagt merke til, setter de vanligste delte hostingoppsettene i disse dager flere nettsteder på en enkelt IP-adresse: portkombinasjon, slik at verten bare skiller mellom nettsteder.
  • Dette er kjent som en navnbasert virtuell vert i Apache-landet, mens Nginx kaller dem servernavn i serverblokker, og IIS foretrekker virtuell server.

Hva om HTTPS?

HTTPS er litt annerledes. Alt er identisk med etableringen av TCP-tilkoblingen, men etter det må en kryptert TLS-tunnel etableres. Målet er å ikke lekke noen informasjon om forespørselen.

For å bekrefte at webserveren faktisk eier dette domenet, må webserveren sende et sertifikat signert av en pålitelig tredjepart. Nettleseren vil da sammenligne dette sertifikatet med det domenet det ba om.

Dette presenterer et problem. Hvordan vet webserveren hvilket verts / nettstedets sertifikat du vil sende hvis det må gjøres før HTTP-forespørselen mottas?

Tradisjonelt ble dette løst ved å ha en dedikert IP-adresse (eller port) for hvert nettsted som krever HTTPS. Dette har tydeligvis blitt problematisk da vi løper ut av IPv4-adresser.

Skriv inn SNI (Server Name Indication). Nettleseren passerer nå vertsnavnet under TLS-forhandlingene, slik at webserveren har denne informasjonen tidlig nok til å sende riktig sertifikat. På webseresiden er konfigurasjonen svært lik HTTP-virtuelle verter er konfigurert.

Ulempen er at vertsnavnet nå er bestått som ren tekst før kryptering, og er i hovedsak lekket informasjon. Dette betraktes vanligvis som en akseptabel avvei, men vurderer at vertsnavnet er normalt eksponert i en DNS-spørring uansett.

Hva hvis du bare ber om et nettsted via IP-adresse?

Hva webserveren gjør når den ikke vet hvilken spesifikk vert du forespurt, avhenger av webserverens implementering og konfigurering. Vanligvis er det et "standard", "catch-all" eller "fall tilbake" -nettsted som er spesifisert som vil gi svar på alle forespørsler som ikke spesifikt angir en vert.

Denne standardwebsiden kan være sin egen uavhengige nettside ( ofte viser en feilmelding), eller det kan være noen av de andre nettstedene på webserveren, avhengig av webserveradministratorens preferanser.

Har du noe å legge til forklaringen? Lyder av i kommentarene. Vil du lese flere svar fra andre tech-savvy Stack Exchange-brukere? Se hele diskusjonstråden her.


Har du sikkert hørt at du alltid må bruke ikonet Trygg fjerning av maskinvare før du kobler fra en USB-enhet. Men det er også en god sjanse for at du har koblet fra en USB-enhet uten å bruke dette alternativet, og alt fungerte fint.

Har du sikkert hørt at du alltid må bruke ikonet Trygg fjerning av maskinvare før du kobler fra en USB-enhet. Men det er også en god sjanse for at du har koblet fra en USB-enhet uten å bruke dette alternativet, og alt fungerte fint.

Hurtig fjerning vs. Bedre ytelse Windows lar deg optimalisere USB-enheten din for rask fjerning eller forbedret ytelse. Som standard optimaliserer Windows USB-enheter for rask fjerning. Du kan få tilgang til denne innstillingen fra enhetsbehandleren. Åpne Start-menyen, skriv Enhetsbehandling, og trykk Enter for å starte den.

(how-to)

Slik sjekker du ruteren for skadelig programvare

Slik sjekker du ruteren for skadelig programvare

Forbrukerruter sikkerheten er ganske dårlig. Attackers utnytter mangelfulle produsenter og angriper store mengder rutere. Slik kontrollerer du om ruteren din er blitt kompromittert. Hjemmedatamarkedet er mye som Android-smarttelefonmarkedet. Produsenter produserer et stort antall forskjellige enheter og ikke plager å oppdatere dem, slik at de er åpne for å angripe.

(how-to)