You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 36 Next »

TDAT2004 Datakommunikasjon med nettverksprogrammering

Oppgave 4 - HTTP/1.1

Knut Aasgaard Kirkhorn, Ingunn Sund og Nicole Uybengkee

 

Innholdsfortegnelse

1. Innledning

1.1 Hva er HTTP?

HyperText Transfer Protocol (HTTP) er applikasjonsprotokollen som kjører på applikasjonslaget. HTTP blir brukt til overføring av filer (html, tekst, bilder, lyd, video, mm.) på internett. Protokollen spesifiserer hvordan meldinger skal overføres mellom klient og tjener, og hvilke handlinger tjenere og nettlesere skal gjøre i respons til forskjellige operasjoner (HTTP-verb).


1.2 Historie

Ordet hypertext oppsto først i 1965 i Project Xanadu. Det var likevel Tim Berners-Lee og avdelingen hans i CERN som originalt var oppfinnere av WWW (“WorldWideWeb”), og derfor også oppfinnere av HTML (HyperText Markup Language) og HTTP. WWW ble først vist frem i 1989, men første versjon av HTTP, HTTP/0.9, kom først to år etter i 1991.

HTTP/0.9 var en enkel protokoll for å overføre ren tekst over internett. Denne versjonen av HTTP hadde et problem; den hadde bare GET-metoden. GET-metoden er metoden som brukes for å hente en ressurs. På grunn av dette problemet og flere andre mangler måtte man til med utvikling av flere metoder og en nyere versjon av HTTP. Dave Raggett ledet en gruppe kalt “HTTP Working Group” i 1995 og de utviklet flere operasjoner (verb), mer metainformasjon, sikkerhetsprotokoller og mer til HTTP-protokollen. HTTP/1.0 ble lagt ut som en RFC (request for comment) på IETF (Internet Engineering Task Force), med nummer 1945 i 1996. 

Den offisielle utgivelsen av HTTP/1.1 kom i 1997 og den ble raskt en standard for mange nettlesere. Denne versjonen hadde strengere krav enn HTTP/1.0 for å sikre pålitelig implementering av funksjonene. HTTP/1.1 ble definert i RFC 2098 i utgivelsesåret og forbedringer kom i RFC 2616 i 1999. [1][5]

2. Ønsket funksjonalitet

HTTP ble laget fordi man ikke hadde en annen protokoll for kommunikasjon mellom tjener og server som var bra for å overføre filer over internett på. Forskjellen fra andre protokoller for overføring av filer, for eksempel FTP og SMTP, er at HTTP-forbindelsen lukkes så snart alle filer er overført til klienten. Dette er positivt for HTTP siden nettsider ofte linker til andre nettsider som ligger på andre tjenere. Når en klient skal koble opp mot en ny tjener må det uansett opprettes en ny forbindelse.

Da HTTP/0.9 og HTTP/1.0 først ble laget så hadde man ikke funksjonalitet som inneholdt HTTP-verb, head, metainformasjon og lignende, og derfor lagde man HTTP/1.1 som inneholdt dette og mye mer. HTTP/1.1 støtter også vedvarende forbindelser i motsetning til 1.0, dette står det mer om under virkemåte.

HTTP/1.1 hadde strengere krav enn HTTP/1.0 for å sørge for bedre og sikrere implementering av funksjonene dens. Mangler i HTTP/1.1 er at alle forbindelsene blir sendt en og en, og må derfor sendes etter hverandre og derfor tar lengre tid å hente flere ting. I HTTP/2.0 er dette implementert og denne versjonen går derfor mye raskere. [1][6]


 
Forskjell på HTTP/1.1 og HTTP/2

 

3. Virkemåte

3.1 Funksjonalitet

En HTTP protokoll er en forespørsel/respons protokoll. Protokollen blir vanligvis initiert av en bruker, og den består av en forespørsel om å bli tilført til en ressurs på en opprinnelig tjener. Etter responsen blir forbindelsen frigitt.


Eksempel på klient/server kommunikasjon

Forespørselen inneholder en request-metode, URI og protokollversjon. Den inneholder også en MIME-melding med “request”-modifikasjoner, klientinformasjon og eventuelt body-innhold. Responsen fra tjeneren inneholder en statuslinje, protokollversjon og en suksess- eller feilkode. Den inneholder også en MIME-melding med serverinformasjon, entitet metainformasjon og eventuelt body-innhold. [1]


Eksempel på klient/server kommunikasjon

