HTTP:ta käytetään yleisesti sille varatullaporttilla 80 salaamattommaan liikenteeseen ja porttilla 443salattuun liikenteeseen. HTTP on sovellustason eliOSI-mallin seitsemännen kerroksen protokolla. Se ontilaton, eli jokainen pyyntö käsitellään erillään aikaisemmista pyynnöistä.
Vuonna1989CERN:illä työskennellytTim Berners-Lee teki esityksen internetin laajuisen hypertekstijärjestelmän rakentamista. Projektin nimi oli aluksi "Mesh", mutta myöhemmin se nimettiin uudelleen World Wide Webiksi sen toteutuksen aikana vuonna1990. Järjestelmä koostui neljästä osasta, jotka rakennettiin jo olemassaolevanTCP/IP -protokollan päälle, joista yksi oli "yksinkertainen protokolla, jolla voi jakaa näitä hypertekstidokumentteja" eli HTTP. WWW:n muut kolme osaa olivatHTML,WorldWideWeb (selain) jahttpd ("httpdaemon",WWW-palvelin).[9]
Ensimmäinen HTTP:n dokumentoitu versio julkaistiin vuonna 1991. Sillä ei ollut alun perin versionumeroa, mutta sitä alettiin kutsua myöhemmin versioksi 0.9, jotta se voitaisiin erottaa myöhemmistä versioista. Versio tuki vain GET-metodia, ja kaikki pyynnöt olivat yhden rivin pituisia. Palvelimen vastaukset olivat myös yksinkertaisia: ne sisälsivät pelkästään halutun HTML-tiedoston sisällön, eikä esimerkiksi kuvia ollut mahdollista välittää.[10]
Vuosina 1991-1995 ominaisuuksia lisättiin palvelin- ja selainkehittäjien toimesta "yritys ja erehdys"-taktiikalla, jolloin katsottiin saako uusi ominaisuus kannatusta. Yhteensopivuusongelmat olivat myös yleisiä. Toukokuussa1996 kirjoitettiin uusi dokumenttiRFC 1945, joka määritteli HTTP:n version 1.0.[11] Versiossa lisättiin tuki vastauksen onnistumis- ja virhekoodeille, otsaketiedoille (headers), PUT, DELETE, LINK ja UNLINK -metodeille ja muuntyyppisille tiedostoille kuin HTML otsakkeen Content-Type (sisällön tyyppi) johdosta. Ensimmäiselle riville lisättiin myös versionumero.[11]
Vuoden1994 lopullaNetscape-selain rakensi HTTP:n päälle salatun kuljetuskerroksen eli SSL:n (Secure Sockets Layer). Salattu yhteys mahdollisti ensimmäisetverkkokaupat. Vuonna 1999 SSL standardisoitiin (RFC 2246), ja se tunnetaan nykyään nimelläTLS (Transport Security Layer).
Versio HTTP/1.1 julkaistiin alkuvuodesta1997, vain muutama kuukausi version 1.0 julkaisun jälkeen. Versio julkaistiin dokumentissaRFC 2068 ja sen kehitys tapahtui yhtä aikaa HTTP 1.0:n kanssa. Versio lisäsi useita parannuksia edeltäjäänsä:[12]
TCP-yhteyttä voitiin käyttää uudelleen, joka säästää aikaa. Yhteyttä ei tarvitse enää avata useita kertoja, jotta voidaan näyttää samassa dokumentissa olevat upotetut tiedostot.
Protokollaa virtaviivaistettiin, mikä mahdollisti toisen pyynnön lähettämisen ennen kuin vastaus ensimmäiseen oli täysin lähetetty. Tämä laski kanssakäynninlatenssia.
Sisällön muodon (esim. kieli, enkoodaus, pakkaus ja tiedostomuoto) pyytäminen lisättiin.
Host-otsakkeen avulla yksiIP-osoite pystyy tarjoamaan useita eri verkkosivustoja käyttäjille verkkotunnuksen perusteella.
Uusia metodeja eli pyyntötyyppejä: OPTIONS, HEAD, POST, TRACE
Versiosta 1.0 tuotiin myös metodit PUT ja DELETE
Tuki pyynnön protokollan vaihdolle (Upgrade-otsake), jota hyödyntää esimerkiksiWebSocket-protokollan
Versiota HTTP/1.1 on päivitetty kaksi kertaa, ensin kesäkuussa 1999 dokumentissaRFC 2616 (kieliasua selkeytettiin ja mm. otsakkeiden ja virhekoodien käyttöä tarkennettiin) ja kesäkuussa 2014 dokumenteissaRFC 7230 (HTTP:n viestiformaatti) jaRFC 7235 (HTTP Basic-tunnistautuminen).
Yli viidentoista vuoden aikana verkkosivuista tuli monimutkaisempia ja tiedostokooltaan suurempia.Internet Engineering Task Forcen (IETF) HTTP-työryhmä julkaisi HTTP/2:n (työnimellä HTTP 2.0) toukokuussa 2015 (RFC 7540).[13]
HTTP/2-protokolla käyttää tiedonsiirrossa tekstin sijaanbinääriä ja se onmultipleksattu, jolloin pyyntöjä voidaan tehdä yhtä aikaa saman yhteyden yli. Se myöspakkaa otsakkeet, sillä ne sisältävät usein samaa tietoa.[13]
Versiossa ei tullut muutoksia protokollan käyttöön, vaan muutokset olivat pääasiassa nopeusparannuksia. Uusi versio otettiin käyttöön nopeasti ympäri maailmaa, sillä se ei vaatinut muutoksia verkkosivustoihin ja -sovelluksiin ja käyttäjiltä vaadittiin vain ajan tasalla ollut selain.[13] The Webmaster -julkaisun mukaan HTTP/2 on noin 14% nopeampi kuin edeltäjänsä.[14]
Suurin osa suosituista selaimista tukee versiota HTTP/2 vain salatun HTTPS-yhteyden yli.[15][16]
AikaisemminGoogle suunnitteli SPDY-protokollaa HTTP:n korvaajaksi, joka kuitenkin päätettiin hylätä HTTP/2:n tarjottua vastaavat edut.[13] SamallaTLS-protokollan laajennukseksi suunniteltu NPN hylättiin, koska samat hyödyt tarjosi IETF:n ALPN-laajennus.[13]
Kuvituskuva kahdesta QUIC-tietovirrasta kahden tietokoneen välillä, joista toisessa tieto voi kulkea samaan aikaan kun toinen on tukkeutunut.
HTTP:n uusin versio HTTP/3 käyttääTCP:n sijaanUDP-protokollaan pohjautuvaaQUIC-protokollaa. HTTP/2:n tapaan muutokset ovat pääasiassa nopeusparannuksia, eikä protokollaan käyttöön tullut muutoksia.[17]
HTTP/3 toimii nopeammin tilanteissa, joissa käyttäjä vaihtaa verkosta toiseen, esimerkiksi vaihtaessaanWiFi-verkosta mobiilidataan kotoa tai toimistolta lähdettäessä. QUIC-protokolla myös parantaa suorituskykyä tilanteissa joissapaketti ei saavuta päämääräänsä (packet loss), sillä tälläisesa tilanteessa HTTP/2:ssa kaikki muut paketit olisivat myös estyneet. HTTP/3:ssa tiedot lähetetään usean tietovirran (data stream) avulla, jonka ansiosta tieto voi jatkaa kulkemista muissa tietovirroissa kun yksi niistä on hetkellisesti tukkeutuneena. Muita hyötyjä ovat:
Yhteyden muodostaminen on nopeampaa, sillä QUIC salliiTLS-salausavainten vaihdon samaan aikaan muidenkättelyiden (handshake) kanssa.[18]
Kättelyvaihe (handshake) voidaan ohittaa kokonaan, mikäli asiakasohjelma on yhdistänyt samalle palvelimelle aikaisemmin ja yhteyden tiedot ovat välimuistissa.[18][19]
Kaikki yhteydet ovat ainaTLS-salattuja, eikä tarvetta erillisellesuojatulle protokollalle tai sen vaatimille ylimääräisille kättelyille ole enää.[20] Salaus kattaa myös pyyntöjen metatiedon.[18]
IETF muodosti QUIC-työryhmän vuonna 2016, joka kehitti projektia aluksi nimillä "HTTP-over-QUIC" ja "HTTP/2 Semantics Using The QUIC Transport Protocol".[18] Lokakuussa 2018 projektin nimeksi vaihdettiin HTTP/3 projektin, jotta se ymmärrettäisiin erottaa QUIC-protokollasta.[21] IETF julkaisi kesäkuussa 2022 HTTP/3:n standardiehdotuksen (RFC 9114).[17]
Tammikuussa 2024 HTTP/3:a tuki 28% kaikista verkkosivustoista,[22] sekä suurin osa suosituimmista selaimista paitsi Safari.[23]
HTTP:ta on muunneltu omiin tarpeisiin jo sen alkuajoilta lähtien. Sen päälle rakennettuja protokollia ovat muun muassaHTTPS,WebSocket jaSSE (engl.server-sent events).
HTTP:n otsakkeet mahdollistavat myös laajan muokattavuuden, ja osa kehittäjäyhteisön luomista otsikoista on myöhemmin standardisoitunut. Näitä ovat esimerkiksi DNT (engl.Do Not Track eli "älä seuraa") ja X-Frame-Options (upotettujen verkkosivujen hallintaan).
KentälläReferer selain kertoo sivulle, minkä sivun kautta kyseiselle sivulle on päädytty. Esimerkiksi palvelimelle kerrotaan, millähakukoneen haulla sivulle on päädytty ellei sitä erikseen ole selaimen asetuksissa kielletty. Selain kertoo myös palvelimelle nimensä ja versionsa. Muut tiedot ovat lähinnä teknisiä ja kertovat minkä muotoisia tiedostoja selain osaa käsitellä ja millä kielellä käyttäjä mieluiten haluaisi sivua lukea.
Vanhempi HTTP 1.0 -protokolla vaati vain itse pyynnön, mutta HTTP 1.1 -protokollassa on määritettävä myösHost-otsake, joka kertoo palvelimen, johon selainuskoo ottavansa yhteyttä. Täten oikeasti samanIP-osoitteen takaa voikin löytyä useita www-sivuja, jotka palvelin lähettää aina kulloisenkin annetun host-otsakkeen perusteella. Tällaisia palvelimia kutsutaanWWW-näennäispalvelimiksi.kenen mukaan?
HTTP/1.1 200 OK Date: Tue, 06 Jul 2004 17:59:22 GMT Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: private, must-revalidate Via: 1.0 cthulhu Server: Apache/1.3.29 (Unix) PHP/4.3.4 X-Powered-By: PHP/4.3.4 Set-Cookie: fiwikiSession=a8015bd32eee4e5bd46fd83aea40f159; path=/ Vary: Accept-Encoding,Cookie Content-Language: fi Content-Type: text/html; charset=utf-8 X-Cache: MISS from wikipedia.org Transfer-Encoding: chunked Connection: keep-alive <!DOCTYPE html> ...
Vastauksessa pyyntöön välitetään ensimmäisenä HTTP-versio ja vastauksentilakoodi (tässä tapauksessa 200 OK), joka kertoo pyynnön onnistumisesta tai virheestä. Tämän jälkeen seuraa otsaketiedot (headers), jotka on eroteltu rivinvaihdolla. Kentän nimi ja arvo erotellaan tuplapisteellä.
Otsakkeista välittyy esimerkiksi dokumentin tyyppi (MIME-tyyppinä, esimerkissäHTML,UTF-8-merkistökoodauksella) ja sisällön kieli (suomi). VastauksenExpires-otsakkeen arvo (voimassaoloaika) onUnix-järjestelmän ajan alkuhetki vuonna 1970, mikä tarkoittaa, että sivu vanhenee välittömästi, eikä sitä pidä tallentaa välipalvelimeen uudelleen käytettäväksi. Tähän voi olla useita syitä. Esimerkiksi pyyntö oli sivun muokkausta varten, eikä vanhentuneen sisällön käsittely enää tulevaisuudessa ole järkevää tai käyttäjä voi olla kirjautunut tunnuksellaan, jolloin sivua ei voi näyttää muille käyttäjille. OtsakeCache-Control kertoo saman asian, mutta tarkemmin.
OtsakkeenSet-Cookie avulla voidaan pyytää selainta tallentamaaneväste (cookie), jonka se palauttaa palvelimelle seuraavan pyynnön yhteydessä omassaCookie-otsakkeessa.
Otsaketietodot päättyvät kahteen rivinvaihtoon (tai tyhjään riviin). Tämän jälkeen palvelin lähettää varsinaisen näytettävän sisällön.
GET onmetodi, jolla luetaan yksittäinen sivu tai resurssi. HTTP määrittelee kuitenkin muitakin metodeja (vaikka valtaosa liikenteestä käyttää vain GET-metodia); erityisesti GET on määriteltyidempotentiksi, jolloin peräkkäisten, identtisten GET-pyyntöjen pitäisi tuottaa aina sama tulos. Toinen käytetty metodi on POST, jolla välitetään palvelimelle muun muassa selaimessa muokattavien tekstikenttien (lomakkeiden) sisällöt. POST ei ole idempotentti, joten useimpien järjestelmän tilaa muuttavien kutsujen tulisi käyttää sitä GETin sijaan. HEAD-metodilla voidaan pyytää pelkät otsikkokentät ilman sivun sisältöä. Tätä käytetään esimerkiksi tarkistettaessa onko dokumentti muuttunut sitten viime kerran siirtämättä sitä kokonaan. CONNECT-metodia käytetään taas salattujen (HTTPS) yhteyksien kanssa. Muita metodeita on harvoin edes toteutettu WWW-palvelimeen, ellei samalla tueta myösWebDAV-laajennuksia.
GET - käytetään resurssin hakua varten (esimerkiksi verkkosivun hakuun)
POST - esimerkiksi täytetyn lomakkeen tietojen lähettäminen palveluun
OPTIONS - kysely palvelimen tai resurssin ominaisuuksista
HEAD - pyydä vain sivun otsikkotiedot (esimerkiksi hakukone selvittää onko sivu muuttunut)
PUT - sivun tallettaminen (käytetään harvoin ilmanWebDAV-laajennuksia)
DELETE - sivun poistaminen (käytetään harvoin ilmanWebDAV-laajennuksia)
TRACE - palauttaa pyynnön sellaisenaan (vikojen jäljitykseen)
Palvelin palauttaa onnistuneeseen sivunhakuun (edellä) vastauksena ensimmäisenä "HTTP/1.1 200 OK". Tämä kertoo protokollan versionumeron ja koodi "200" kertoo pyynnön onnistuneen (selväkielisenä "OK"). Statuskoodeista 2xx-alkuiset kertovat onnistuneesta pyynnöstä. Näistä tärkeimpiä ovat 200 eli OK ja 206 "Partial Content", joka kertoo vastauksen olevan osa pyydetty osa tiedostoa (pyydettäessä osaa suuremmasta tiedostosta).
3xx-alkuiset koodit kertovat sisällön löytyvän jostain muualta kuin selain pyysi. Koodi 301 "Moved Permanently" kertoo sivun siirtyneen pysyvästi ja 302 "Moved Temporarily" väliaikaisesti toiseen paikkaan.
4xx-alkuiset vastauskoodit kertovat asiakasohjelman (selaimen) tekemästä virheestä. Esimerkiksi 404 "Not Found" on tuloksena, jos haetaan sivua, jota palvelimella ei ole ja 403 "Forbidden", ettei hakijalla ole oikeutta dokumenttiin pääsyyn.
5xx-alkuiset koodit ovat palvelimen tekemien virheiden seurausta. Näistä yleisin on 500 "Internal Server Error", joka kertoo pyynnön epäonnistuneen sitä käsittelevän ohjelman kaaduttua tai palvelimen muun virheellisen toiminnan seurauksena.
Vastauskoodeja käytetään verrattain vähän, vaikka niiden avulla voitaisiin toteuttaa monia hyviä ominaisuuksia, esimerkiksi www-selain voisisopivan vastauskoodin saadessaan tietää, että URL ei ole enää olemassa, mutta että se löytyy annetusta osoitteesta ja päivittää automaattisesti kirjanmerkin uutta vastaavaksi.
HTTP on normaalistitilaton. Tämä tarkoittaa, ettei seuraavan pyynnön tulos riipu mitenkään edellisen tuloksesta ja kaikki asiakkaat saavat saman tuloksen samalla pyynnöllä. Tämä on kuitenkin melko rajoitettua, koska esimerkiksi verkkokaupan ostoskori tai kirjautuminen käyttäjätunnuksella foorumille olisivat mahdottomia tilattomalla protokollalla.
Käyttäjienistuntojen (session) toteuttamiseen HTTP:ssä on useita keinoja. Luotettavimmat näistä liittyvätevästeiden (cookie) käyttöön. Tällöin palvelin asettaa asiakasohjelmalle evästeenSet-Cookie-kentällä pyynnön yhteydessä. Vastaavasti palvelimelle luodaan ja pidetään muistissa istuntoon liittyvä tieto. Istunnon voisi muodostaa luottamalla pelkästään evästeiden välittämään tietoon, mutta tämä on usein hankalaa jamahdollisesti tietoturvariski. Tietoturvan ylläpitämiseksi istunto sidotaan myös käyttäjän IP-osoitteeseen, johon luottaminen ainoana istunnon tunnisteena on epävarmaa (mm. siksi, että usea eri käyttäjä voi hakea sivuja saman IP-osoitteen takaa. Katsoosoitteenmuunnos) Myös evästeisiin luottaminen on suhteellisen epävarmaa, koska niille varattu tila on rajattu ja monet käyttäjät estävät ainakin epämääräisten evästeiden käytön. Istuntoon liittyvä tilatieto voidaan välittää myösURL:n yhteydessä parametrina, mutta sekin on ongelmallista väärin toteutettuna. Vastaavasti palvelimen kapasiteetti on rajallinen, joten vanhoja ja käyttämättömiä istuntoja on siivottava pois tietyin väliajoin, mikä saa liian kauan käyttämättömä olevan istunnon katkeamaan.
HTTP-protokollalle on varattuTCP-portti 80. Toinen varattu, mutta harvoin käytetty, portti on 8080. Toisaalta portti 8080 on monien verkkosovelluspalvelimien, kutenTomcatin,JBossin jaGlassfishin oletusportti. Portin 8080 käyttö on niin ikään yleistä testiympäristöissä.
