Share
I min tidligere artikkel dekket vi noen av HTTPs grunnleggende, for eksempel URL-ordningen, statuskoder og forespørsel / svarhodet. Med det som grunnlag, vil vi se på de finere aspektene ved HTTP, for eksempel tilkoblingshåndtering, autentisering og HTTP-caching. Disse emnene er ganske omfattende, men vi dekker de viktigste brikkene.
Det må etableres en tilkobling mellom klienten og serveren før de kan kommunisere med hverandre, og HTTP bruker den pålitelige TCP-transportprotokollen for å gjøre denne tilkoblingen. Som standard bruker webtrafikk TCP-port 80. En TCP-strøm er delt inn i IP-pakker, og det sikrer at disse pakkene alltid kommer i riktig rekkefølge uten å feile. HTTP er en applikasjonslagprotokoll over TCP, som er over IP.
HTTPS er en sikker versjon av HTTP, og legger inn et ekstra lag mellom HTTP og TCP som heter TLS eller SSL (henholdsvis Transport Layer Security eller Secure Sockets Layer). HTTPS kommuniserer via port 443 som standard, og vi vil se på HTTPS senere i denne artikkelen.
En HTTP-tilkobling er identifisert av
Serveren er ansvarlig for alltid å svare med de riktige overskriftene og svarene.
I HTTP / 1.0 ble alle tilkoblinger stengt etter en enkelt transaksjon. Så, hvis en klient ønsket å be om tre separate bilder fra samme server, gjorde det tre separate forbindelser til den eksterne verten. Som du ser fra diagrammet ovenfor, kan dette introdusere mange forsinkelser i nettverket, noe som resulterer i en suboptimal brukeropplevelse.
For å redusere forbindelses-etableringsforsinkelser, introduserte HTTP / 1.1 vedvarende forbindelser, Langlivede forbindelser som forblir åpne til klienten lukker dem. Vedvarende tilkoblinger er standard i HTTP / 1.1, og det å foreta en enkelt transaksjonsforbindelse krever at klienten stiller inn Tilkobling: Lukk be om header. Dette forteller at serveren skal lukke tilkoblingen etter å ha sendt svaret.
I tillegg til vedvarende forbindelser bruker nettlesere / klienter også en teknikk, kalt parallelle tilkoblinger, for å minimere forsinkelser i nettverket. Det eldgamle konseptet med parallelle tilkoblinger innebærer å skape et basseng av tilkoblinger (vanligvis på seks tilkoblinger). Hvis det er seks eiendeler som klienten trenger å laste ned fra et nettsted, gjør klienten seks parallelle tilkoblinger for å laste ned disse eiendelene, noe som resulterer i en raskere tilbakeslag. Dette er en stor forbedring over serielle tilkoblinger der klienten bare laster ned en ressurs etter at du har fullført nedlastingen for en tidligere ressurs.
Parallelle tilkoblinger, i kombinasjon med vedvarende tilkoblinger, er dagens svar for å minimere nettverksforsinkelser og skape en jevn opplevelse på klienten. For en grundig behandling av HTTP-tilkoblinger, se Tilkoblinger-delen av HTTP-spesifikasjonen.
Serveren lytter mest etter innkommende tilkoblinger og behandler dem når den mottar en forespørsel. Operasjonene innebærer:
Accentsconagua
Tilkobling: Lukk forespørselsoverskrift ble funnetSelvfølgelig er dette ikke en uttømmende liste over operasjoner. De fleste applikasjoner / nettsteder trenger å vite hvem som gjør en forespørsel for å skape mer tilpassede svar. Dette er riket til identifikasjon og godkjenning.
HTTP er en applikasjonslagprotokoll over TCP, som er over IP.
Det er nesten obligatorisk å vite hvem som kobler til en server for å spore en apps eller nettstedets bruk og de generelle samhandlingsmønstrene til brukerne. Forutsetningen for identifikasjon er å skreddersy svaret for å gi en personlig opplevelse; Naturligvis må serveren vite hvem en bruker er for å kunne tilby den funksjonaliteten.
Det er noen forskjellige måter en server kan samle inn denne informasjonen, og de fleste nettsteder bruker en hybrid av disse tilnærmingene:
Fra, Referer, Bruker agent - Vi så disse topptekstene i del 1.Cookies tillater at serveren legger til vilkårlig informasjon for utgående svar via Set-Cookie svar overskrift. En informasjonskapsel er satt med en eller flere name = verdi par skilt av semikolon (;), som i Set-Cookie: session-id = 12345ABC; username = nettuts.
En server kan også begrense informasjonskapslene til et bestemt domene og sti, og det kan gjøre dem vedholdende med en utløper verdi. Cookies sendes automatisk av nettleseren for hver forespørsel til en server, og nettleseren sikrer at bare domene- og sti-Spesifikke informasjonskapsler sendes i forespørselen. Forespørselsoverskriften Cookie: navn = verdi [; name2 = value2] brukes til å sende disse informasjonskapslene til serveren.
Den beste måten å identifisere en bruker på er å kreve at de registrerer seg og logger på, men implementeringen av denne funksjonen krever en viss innsats av utvikleren, samt brukeren.
Teknikker som OAuth forenkler denne typen funksjon, men det krever fortsatt brukerens samtykke for å kunne fungere riktig. Autentisering spiller en stor rolle her, og det er trolig den eneste måten å identifisere og verifisere brukeren på.
HTTP støtter en rudimentær form for godkjenning som kalles Grunnleggende godkjenning, så vel som sikrere Digest-godkjenning.
I grunnleggende godkjenning nekter serveren først og fremst klientens forespørsel med en WWW-Verifisere svarheader og a 401 Uautorisert statuskode. Ved å se denne overskriften, viser nettleseren en innloggingsdialog, som ber om et brukernavn og passord. Denne informasjonen sendes i et base-64 kodet format i Godkjenning be om header. Serveren kan nå validere forespørselen og gi tilgang hvis legitimasjonene er gyldige. Noen servere kan også sende en Autentisering-Info header med ytterligere autentiseringsdetaljer.
En følge av grunnleggende autentisering er Proxy-godkjenning. I stedet for en webserver blir autentiseringsutfordringen forespurt av en mellomliggende proxy. Fullmakten sender en Proxy-Verifisere header med a 407 Uautorisert statuskode. Til gjengjeld skal klienten sende legitimasjonene via Proxy-Authorization be om header.
Digest Authentication ligner Basic og bruker samme håndtrykksteknikk med WWW-Verifisere og Autorisasjon overskrifter, men Digest bruker en sikrere hashing-funksjon for å kryptere brukernavnet og passordet (vanligvis med MD5 eller KD-fordøyelsesfunksjoner). Selv om Digest Authentication skal være sikrere enn Basic, bruker nettsteder vanligvis Basic Authentication på grunn av det enkle. For å redusere sikkerhetsproblemene, er Basic Auth brukt i forbindelse med SSL.
HTTPS-protokollen gir en sikker tilkobling på nettet. Den enkleste måten å vite om du bruker HTTPS, er å sjekke nettleserens adressefelt. HTTPs sikre komponent innebærer å sette inn et lag av kryptering / dekryptering mellom HTTP og TCP. Dette er Secure Sockets Layer (SSL) eller forbedret Transport Layer Security (TLS).
SSL bruker en kraftig form for kryptering ved hjelp av RSA og public key-kryptering. Fordi sikre transaksjoner er så viktige på nettet, har en allestedsnærværende standardbasert Public Key Key Infrastructure (PKI) innsats for ganske en gang.
Eksisterende klienter / servere trenger ikke å endre måten de håndterer meldinger på, fordi det meste av det harde arbeidet skjer i SSL-laget. Dermed kan du utvikle webapplikasjonen din ved hjelp av Basic Authentication, og høst automatisk fordelene ved SSL ved å bytte til https: // protokoll. Men for å få webapplikasjonen til å fungere over HTTPS, må du ha et fungerende digitalt sertifikat utplassert på serveren.
Akkurat som du trenger ID-kort for å vise identiteten din, trenger en webserver et digitalt sertifikat for å identifisere seg. Sertifikater (eller "certs") utstedes av en sertifiseringsinstans (CA) og garanterer din identitet på nettet. CA er foresatte av PKI. Den vanligste formen for sertifikater er X.509 v3-standarden, som inneholder informasjon, for eksempel:
Når en klient gjør en forespørsel over HTTPS, forsøker den først å finne et sertifikat på serveren. Hvis certifikatet er funnet, forsøker det å verfiy det mot sin kjente liste over CA'er. Hvis det ikke er en av de oppgitte CA, kan det vise en dialog til brukerens advarsel om nettstedets certficate.
Når sertifikatet er bekreftet, er SSL-håndtrykk fullført og sikker overføring er i kraft.
Det er generelt avtalt at det å gjøre det samme arbeidet to ganger er sløsing. Dette er hovedprinsippet om begrepet HTTP-caching, en grunnleggende søyle for HTTP-nettverksinfrastrukturen. Fordi de fleste operasjonene er over et nettverk, hjelper en hurtigbuffer med å spare tid, kostnad og båndbredde, samt gi en bedre opplevelse på nettet.
Caches brukes på flere steder i nettverksinfrastrukturen, fra nettleseren til opprinnelsesserveren. Avhengig av hvor den befinner seg, kan en cache kategoriseres som:
Uansett hvor en cache er plassert, er prosessen med å opprettholde en cache ganske lik:
Selvfølgelig er serveren ansvarlig for alltid å svare med de riktige overskriftene og svarene. Hvis et dokument ikke er endret, skal serveren svare med en 304 ikke endret. Hvis den bufret kopien er utløpt, skal den generere et nytt svar med oppdaterte svarhodene og returnere med en 200 OK. Hvis ressursen slettes, skal den komme tilbake med 404 ikke funnet. Disse svarene hjelper til med å justere cachen og sørge for at uaktuelt innhold ikke holdes for lenge.
Parallelle tilkoblinger, i kombinasjon med vedvarende tilkoblinger, er dagens svar for å minimere nettverksforsinkelser.
Nå som vi har en følelse av hvordan en cache fungerer, er det på tide å se på forespørselen og svarhodene som aktiverer cache-infrastrukturen. Å holde innholdet friskt og oppdatert er et av de viktigste ansvarene for hurtigbufferen. For å holde den hurtigbufrede kopien konsistent med serveren, gir HTTP noen enkle mekanismer, nemlig Dokumentets utløp og Server Revalidation.
HTTP tillater en opprinnelsesserver å legge ved en utløpsdato til hvert dokument ved hjelp av Cache-Control og utløper respons overskrifter. Dette hjelper klienten og andre cache-servere å vite hvor lenge et dokument er gyldig og frisk. Cachen kan tjene kopien så lenge som alder av dokumentet er innen utløpsdato. Når et dokument utløper, må hurtigbufferen sjekke med serveren for en nyere kopi og oppdatere sin lokale kopi tilsvarende.
utløper er en eldre HTTP / 1.0 respons header som spesifiserer verdien som en absolutt dato. Dette er bare nyttig hvis serverklokkene synkroniseres med klienten, noe som er en forferdelig antakelse om å gjøre. Denne overskriften er mindre nyttig sammenlignet med nyere Cache-Control: maksimal alder = header introdusert i HTTP / 1.1. Her, max-age er en relativ alder, spesifisert i sekunder, fra det tidspunktet svaret ble opprettet. Dermed hvis et dokument skal utløpe etter en dag, bør utløpshovedet være Cache-Control: maksimal alder = 86400.
Når et hurtigbufret dokument utløper, må hurtigbufferen fornyes med serveren for å sjekke om dokumentet er endret. Dette kalles server fornyelse og fungerer som en spørringsmekanisme for foreldet-ness av et dokument. Bare fordi en bufret kopi er utløpt, betyr det ikke at serveren faktisk har nyere innhold. Revalidation er bare et middel for å sikre at hurtigbufferen forblir frisk. På grunn av utløpstidspunktet (som angitt i et tidligere serverrespons), trenger ikke hurtigbufferen å sjekke med serveren for hver enkelt forespørsel, og dermed spare båndbredde, tid og redusere nettverkstrafikken.
Kombinasjonen av dokumentutløp og serverrevalidering er en meget effektiv mekanisme, og gjør det mulig for distribuerte systemer å opprettholde kopier med en utløpsdato.
Hvis innholdet er kjent for ofte endring, kan utløpetiden reduseres, slik at systemene kan synkroniseres oftere.
Forhøyelsestrinnet kan oppnås med to typer forespørsler: If-Modified-Since og If-None-Match. Den tidligere er for datobasert validering mens sistnevnte bruker Entity-Tags (ETags), en hash av innholdet. Disse overskriftene bruker dato eller ETag-verdier oppnådd fra et tidligere serverrespons. I tilfelle If-Modified-Since, de Sist endret svar overskrift brukes til If-None-Match, det er den ETag svar overskrift.
Gyldighetsperioden for et dokument skal defineres av serveren som genererer dokumentet. Hvis det er en aviswebside, bør hjemmesiden utløpe etter en dag (eller noen ganger også hver time!). HTTP gir Cache-Control og utløper svar overskrifter for å angi utløp på dokumenter. Som nevnt tidligere, utløper er basert på absolutte datoer og ikke en pålitelig løsning for å kontrollere cachen.
De Cache-Control header er langt mer nyttig og har noen forskjellige verdier for å begrense hvordan klienter skal cache svaret:
Som en side, hvis serveren ikke sender noen Cache-Control overskrifter, er klienten fri til å bruke sin egen heuristiske utløpsalgoritme for å bestemme friskhet.
Cachability er ikke bare begrenset til serveren. Det kan også spesifiseres fra klienten. Dette gjør at klienten kan legge inn begrensninger på hva det er villig til å akseptere. Dette er mulig via det samme Cache-Control header, om enn med noen forskjellige verdier:
HTTP-caching er faktisk et veldig interessant emne, og det er noen svært sofistikerte algoritmer for å administrere hurtigbufret innhold. For en dypere titt på dette emnet, se Caching-delen av HTTP-spesifikasjonen.
Vår tur til HTTP begynte med grunnlaget for nettadressesystemer, statuskoder og forespørsel / responsoverskrifter. Basert på disse konseptene, så vi på noen av de finere områdene av HTTP, for eksempel tilkoblingshåndtering, identifikasjon og autentisering og caching. Jeg håper at denne turen har gitt deg en god smak for bredden til HTTP og nok poeng for å utforske denne protokollen videre..