HTTP/1.1 støtter vedvarende forbindelser. Det betyr at klienten kan sende en forespørsel og motta svar, for å deretter sende flere forespørsler over samme TCP-forbindelse. TCP-forbindelsen blir dermed ikke frigjort etter hver forespørsel og svar, men kan brukes til flere over tid. Det er også mulig å sende flere enn bare en forespørsel før svar mottas, dette kalles HTTP-pipelining. Fordeler med varige forbindelser er at “overhead” blir redusert og det blir mindre kostnader for blant annet nettverk og systemressurser. [1]


Forskjell på HTTP/1.0, HTTP/1.1 (Persistent) og HTTP/1.1 (Pipelining)

 


Eksempel på vedvarende forbindelser (HTTP/1.1)

 

3.2 Sesjon

En HTTP-sesjon er en samling med forespørsler/responser mellom klienten og tjeneren. Klienten setter frem forespørselen og etablerer en TCP-kobling til en bestemt port på en tjener. HTTP-serveren venter og lytter hele tiden etter innkommende forespørsler på den aktuelle porten. Når forespørsler mottas, sender serveren en respons til klienten som inneholder den forespurte ressursen, eller eventuelt en feilmelding. [1][4]

 

3.3 Verb

HTTP definerer et sett av forespørsel-metoder som klienten kan bruke til å kommunisere med serveren. Selv om noen av de teknisk sett er substantiv, så kaller man de ofte bare HTTP-verb. [2]

Eksempler på HTTP-verb:

VerbBeskrivelse
GETBrukes for å hente en ressurs, for eksempel en HTML side eller en videofil.
HEADSamme som GET, men uten response-body. Dette kan være nyttig dersom du ønsker å spørre serveren om meta-informasjon uten å laste ned hele ressursen (f.eks hvor stor en videofil er).
POSTBrukes når man ønsker å opprette et objekt på serveren. For eksempel når man skriver en kommentar.
PUTBrukes når man ønsker å oppdatere et objekt serveren. PUT overskriver hele objektet med det objektet du sender med.
PATCHLikner på put, men skal kun brukes til å oppdatere utvalgte deler av et objekt på serveren.
DELETEBrukes når man ønsker å slette et objekt på serveren.
CONNECTBrukes til å opprette en forbindelse (eller tunnel) til serveren.
OPTIONSBrukes til å spørre om kommunikasjonsmulighetene som serveren støtter.
TRACESender et ‘ekko’ av forespørselen tilbake til tjeneren. Brukes vanligvis til debugging.

 

3.4 Autentisering

HTTP tilbyr ulike autentiseringsordninger som blant annet tilgangsautentisering, der “HTTP basic authentication” og “HTTP digest authentication” er de mest brukte. [6]

 

3.5 Statuskoder

Den første linjen til HTTP-responsen kalles statuslinjen og inneholder en statuskode med et tall og en årsakssetning. Årsakssetningen er med for at det skal være lettere for mennesker å forstå koden. User agenten kan håndtere statuskoden på forskjellige måter som avhenger av alvorlighetsgraden til koden. [1][2]

Eksempler på statuskoder:

StatuskodeTypeEksempel
1xxInformativ
100 Continue, 101 Switching Protocols
2xxSuksess
200 OK, 201 Created, 202 Accepted
3xxOmdirigering/videreføring
300 Multiple Choices, 301 Moved Permanently, 302 Found
4xxKlientfeil
400 Bad Request, 403 Forbidden, 404 Not Found,
422 Unprocessable Entity
5xx
Serverfeil
500 Internal Server Error, 503 Service Unavailable

 

3.6 HTTP 1.1

3.6.1 HTTP 1.1 Klient

For å etterkomme HTTP 1.1 standarden må klienter:

 

  • Inkludere host-headeren i hver request
  • Motta responser med “chunked”/oppdelt data
  • Enten støtte persistente tilkoblinger, eller inkludere connection-close-headeren i hver forespørsel
  • Håndtere “100 Continue” responser
3.6.1.1 Host-header

I HTTP 1.1 kan en server med en ip-addresse ha flere web-domener. For eksempel kan www.example.com og www.example2.com holde til på samme webserver. [6]

Hvert HTTP request må spesifisere host-name og port via host-headeren. Hvis port ikke er spesifisert brukes defaultporten, port 80. For eksempel:

GET /path/file.html HTTP/1.1
Host: www.example.com:80

 

3.6.1.2 Chunked Transfer-Encoding

Hvis en server ønsker å begynne å sende en respons uten å vite den totale lengden, kan den bruke “chunked transfer-encoding”. Den bryter responsen i mindre deler som inneholder binære data, og sender dem i en serie. Man kan identifisere slike responser fordi den inneholder  "Transfer-Encoding: chunked"-headeren.  Alle HTTP 1.1 klienter må kunne motta slike meldinger. [6]

