Share
I det første kapitlet snakket vi om ressurser, men mest fokusert på nettadresser og hvordan du tolker en URL. Imidlertid er ressursene midtpunktet for HTTP. Nå som vi forstår HTTP-meldinger, metoder og tilkoblinger, kan vi gå tilbake for å se på ressurser i et nytt lys. I dette kapitlet skal vi snakke om den sanne essensen av å jobbe med ressurser når vi arkiverer webapplikasjoner og webtjenester.
Selv om det er lett å tenke på en webressurs som en fil på en webserveres filsystem, tenker man på denne måten, respekterer den virkelige evnen til ressursabstraksjonen. Mange nettsider krever fysiske ressurser på et filsystem - JavaScript-filer, bilder og stilark. Men forbrukere og brukere av nettet bryr seg ikke mye om disse bakgrunnsressursene. I stedet bryr de seg om ressurser de kan kommunisere med, og enda viktigere ressurser de kan nevne. Ressurser som:
Alle disse ressursene er typer av ressurser vi bygger applikasjoner rundt, og det vanlige temaet i listen er hvordan hvert element er betydelig nok til å identifisere og navngi. Hvis vi kan identifisere en ressurs, kan vi også gi ressursen en nettadresse for at noen skal finne ressursen. En nettadresse er en nyttig ting å ha rundt. Gitt en nettadresse kan du selvfølgelig finne en ressurs, men du kan også gi nettadressen til noen andre ved å legge inn nettadressen i en hyperkobling eller sende den i en epost.
Men det er mange ting du ikke kan gjøre med en nettadresse. Snarere er det mange ting en nettadresse ikke kan gjøre. For eksempel kan en URL ikke begrense klienten eller serveren til en bestemt type teknologi. Alle snakker HTTP. Det spiller ingen rolle om klienten din er C ++ og din webapplikasjon er i Ruby.
En URL kan heller ikke tvinge serveren til å lagre en ressurs ved hjelp av en bestemt teknologi. Resursen kan være et dokument på filsystemet, men et webramme kan også svare på forespørselen for ressursen og bygge ressursen ved hjelp av informasjon lagret i filer, lagret i databaser, hentet fra webtjenester eller utlede ressursen fra gjeldende tid på dagen.
En nettadresse kan ikke engang spesifisere representasjonen av en bestemt ressurs, og en ressurs kan ha flere representasjoner. Som vi lærte tidligere, kan en klient be om en bestemt representasjon ved hjelp av overskrifter i HTTP-forespørselen. En klient kan be om et bestemt språk eller en bestemt innholdstype. Hvis du noen gang har jobbet med en webapplikasjon som gjør det mulig for innholdsforhandlinger, har du sett fleksibiliteten til ressurser i aksjon. JavaScript kan be om pasient 123-data i JSON-format, C # kan be om samme ressurs i XML-format, og en nettleser kan be om dataene i HTML-format. De jobber alle med samme ressurs, men bruker tre forskjellige representasjoner.
Det er enda en ting en nettadresse ikke kan gjøre - det kan ikke si hva en bruker vil gjøre med en ressurs. En nettadresse sier ikke om jeg vil hente en ressurs eller redigere en ressurs. Det er jobben i HTTP-forespørselsmeldingen for å beskrive denne intensjonen ved å bruke en av HTTP-standardmetodene. Som vi snakket om i del 2 av denne sesjonen, er det et begrenset antall standard HTTP-metoder, inkludert FÅ, POST, SETTE, og SLETT.
Når du begynner å tenke på ressurser og nettadresser som vi er i dette kapitlet, begynner du å se på nettet som en del av søknaden din og som et fleksibelt arkitektonisk lag du kan bygge på. For mer innblikk i denne tankegangen, se Roy Fieldings berømte avhandling med tittelen "Arkitektoniske stiler og utformingen av nettverksbaserte programvarearkitekturer". Denne avhandlingen er papiret som introduserer arkitekturens representativ tilstandsoverføring (REST) og går i større detalj om ideene og konseptene i denne delen og den neste. Artikkelen finnes på http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
Så langt har vi vært fokusert på en nettadresse kan ikke gjøre det, når vi bør være fokusert på hvilken URL-adresse kan gjøre. Eller rettere fokus på hva en nettadresse og HTTP kan gjøre, fordi de jobber vakkert sammen. I sin avhandling beskriver Fielding fordelene ved å omfavne HTTP. Disse fordelene inkluderer skalerbarhet, enkelhet, pålitelighet og løs kobling. HTTP tilbyr disse fordelene delvis fordi du kan tenke på en nettadresse som en peker eller en enhet for indirection mellom en klient og et serverprogram. Igjen dikter nettadressen ikke en bestemt ressursrepresentasjon, teknologiimplementering eller klientens intensjon. I stedet kan en klient uttrykke ønsket intensjon og representasjon i en HTTP-melding.
En HTTP-melding er en enkel, ren tekstmelding. Den vakre HTTP-meldingen er hvor både forespørselen og svaret er helt selvbeskrivende. En forespørsel inkluderer HTTP-metoden (hva kunden ønsker å gjøre), banen til ressursen og tilleggsoverskrifter som gir informasjon om ønsket representasjon. Et svar inkluderer en statuskode for å indikere resultatet av transaksjonen, men inkluderer også overskrifter med hurtigbufferinstruksjoner, innholdstypen til ressursen, ressursens lengde og muligens andre verdifulle metadata.
Fordi all informasjon som kreves for en transaksjon, finnes i meldingene, og fordi informasjonen er synlig og lett å analysere, kan HTTP-applikasjoner stole på et antall tjenester som gir verdi som en melding flytter mellom klientprogrammet og serverprogrammet.
Ettersom en HTTP-melding beveger seg fra minnestrekningen i en prosess på en maskin til minnesplassen i en prosess på en annen maskin, kan den bevege seg gjennom flere deler av programvare og maskinvare som inspiserer og muligens endrer meldingen. Et godt eksempel er selve webserverprogrammet. En webserver som Apache eller IIS vil være en av de første mottakerne av en innkommende HTTP-forespørsel på en servermaskin, og som en webserver kan den sende meldingen til riktig søknad.
Webserveren kan bruke informasjon i en melding, som nettadressen eller vertsoverskriften, når du bestemmer hvor du skal sende en melding. Serveren kan også utføre flere handlinger med meldingen, som å logge meldingen til en lokal fil. Programmene på serveren trenger ikke å bekymre seg for logging fordi serveren er konfigurert til å logge alle meldinger.
På samme måte, når et program oppretter en HTTP-svarmelding, har serveren muligheten til å samhandle med meldingen på vei ut. Igjen kan dette være en enkel loggoperasjon, men det kan også være en direkte modifikasjon av selve meldingen. For eksempel kan en server vite om en klient støtter gzip-komprimering, fordi en klient kan annonsere dette faktum gjennom en Accept-Encoding header i HTTP-forespørselen. Komprimering gjør det mulig for en server å ta en 100-KB ressurs og gjøre den til en 25-kB ressurs for raskere overføring. Du kan konfigurere mange webservere til å automatisk bruke komprimering for bestemte innholdstyper (vanligvis teksttyper), og dette skjer uten at selve programmet bekymrer seg om komprimering. Komprimering er en tilleggsverdi som leveres av selve webserverprogramvaren.
Programmer trenger ikke å bekymre seg for å logge HTTP-transaksjoner eller komprimering, og dette er alt takket være de selvbeskyttende HTTP-meldingene som tillater andre deler av infrastrukturen å behandle og transformere meldinger. Denne typen behandling kan skje når meldingen beveger seg over nettverket også.
EN proxy-server er en datamaskin som sitter mellom en klient og en server. En proxy er mest mulig gjennomsiktig for sluttbrukere. Du tror du sender HTTP-forespørsler direkte til en server, men meldingene går faktisk til en proxy. Proxyen aksepterer HTTP-forespørsler fra en klient og videresender meldingene til den ønskede serveren. Proxyen tar da serverresponsen og sender svaret tilbake til klienten. Før du videresender disse meldingene, kan proxyen inspisere meldingene og muligens ta noen ekstra handlinger.
En av klientene jeg jobber for bruker en proxy-server for å fange all HTTP-trafikk som forlater kontoret. De ønsker ikke at ansatte og entreprenører tilbringer all sin tid på Twitter og Facebook, så HTTP-forespørsler til de serverne vil aldri nå deres reisemål, og det er ingen tweeting eller Farmville på kontoret. Dette er et eksempel på en populær rolle for proxy-servere, som skal fungere som en tilgangskontrollenhet.
En proxy-server kan imidlertid være mye mer sofistikert enn å bare slippe meldinger til bestemte verter. En enkel brannmur kan utføre denne plikten. En proxy-server kan også inspisere meldinger for å fjerne konfidensielle data, for eksempel Referer overskrifter som peker på interne ressurser på bedriftsnettverket. En tilgangskontrollproxy kan også logge HTTP-meldinger for å opprette revisjonsstier på all trafikk. Mange tilgangskontrollpersoner krever brukerautentisering, et emne som vi ser på i neste artikkel.
Den proxy som jeg beskriver i det forrige avsnittet er det vi kaller a videre proxy. Forward proxy er vanligvis nærmere klienten enn serveren, og fremadrettede proxyer krever vanligvis en konfigurasjon i klientprogramvaren eller nettleseren for å jobbe.
EN omvendt proxy er en proxy-server som er nærmere serveren enn klienten, og er helt gjennomsiktig for klienten.
Fremover og omvendt fullmakter Begge typer proxyer kan tilby et bredt spekter av tjenester. Hvis vi går tilbake til gzip-kompresjonsscenariet, snakket vi om tidligere, en proxy-server har muligheten til å komprimere svarmeldingsorganer. Et selskap kan bruke en omvendt proxy-server for komprimering for å ta beregningsbelastningen av webserverne der applikasjonen lever. Nå må ikke applikasjonen eller webserveren bekymre seg om komprimering. I stedet er komprimering en funksjon som er lagdelt inn via en proxy. Det er skjønnheten i HTTP.
Noen andre populære proxy-tjenester inkluderer følgende.
Lastbalansering proxyer kan ta en melding og videresende den til en av flere webservere på round-robin-basis, eller ved å vite hvilken server som for øyeblikket behandler det minste antall forespørsler.
SSL-akselerasjon proxyer kan kryptere og dekryptere HTTP-meldinger, og ta kryptering av en webserver. Vi snakker mer om SSL i neste kapittel.
Proxies kan gi et ekstra lag av sikkerhet ved å filtrere ut potensielt farlige HTTP-meldinger. Spesielt meldinger som ser ut til at de kan prøve å finne en sårbarhet på tvers av nettstedskripting (XSS) eller starte et SQL-injeksjonsangrep.
Caching proxyer kan lagre kopier av ofte brukte ressurser og svare på meldinger som ber om disse ressursene direkte. Vi vil gå nærmere på caching i neste avsnitt.
Endelig er det verdt å påpeke at en proxy ikke behøver å være en fysisk server. Fiddler, et verktøy som er nevnt i forrige kapittel, er en HTTP-debugger som lar deg fange og inspisere HTTP-meldinger. Fiddler fungerer ved å fortelle Windows å videresende all utgående HTTP-trafikk til port 8888 på IP-adresse 127.0.0.1. Denne IP-adressen er loopback-adressen, noe som betyr at trafikken bare går direkte til den lokale maskinen der Fiddler nå lytter på port 8888. Fiddler tar HTTP-forespørselen, logger den, videresender den til destinasjonen og tar også inn svaret før videresending svaret på den lokale søknaden. Du kan se proxy-innstillingene i Internet Explorer (IE) ved å gå til Verktøy, Internett instillinger, klikke på tilkoblinger kategorien, og klikk deretter på LAN-innstillinger knapp. Under Proxy-server område, klikk på Avansert knappen for å se proxy-serverens detaljer.
Proxy-innstillinger i Internet Explorer Proxies er et perfekt eksempel på hvordan HTTP kan påvirke arkitekturen til et webapplikasjon eller nettsted. Det er mange tjenester du kan lagre inn i nettverket uten å påvirke programmet. Den ene tjenesten vi vil undersøke mer detaljert, er caching.
Caching er en optimalisering laget for å forbedre ytelsen og skalerbarheten. Når det er flere forespørsler om samme ressursrepresentasjon, kan en server sende samme byte over nettverket gang på gang for hver forespørsel. Eller en proxy-server eller en klient kan cache representasjonen lokalt og redusere mengden tid og båndbredde som kreves for full gjenfinning. Caching kan redusere ventetiden, bidra til å hindre flaskehalser, og la et nettapplikasjon overleve når hver bruker kommer opp på en gang for å kjøpe det nyeste produktet eller se den siste pressemeldingen. Caching er også et godt eksempel på hvordan metadataene i HTTP-meldingshodene letter flere lag og tjenester.
Det første du må vite er at det finnes to typer cacher.
EN offentlig cache er en cache delt mellom flere brukere. En offentlig cache ligger vanligvis på en proxy-server. En offentlig cache på en proxy-proxy kaster vanligvis de ressursene som er populære i et fellesskap av brukere, som brukerne av et bestemt selskap, eller brukerne av en bestemt Internett-leverandør. En offentlig cache på en omvendt proxy kaster vanligvis ressursene som er populære på et bestemt nettsted, som populære produktbilder fra Amazon.com.
EN privat cache er dedikert til en enkelt bruker. Nettlesere behold alltid en privat buffer for ressurser på disken din (disse er "Midlertidige Internett-filer" i IE, eller skriv inn about: cache i adresselinjen til Google Chrome for å se filer i Chrome's private cache). Alt en nettleser har cached på filsystemet kan vises nesten umiddelbart på skjermen.
Reglene om hva du skal cache, når du skal cache, og når du skal ugyldiggjøre et cache-element (det vil si, sparke det ut av hurtigbufferen), er dessverre komplisert og kjempet av noen eldre oppføringer og inkompatible implementeringer. Likevel vil jeg forsøke å påpeke noen av tingene du bør vite om caching.
I HTTP 1.1, en svarmelding med en 200 (OK) statuskode for en HTTP FÅ forespørselen er cacheable som standard (det betyr at det er lovlig for proxy og klienter å cache svaret). Et program kan påvirke denne standarden ved å bruke de riktige overskriftene i en HTTP-respons. I HTTP 1.1 er denne overskriften den Cache-Control header, selv om du også kan se en utløper header i mange meldinger også. De utløper header er fortsatt rundt og støttes på tross av at de blir avskrevet i HTTP 1.1. Pragma er et annet eksempel på en header som brukes til å kontrollere cachingadferd, men det er egentlig bare rundt for bakoverkompatibilitet. I denne boken vil jeg fokusere på Cache-Control.
En HTTP-respons kan ha en verdi for Cache-Control av offentlig, privat, eller no-cache. En verdi på offentlig betyr at offentlige proxy-servere kan cache svaret. En verdi på privat betyr at bare nettleseren kan cache svaret. En verdi på no-cache betyr at ingen burde cache svaret. Det er også en no-butikken verdi, noe som betyr at meldingen kan inneholde sensitiv informasjon og ikke bør fortsette, men bør fjernes fra minnet så snart som mulig.
Hvordan bruker du denne informasjonen? For populære delte ressurser (som hjemmesidenes logo-bilde), vil du kanskje bruke en offentlig cache control directive og tillate alle å cache bildet, selv proxy servere.
For svar til en bestemt bruker (som HTML for hjemmesiden som inneholder brukerens navn), vil du bruke et privat bufferdirektiv.
Merk: I ASP.NET kan du kontrollere disse innstillingene via Response.Cache.
En server kan også spesifisere a max-age verdi i Cache-Control. De max-age verdien er antall sekunder for å cache svaret. Når disse sekundene utløper, bør forespørselen alltid gå tilbake til serveren for å hente en oppdatert respons. La oss se på noen eksempler på svar.
Her er en delvis respons fra Flickr.com for en av Flickr CSS-filene.
HTTP / 1.1 200 OK Sist endret: ons, 25 jan 2012 17:55:15 GMT Utløper: lør, 22 jan 2022 17:55:15 GMT Cache-kontroll: max-alder = 315360000, offentlig
Legg merke til Cache-Control gjør at offentlige og private caches kan cache filen, og de kan holde den rundt i mer enn 315 millioner sekunder (10 år). De bruker også en utløper header for å gi en bestemt utløpsdato. Hvis en klient er HTTP 1.1 kompatibel og forstår Cache-Control, det skal bruke verdien i max-age i stedet for utløper. Merk at dette ikke betyr at Flickr planlegger å bruke samme CSS-fil i 10 år. Når Flickr endrer sin design, vil den nok bare bruke en annen URL for sin oppdaterte CSS-fil.
Svaret inneholder også a Sist endret header for å indikere når representasjonen sist ble endret (som kanskje bare er tidspunktet for forespørselen). Cache-logikk kan bruke denne verdien som en validator, eller en verdi klienten kan bruke til å se om den cachede representasjonen fortsatt er gyldig. For eksempel, hvis agenten bestemmer seg, må den sjekke ressursen den kan utstede følgende forespørsel.
GET ... HTTP / 1.1 Hvis-Modifisert-siden: ons, 25 jan 2012 17:55:15 GMT
De If-Modified-Since header forteller serveren klienten trenger bare full respons hvis ressursen er endret. Hvis ressursen ikke er endret, kan serveren svare med en 304 ikke endret budskap.
HTTP / 1.1 304 Ikke endret Utløper: Lør, 22 Jan 2022 17:16:19 GMT Cache-Control: maksimal alder = 315360000, offentlig
Serveren forteller klienten: Gå videre og bruk bytesene du allerede har bufret.
En annen validator du vanligvis ser er ETag.
HTTP / 1.1 200 OK Server: Apache Senest endret: Fre, 06 Jan 2012 18:08:20 GMT ETag: "8e5bcd-59f-4b5dfef104d00" Innholdstype: tekst / xml Varighet: Godta-kodende innholdskoding: gzip innhold -Lengde: 437
De ETag er en ugjennomsiktig identifikator, som betyr at den ikke har noen inneboende betydning. en ETag Opprettes ofte ved hjelp av en hashing-algoritme mot ressursen. Hvis ressursen noen gang endres, beregner serveren en ny ETag. En cache-oppføring kan valideres ved å sammenligne to ETags. Hvis ETags er de samme, ingenting har endret seg. Hvis ETags er forskjellige, det er på tide å ugyldiggjøre hurtigbufferen.
I dette kapittelet dekket vi noen arkitektonisk teori samt praktiske fordeler med HTTP-arkitektur. Muligheten til lag caching og andre tjenester mellom en server og klient har vært en drivkraft bak suksessen til HTTP og nettet. Synligheten til de selvbeskrevne HTTP-meldingene og indireksjonen som tilbys av nettadresser, gjør det mulig. I neste kapittel snakker vi om noen av emnene vi har skørt rundt, emner som autentisering og kryptering.
Accentsconagua