Protokollen som blir brukt for overføring på web heiter HyperText Transmission Protocol (HTTP).
Den originale HTTP-protokollen var heilt enkel og laga før web blei populær, har vore i bruk sidan 1990.
Samband blei sett opp ved å gå rett til ein webtenar, bruker TCP/IP (sjølv om du kan bruka kva du vil i botn, dersom du vil bruka brevduer, sjå RFC 1149 "IP Datagrams over Avian Carriers" for nærare spesifikasjon) til den tenaren som er oppgitt i URLen.
Tenaren opnar sambandet.
Deretter spør klientprogrammet etter dokumentet
GET /sti-til-dokument/dokumentSvaret på denne kommandoen er HTML-dokumentet, ein straum av teikn.
Feilmeldingar blir gitt som HTML-dokument, og det er ingen måte klienten kan finna ut om noko gjekk feil (men brukaren vil sjå det).
Deretter tar tenaren ned sambandet.
Konsekvensen av dette er at kvart element som blir henta krev at eit eige samband blir sett opp, noko som er tid- og ressurskrevjande. Protokollen er tilstandslaus.
Er dokumentert som eit informasjonsdokument i RFC- serien; RFC1945, dette hovudsakleg som eit døme på kva som er i bruk i dag, ikkje som eit forsøk på å standardisera (då ville det vore eit standard-dokument).
HTTP/1.0 tillet MIME-liknande meldingar som inneheldt ikkje berre sjølve dokumentet, men også informasjon om dokumentet.
Protokollen er basert på spørsmål/svar, der klienten koplar seg opp mot tenaren, sender eit spørsmål til tenaren og får eit svar tilbake, tenaren tar ned sambandet. Spørsmålet frå klienten inneheld metode (t.d. GET), URI (er i praksis berre URLar), protokollversjon (HTTP/1.0); fulgt av ein MIME-liknande del med informasjon om klienten, eventuelle modifiers, og eventuelt innhald (kropp)
Svaret frå tenaren før han koplar ned sambandet er saman sett av protokollversjon, statuskode (enten suksess eller feil-kode); ei MIME-liknande melding med informasjon om tenaren, informasjon om innhaldet og innhald.
Som du ser er dette meir komplisert enn i versjon 0.9, funksjonaliteten er også utvida frå henting av dokument til gjer nesten kva som helst.
Med unntak av eksperimentelle tenester, vil alltid ei opp kopling bli sett opp av klienten mot tenaren, aldri omvendt; og tenaren vil alltid lukka sambandet etter at han har sendt svar til klienten. Kvart dokument (og kvart bilde i dokumentet) krev at klienten koplar seg opp på ny mot tenaren. ofte vil mange oppkoplingar etter kvarandre gå mot den same tenaren.
Vanlegvis vil klienten A kopla seg direkte opp mot tenaren B (nederste pila) og få tilbake eit svar (øverste pila).

Kommunikasjonen går direkte mellom klient og tenar. Webcaching kan spara trafikk i nettverket og gje raskare respons til brukarane. Det er dumt å henta same sida over same sambandet mange gonger. Dersom vi set inn ein webcache C i nettet, går kommunikasjonen gjennom webcachetenaren.

Har ein brukar henta ned det aktuelle dokumentet før, vil A få dokumentet direkte frå C, som vist med dei heiltrukne pilene. Dersom dokumentet ikkje er henta ned før, vil C henta dokumentet frå B, som vist med dei stipla pilene, og lagra det for framtidig bruk. Webcachen kan vera ein del av klienten, det kan vera ein eigen tenar som fleire klientar deler, eller det kan vera ei rekkje tenarar der klientane koplar seg opp mot den nærmaste.
Ein anna grunn for oppgradering av protokollen var alle dei implementasjonane som gjorde krav på å vera kompatible med HTTP/1.0 (ein god del av desse gjorde krav på kompabilitet før protokollen var ferdig definert), utan heilt å vera det. Det er viktig for tenarar og klientar å bli einige om kva dei kan utveksla og kva funksjonalitet dei har, difor ei endring av versjonsnummeret.
Samarbeidande webcachar kan redusera nett-trafikken sterkt. Manglande støtte for samarbeid mellom webcache tenarar har vore eit hinder på vegen mot eit betre nett, difor er HTTP/1.1 utvida med støtte for webcaching. Det blir no enklare å spesifisera kva som ikkje kan cachast og kva som kan cachast, ein ny klasse "kommandoar" er innført for å ha kontroll over webcaching. Ein av konsekvensane blir at utdatert informasjon ikkje blir liggjande i webcachen med mindre det er gode grunnar til det (t.d. at linja til webtenaren er nede, då kan gamal informasjon vera betre enn ingenting).
Eit av dei største problema med web er at for kvart enkelt element (tekstside, bilde på side, lyd, video, programsnuttar) blir det sett opp eitt nytt samband til webtenaren. Ved å la alle forespørslar til webtenaren henga saman utan å setja opp nye samband, kan ein spara både tida det tar å setja opp sambandet og ein kan ha betre flytkontroll på den datastraumen som blir overført. Det siste gjer web snillare mot andre som bruker nettet, i dag er det eit stort problem at web grådig grip til seg for mykje bandbreidde.
Skal gje høve til å velja ei side basert på ønske frå brukaren. Kan t.d. setja opp at du ønskjer å sjå norsk versjon framfor engelsk, og at du ikkje ønskjer lydfiler. Dersom du berre kan lesa eitt bildeformat, kan du fortelja tenaren at du berre vil ha bilde dersom dei er i det rette formatet, og slik oppnå betre webteneste for deg og spara nettet for unødige overføringar.
Ved at ein kan forhandla om format, blir det enklare for informasjonsleverandørane på web å tilretteleggja infor masjon for kvar enkelt brukargruppe.
Kan ha fleire virtuelle tenarar på ei maskin, dette inneber mellom anna at ein ikkje treng eit IP-nummer for kvar webtenar med ulikt domenenamn. Konsekvensen av dette er at det blir enklare å setja opp store webhotell, og at ein ikkje sløser med IPnummer.
Ei arbeidsgruppe innan IETF som heiter Web Transaction Security har starta arbeidet med å definera sikre overførin gar på web, mellom anna for bruk ved elektronisk handel. Forhandlingar om format vil bli utvida med fleire funksjo nar i HTTP/1.2 i høve til HTTP/1.1.
Fleire ulike retningar for utviklinga blir drøfta, mellom emna som er tatt opp er multicasting av webinformasjon (både mellom webcachar og heilt fram til sluttbrukaren), kompresjon av maskinlesbar informasjon i headarar og fleire utvidingar med støtte for tryggleiksfunksjonar som kryptering og sikre samband.
Meir informasjon om kva som skjer med webprotokollane finn du hjå IETF, sjå
eller hjå World Wide Web Consortium| uninytt@uninett.no | 2002-10-29 |