En “chunked” respons kan se slik ut:

HTTP/1.1 200 OK
Date: Wed, 22 Feb 2017 22:22:22 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
  
1a; stuff-here
abcdefghijklmnopqrstuvwxyz
10
1234567890abcdef
0
some-footer: some-value

 

3.6.1.3 Persistente tilkoblinger og “Connection: close”-headeren

En stor forskjell mellom HTTP/1.1 og tidligere versjoner av HTTP er at persistente tilkoblinger er standard oppførsel for alle HTTP-tilkoblinger. Persistente tilkoblinger handler om å bruke en enkel TCP-tilkobling til å sende og motta flere forespørsler/responser, i motsetning til å åpne en ny tilkobling for hver enkel forespørsel/respons.

Hvis en klient setter "Connection: Close"-headeren i forespørselen, blir forbindelsen lukket etter at tjeneren sender responsen. Dette skal brukes hvis du ikke støtter persistente tilkoblinger, eller hvis du vet at forespørselen er den siste for forbindelsen. Tjeneren kan også sette denne headeren på en respons, og da skal klienten ikke kunne sende flere forespørsler gjennom den forbindelsen. [6]


3.6.1.4 “100 Continue”

Tjeneren har mottatt forespørselen, og klienten kan fortsette og sende forespørsel-bodyen. Å sende en full forespørsel med feilaktige headere kan være ineffektivt dersom det er snakk om mye data. Man kan da sjekke om headerene er riktig satt, og kun sende forespørsel-body dersom tjeneren svarer 100-Continue. Hvis tjeneren svarer "417 - Expectation failed" vet klienten at det ikke er noen grunn til å sende forespørsel-body, fordi noe er feil. [6]


3.6.2 HTTP 1.1 Tjener

For å etterkomme HTTP 1.1 standarden må tjenere

  • inkludere date-headeren i hver respons

  • støtte GET og HEAD metoder

  • støtte HTTP 1.0 forespørsler


3.6.2.1 Date-headeren

Caching er en viktig forbedring introdusert i HTTP 1.1, og er avhengig av at hver response blir tidsmerket. Date-headeren må være på formatet "Date: Sun, 12 Mar 2017 23:59:59 GMT". Alle responser utenom de i 100-rangen må inkludere date-headeren.


3.6.2.2 GET og HEAD metoder

 For å oppfylle HTTP 1.1 standarden, må serveren støtte minst GET og HEAD. Hvis en klient bruker en metode serveren ikke støtter, f.eks PUT til "http://example.com/books", skal serveren svare med "501 Not Implemented", f.eks:

HTTP/1.1 501 Not Implemented

 [blank line here]

 

3.6.2.3 Støtte av HTTP 1.0 requester

 HTTP 1.1 servere må også støtte HTTP 1.0 request (for å ta hensyn til gamle nettlesere). Hvis en request bruker HTTP 1.0 skal en server:

  • ikke krev Host: header, og

  • ikke sende "100 Continue" response.



4. Referanseliste 

4.1 Innhold

[1] Medlemmer av w3.org, microsoft og andre bedrifter, "RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1", Tools.ietf.org, 1999. URL: https://tools.ietf.org/html/rfc2616. [Besøkt: 21. Feb. 2017].

[2] T. Berners-Lee, "Design Issues for HTTP", W3.org, 1991. URL: https://www.w3.org/Protocols/DesignIssues.html. [Besøkt: 21. Feb. 2017].

[3] H. Frystyk Nielsen, "Classic HTTP Documents", W3.org, 1998. URL: https://www.w3.org/Protocols/Classic.html. [Besøkt: 21. Feb. 2017].

[4] T. Berners-Lee, "The HTTP Protocol As Implemented In W3", W3.org, 1991. URL: https://www.w3.org/Protocols/HTTP/AsImplemented.html. [Besøkt: 21. Feb. 2017].

[5] H. Frystyk Nielsen og J. Gettys, "Change History for HTTP", W3.org, 2004. URL: https://www.w3.org/Protocols/History.html. [Besøkt: 21. Feb. 2017]. 

[6] B. Krishnamurthy, J. Mogul og D. Kristol, "Key Differences between HTTP/1.0 and HTTP/1.1", Www8.org, 2002. URL: http://www8.org/w8-papers/5c-protocols/key/key.html. [Besøkt: 21. Feb. 2017].


4.2 Bilder

  • No labels