HTTP

HTTP
Navn Hypertext Transfer Protocol
Niveau (ifølge OSI-modellen ) Anvendt
Familie TCP/IP
Oprettet i 1992
Port/ID 80/ TCP
Specifikation RFC 124 , RFC 1945 , RFC 2616 , RFC 2617 , RFC 6266 , RFC 7230 , RFC 7240 , RFC 8446 .
Vigtigste implementeringer (klienter) Webbrowsere , for eksempel Internet Explorer , Mozilla Firefox , Opera , Google Chrome , Yandex Browser , Microsoft Edge osv.
Kerneimplementeringer ( servere ) Apache , IIS , nginx , Google Web Server osv.
 Mediefiler på Wikimedia Commons

HTTP ( HyperText  Transfer Protocol  - " hypertekstoverførselsprotokol ") er en applikationslagsdataoverførselsprotokol , oprindeligt i form af hypertekstdokumenter i HTML -format , som i øjeblikket bruges til at overføre vilkårlige data.

Grundlæggende egenskaber

Grundlaget for HTTP er "klient-server" teknologien , det vil sige eksistensen af:

HTTP er nu allestedsnærværende på World Wide Web til at hente information fra websteder . I 2006 overgik HTTP - trafikken i Nordamerika den for P2P-netværk med 46 %, hvoraf næsten halvdelen var video- og lydstreaming [1] .

HTTP bruges også som en "transport" for andre applikationslagsprotokoller såsom SOAP , XML-RPC , WebDAV .

Hovedobjektet for manipulation i HTTP er den ressource, der peges på af en URI (Uniform Resource Identifier) ​​i en klientanmodning. Disse ressourcer er typisk filer gemt på serveren , men de kan være logiske objekter eller noget abstrakt. Et træk ved HTTP-protokollen er evnen til at specificere i anmodningen og svaret, hvordan den samme ressource repræsenteres af forskellige parametre: format , kodning , sprog osv. (især HTTP-header bruges til dette ). Det er takket være evnen til at specificere, hvordan beskeden er kodet, at klienten og serveren kan udveksle binære data , selvom denne protokol er tekst.

HTTP er en applikationslagsprotokol ; dets modstykker er FTP og SMTP . Beskeder udveksles efter den sædvanlige "request-response"-ordning. HTTP bruger globale URI'er til at identificere ressourcer . I modsætning til mange andre protokoller er HTTP statsløs. Det betyder, at der ikke lagres nogen mellemtilstand mellem anmodning-svar-par. Komponenter, der bruger HTTP, kan uafhængigt gemme tilstandsoplysninger relateret til seneste anmodninger og svar (f.eks. " cookies " på klientsiden, "sessioner" på serversiden). Den browser, der sender anmodningerne, kan spore svarforsinkelser. Serveren kan gemme IP-adresserne og anmode om overskrifter for de seneste klienter. Protokollen selv er dog ikke bekendt med tidligere anmodninger og svar, den yder ikke intern statsstøtte, den har ikke sådanne krav.

De fleste protokoller giver mulighed for etablering af en TCP-session, hvor godkendelse sker én gang, og yderligere handlinger udføres i forbindelse med denne godkendelse. HTTP etablerer en separat TCP-session for hver anmodning; senere versioner af HTTP tillod flere anmodninger i en enkelt TCP-session, men browsere anmoder typisk kun om siden og de objekter, der er inkluderet i den (billeder, cascading-stile osv.) og afslutter derefter TCP-sessionen med det samme. HTTP bruger cookies til at understøtte autoriseret (ikke-anonym) adgang ; Desuden giver denne godkendelsesmetode dig mulighed for at gemme sessionen, selv efter at klienten og serveren er genstartet.

Når du får adgang til data via FTP eller filprotokoller, bestemmes filtypen (mere præcist, typen af ​​data, der er indeholdt i den) af filtypenavnet, hvilket ikke altid er praktisk. HTTP transmitterer, før selve dataene transmitteres, Content-Type: type/subtype-headeren, som giver klienten mulighed for utvetydigt at bestemme, hvordan de sendte data skal behandles. Dette er især vigtigt, når du arbejder med CGI -scripts, når filtypenavnet ikke angiver typen af ​​data sendt til klienten, men behovet for at køre denne fil på serveren og sende resultaterne af programmet skrevet i denne fil til klienten (i dette tilfælde, den samme fil i afhængigt af anmodningsargumenterne og dens egne overvejelser, kan den generere svar af forskellige typer - i det enkleste tilfælde billeder i forskellige formater).

Derudover giver HTTP klienten mulighed for at sende parametre til serveren, som vil blive videregivet til det CGI-script, der køres. Til dette blev formularer indført i HTML .

Disse funktioner i HTTP gjorde det muligt at oprette søgemaskiner (hvoraf den første var AltaVista , skabt af DEC ), fora og internetbutikker. Dette kommercialiserede internettet, virksomheder dukkede op, hvis hovedaktivitetsområde var levering af internetadgang (udbydere) og oprettelse af websteder.

Software

Al software til at arbejde med HTTP-protokollen er opdelt i tre brede kategorier:

For at skelne slutservere fra proxyer bruger den officielle dokumentation udtrykket oprindelsesserver .  Et og samme softwareprodukt kan samtidigt udføre funktionerne som en klient, server eller mellemmand afhængig af opgaverne. HTTP-protokolspecifikationerne beskriver adfærden for hver af disse roller.

Klienter

HTTP-protokollen blev oprindeligt designet til at få adgang til hypertekstdokumenter på World Wide Web. Derfor er de vigtigste klientimplementeringer browsere (brugeragenter). For at se det gemte indhold af websteder på en computer uden internetforbindelse blev offline browsere opfundet . Når forbindelsen er ustabil , bruges downloadadministratorer til at downloade store filer ; de giver dig mulighed for at downloade de angivne filer til enhver tid, efter at forbindelsen til webserveren er mistet. Nogle virtuelle atlasser (såsom Google Earth og NASA World Wind ) bruger også HTTP.

Ofte bruges HTTP-protokollen af ​​programmer til at downloade opdateringer.

En lang række robotprogrammer bruges i internetsøgemaskiner . Blandt dem er web-spiders ( crawlere ), der krydser hyperlinks, kompilerer en database med serverressourcer og gemmer deres indhold til yderligere analyse.

Kildeservere

Vigtigste implementeringer: Apache , Internet Information Services (IIS), nginx , LiteSpeed ​​​​Web Server (LSWS), Google Web Server , lighttpd .

Proxy-servere

Vigtigste implementeringer: Squid , UserGate , Multiproxy , Naviscope , nginx .

HTTP-meddelelsesstruktur

Hver HTTP-meddelelse består af tre dele, som sendes i den angivne rækkefølge:

  1. Startlinje ( eng.  Startlinje ) - bestemmer typen af ​​besked;
  2. Headers ( engelske  Headers ) - karakteriserer meddelelsens brødtekst, transmissionsparametre og anden information;
  3. Meddelelsens brødtekst ( English  Message Body ) - direkte data for meddelelsen. Skal adskilles fra overskrifter med en tom linje.

Brødteksten i meddelelsen kan udelades, men startlinjen og overskriften er obligatoriske elementer. Undtagelsen er version 0.9 af protokollen, hvor anmodningsmeddelelsen kun indeholder startlinjen, og svarmeddelelsen kun indeholder meddelelsesteksten.

For protokolversion 1.1 skal anmodningsmeddelelsen indeholde Host -headeren .

Startlinje

Startstrengene er forskellige for anmodning og svar. Forespørgselsstrengen ser sådan ud:

GET URI — for protokolversion 0.9; Метод URI HTTP/Версия - for andre versioner.

Her:

For at anmode om en side til denne artikel skal klienten sende strengen (kun én overskrift angivet):

FÅ /wiki/HTTP HTTP/1.0 Vært: en.wikipedia.org

Startlinjen for serversvaret har følgende format: HTTP/Версия КодСостояния Пояснение, hvor:

For eksempel kan startlinjen for serverens svar på en tidligere anmodning se sådan ud:

HTTP/1.0 200 OK

Metoder

HTTP-metode ( engelsk  HTTP-metode ) - en sekvens af alle tegn, undtagen kontrol og afgrænsningstegn, der angiver hovedoperationen på ressourcen. Normalt er metoden et kort engelsk ord skrevet med store bogstaver. Bemærk, at metodenavnet skelner mellem store og små bogstaver.

Serveren kan bruge alle metoder, der er ingen obligatoriske metoder til serveren eller klienten. Hvis serveren ikke genkender metoden specificeret af klienten, skal den returnere status 501(Ikke implementeret). Hvis metoden er kendt af serveren, men den ikke er anvendelig for en bestemt ressource, 405returneres en meddelelse med en kode (Method Not Allowed). I begge tilfælde SKAL serveren inkludere en header Allowmed en liste over understøttede metoder i svarmeddelelsen.

Ud over metoderne GETog HEADanvendes metoden ofte POST.

MULIGHEDER

Bruges til at bestemme webserverens muligheder eller forbindelsesmuligheder for en specifik ressource. Som svar SKAL serveren inkludere en header Allowmed en liste over understøttede metoder. Svaroverskriften kan også indeholde oplysninger om understøttede udvidelser.

Det forudsættes, at klientanmodningen kan indeholde en meddelelsestekst til at angive de oplysninger, der er af interesse for ham. Brødtekstens format og rækkefølgen af ​​arbejdet med den er ikke defineret i øjeblikket. serveren bør ignorere det indtil videre. Situationen er den samme med kroppen i serversvaret.

For at finde ud af mulighederne for hele serveren, skal klienten angive en stjerne - " *" - i URI'en. Anmodninger " OPTIONS * HTTP/1.1" kan også bruges til at kontrollere serverens tilstand (svarende til " ping ") og til at teste, om serveren understøtter HTTP version 1.1-protokollen.

Resultatet af at udføre denne metode er ikke cachelagret .

FÅ

Bruges til at forespørge på indholdet af den angivne ressource. GETDu kan også starte en proces ved hjælp af en metode . I dette tilfælde skal information om processens fremskridt inkluderes i brødteksten i svarmeddelelsen.

Klienten kan sende anmodningsudførelsesparametre i målressourcens URI efter ?tegnet " ":
GET /path/resource?param1=value1&param2=value2 HTTP/1.1

Ifølge HTTP-standarden betragtes typeanmodninger GETsom idempotente [2]

Ud over den sædvanlige metode GETer der også

Rækkefølgen for udførelse af sådanne anmodninger er defineret separat af standarderne.

HOVED

Svarende til metoden GET, bortset fra at der ikke er nogen krop i serversvaret. Forespørgslen HEADbruges typisk til at hente metadata , kontrollere, om der findes en ressource ( URL -validering ), og se, om den har ændret sig, siden den sidst blev tilgået.

Svaroverskrifter kan cachelagres. Hvis ressourcemetadataene ikke matcher de tilsvarende oplysninger i cachen, markeres kopien af ​​ressourcen som forældet.

POST

Bruges til at videregive brugerdata til en given ressource. For eksempel i blogs kan besøgende normalt indtaste deres kommentarer til indlæg i en HTML-formular, hvorefter de sendes til serveren ved hjælp af POST -metoden, og den sætter dem på siden. I dette tilfælde er de overførte data (i blogeksemplet kommentarteksten) inkluderet i anmodningsteksten. POSTPå samme måde uploades filer normalt til serveren ved hjælp af metoden .

I modsætning til metoden GETanses metoden POSTikke for at være idempotent [2] , det vil sige, at gentagne gentagelser af de samme forespørgsler POSTkan returnere forskellige resultater (for eksempel, efter hver kommentar er sendt, vil der vises en anden kopi af denne kommentar).

Hvis udførelsesresultatet er 200(Ok), skal svarlegemet inkludere en meddelelse om resultatet af anmodningen. Hvis en ressource er blevet oprettet, SKAL serveren returnere et svar 201(Created) med URI'en for den nye ressource i Location.

Metodeudførelsesserverens svarmeddelelse er POSTikke cachelagret.

PUTS

Bruges til at downloade indholdet af anmodningen til den URI, der er angivet i anmodningen. Hvis der ikke findes en ressource for den givne URI, opretter serveren den og returnerer status 201(Oprettet). Hvis ressourcen er blevet ændret, returnerer serveren 200(Ok) eller 204(Intet indhold). Serveren MÅ IKKE ignorere ugyldige headere Content-*sendt af klienten sammen med beskeden. Hvis nogen af ​​disse overskrifter ikke kan genkendes eller er ugyldige under de nuværende forhold, skal en fejlkode 501(Ikke implementeret) returneres.

Den grundlæggende forskel mellem metoderne POSTligger PUTi at forstå hensigten med ressource-URI'er. Metoden POSTantager, at det indhold, der transmitteres af klienten, vil blive behandlet på den specificerede URI. Ved at bruge PUT, antager klienten, at indholdet, der indlæses, matcher ressourcen på den givne URI.

Serversvarmeddelelser til en metode PUTgemmes ikke i cache.

PATCH

Svarer til PUT, men gælder kun for et ressourcefragment.

SLET

Sletter den angivne ressource.

SPOR

Returnerer den modtagne anmodning, så klienten kan se, hvilke oplysninger mellemservere tilføjer eller ændrer i anmodningen.

TILSLUT

Konverterer anmodningsforbindelsen til en gennemsigtig TCP/IP- tunnel, normalt for at lette etableringen af ​​en sikker SSL - forbindelse gennem en ukrypteret proxy .

Statuskoder

Statuskoden er en del af den første linje i serverens svar. Det er et trecifret heltal [3] . Det første ciffer angiver statusklassen. Svarkoden efterfølges normalt af en mellemrumsadskilt forklarende sætning på engelsk, som forklarer personen årsagen til et sådant svar. Eksempler:

201 Webside oprettet 403 Adgang er kun tilladt for registrerede brugere 507 Utilstrækkelig opbevaring

Klienten lærer af svarkoden om resultaterne af hans anmodning og bestemmer, hvilke handlinger der skal tages derefter. Sættet af statuskoder er en standard, og de er beskrevet i de relevante RFC- dokumenter . Indførelse af nye koder bør kun ske efter samråd med IETF . Klienten kender måske ikke alle statuskoder, men den skal svare i henhold til kodeklassen.

Der er i øjeblikket fem klasser af statuskoder

Koden Klasse Formål
1xx Oplysende

(eng. informal )

Oplysninger om overførselsprocessen.

I HTTP/1.0 skal meddelelser med sådanne koder ignoreres.

I HTTP/1.1 skal klienten være forberedt på at acceptere denne beskedklasse som et normalt svar, men der skal ikke sendes noget til serveren.

Beskederne fra selve serveren indeholder kun svarstartlinjen og om nødvendigt nogle få svarspecifikke overskriftsfelter. Proxyservere bør sende sådanne meddelelser videre fra serveren til klienten.

2xx Succes

(Engelsk succes )

Informere om sager om vellykket accept og behandling af kundens anmodning. Afhængigt af status kan serveren stadig sende meddelelsens overskrifter og brødtekst.
3xx omdirigere

(eng. Omdirigering )

Informerer klienten om, at en anden anmodning (normalt af en anden URI) skal foretages for at fuldføre handlingen. Fra denne klasse henviser fem koder 301, 302, 303, 305og 307direkte til omdirigeringer (omdirigering). Adressen, som klienten skal sende en anmodning til, angives af serveren i Location. Dette gør det muligt at bruge fragmenter i mål-URI'en.
4xx Klientfejl

(Engelsk klientfejl )

Angivelse af fejl fra klientsiden. Når du bruger alle metoder undtagen HEAD, skal serveren returnere en hypertekstforklaring til brugeren i meddelelsens brødtekst.
5xx Server Fejl

(Engelsk serverfejl )

Informere om tilfælde af mislykket drift på grund af serverens fejl. For alle andre situationer end at bruge metoden HEADSKAL serveren inkludere en forklaring i brødteksten af ​​meddelelsen, som klienten vil vise til brugeren.

Titler

HTTP-headere er strenge i en HTTP-meddelelse, der indeholder et kolonsepareret parameter-værdi-par .  Formatet på overskrifterne følger det generelle format for ARPA-tekstnetværksmeddelelsesoverskrifter (se RFC 822 ). Overskrifter skal adskilles fra meddelelsesteksten med mindst én tom linje.

Eksempler på overskrifter:

Server: Apache/2.2.11 (Win32) PHP/5.3.0 Sidst ændret: Lør, 16 Jan 2010 21:16:42 GMT Indholdstype: tekst/almindelig; charset=windows-1251 Indhold-Sprog: en

I eksemplet ovenfor repræsenterer hver linje én overskrift. I dette tilfælde kaldes det, der står før kolon, navnet ( engelsk  navn ), og det, der står efter det, kaldes værdien ( engelsk  værdi ).

Alle overskrifter er opdelt i fire hovedgrupper:

  1. Generelle overskrifter ("Hovedoverskrifter") - kan inkluderes i enhver meddelelse fra klienten og serveren;
  2. Request Headers ("Request Headers") - bruges kun i klientanmodninger;
  3. Response Headers ("Response Headers") - kun for svar fra serveren;
  4. Entitetsoverskrifter ("Entitetens overskrifter") - ledsager hver enhed i meddelelsen.

Dette er den rækkefølge, det anbefales at sende overskrifterne i til modtageren.

Alle headere, der kræves for, at HTTP kan fungere, er beskrevet i de centrale RFC'er . Hvis der ikke er nok eksisterende, så kan du indtaste dine egne. Traditionelt er navnene på sådanne ekstra overskrifter foranstillet med " X-" for at undgå navnekonflikter med muligvis eksisterende. For eksempel som i overskrifter X-Powered-Byeller X-Cache. Nogle udviklere bruger deres egne brugerdefinerede præfikser. Eksempler på sådanne overskrifter er dem , som Microsoft Ms-Echo-Requestintroducerede til WebDAV- udvidelsen . Ms-Echo-Reply

Meddelelsestekst

HTTP-meddelelsesteksten ( message-body), hvis den findes, bruges til at formidle den objekttekst, der er knyttet til anmodningen eller svaret. Meddelelsesteksten adskiller sig kun fra objektteksten ( entity-body), når der anvendes en transmissionskodning, som angivet af overskriftsfeltet Transfer-Encoding.

message-body = entity-body | <entity-body kodet iht overførsels-kodning>

Feltet Transfer-Encodingskal bruges til at angive enhver transmissionskodning, der anvendes af applikationen for at sikre, at meddelelsen transmitteres sikkert og korrekt. Et felt Transfer-Encoding er en egenskab for en meddelelse, ikke et objekt, og kan således tilføjes eller fjernes af enhver applikation i anmodnings-/svarkæden.

Reglerne for gyldigheden af ​​en meddelelsestekst i en meddelelse er forskellige for anmodninger og svar.

Tilstedeværelsen af ​​en meddelelsestekst i en anmodning indikeres ved at tilføje et overskriftsfelt Content-Lengtheller til anmodningshovederne Transfer-Encoding. En meddelelsestekst kan kun tilføjes til en anmodning, når anmodningsmetoden tillader en objekttekst.

Hvorvidt meddelelsesteksten er inkluderet i svarmeddelelsen afhænger af både anmodningsmetoden og svarstatuskoden. Alle svar på en anmodning med en metode HEADmå ikke indeholde en meddelelsestekst, selvom objektoverskriftsfelter ( entity-header) er til stede for at få det til at se ud som om objektet er til stede. Ingen svar med statuskoder 1xx(informativ), 204(Intet indhold) og 304(Ikke ændret) må indeholde en meddelelsestekst. Alle andre svar indeholder en meddelelsestekst, selvom den er nul-længde.

Eksempler på HTTP-dialoger

Regelmæssig GET-anmodning

Kundeanmodning:

FÅ /wiki/ HTTP/1.1 side Vært: en.wikipedia.org Brugeragent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accepter: tekst/html Tilslutning: Luk (tom linje)

Serversvar:

HTTP/1.1 200 OK Dato: ons, 11. februar 2009 11:20:59 GMT Server: Apache X-Powered-By: PHP/5.2.4-2ubuntu5wm1 Sidst ændret: ons, 11. februar 2009 11:20:59 GMT Indhold-Sprog: en Indholdstype: tekst/html; charset=utf-8 Indholdslængde: 1234 Tilslutning: Luk (tom streng) (anmodet side i HTML )

Svaret ser det samme ud 203. Hvad der er vigtigt - direkte anmodede data adskilles fra HTTP-headere ved hjælp af CR , LF , CR, LF.

Omdirigeringer

Antag, at det fiktive firma "Example Corp." der er et hovedwebsted på "http://example.com" og et aliasdomæne "example.org" . Klienten sender en anmodning om siden "Om" til det sekundære domæne (nogle overskrifter udeladt):

FÅ /about.html HTTP/1.1 Vært: example.org Brugeragent: MyLonelyBrowser/5.0

Da "example.org" -domænet ikke er et primært domæne, og virksomheden ikke har til hensigt at bruge det til andre formål i fremtiden, vil deres server returnere en kode til en permanent omdirigering, der angiver Locationmål-URL'en i overskriften:

HTTP/1.x 301 flyttet permanent Placering: http://example.com/about.html#contacts Dato: tor, 19. februar 2009 11:08:01 GMT Server: Apache/2.2.4 Indholdstype: tekst/html; charset=windows-1251 Indholdslængde: 110 (tom linje) <html><body><a href="http://example.com/about.html#contacts">Klik her</a></body></html>

I titlen Locationkan du angive fragmenter som i dette eksempel. Browseren har ikke angivet et fragment i anmodningen, fordi den er interesseret i hele dokumentet. Men det vil automatisk rulle siden til "kontakter"-fragmentet, så snart det indlæses. Et kort HTML-dokument blev også placeret i brødteksten af ​​svaret med et link, der ville tage den besøgende til landingssiden, hvis browseren ikke automatisk navigerede til den. Titlen Content-Typeindeholder egenskaberne for den pågældende HTML-forklaring, ikke for det dokument, der findes på mål-URI'en.

Lad os sige det samme firma "Example Corp." har flere regionale kontorer rundt om i verden. Og for hvert bureau har de en hjemmeside med en tilsvarende ccTLD . Hjemmesideanmodningen for hovedwebstedet "example.com" kan se sådan ud:

GET /HTTP/1.1 vært: eksempel.com Brugeragent: MyLonelyBrowser/5.0 Accepter: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accepter-sprog: ru,en-us;q=0.7,en;q=0.3 Accepter-tegnsæt: windows-1251,utf-8;q=0.7,*;q=0.7

Serveren tog headeren i betragtning Accept-Languageog dannede et svar med en midlertidig omdirigering til den russiske server "example.ru" , der angiver dens adresse i headeren Location:

HTTP/1.x 302 fundet Placering: http://example.ru/ Cache-kontrol: privat Dato: tor, 19. februar 2009 11:08:01 GMT Server: Apache/2.2.6 Indholdstype: tekst/html; charset=windows-1251 Indholdslængde: 82 (tom linje) <html><body><a href="http://example.ru">Example Corp.</a></body></html>

Vær opmærksom på overskriften Cache-Control: "private" værdien fortæller resten af ​​serverne (primært proxyer), at svaret kun kan cachelagres på klientsiden. Ellers er det muligt, at følgende besøgende fra andre lande altid vil gå til en anden repræsentation.

303Svarkoderne (Se Andet) og 307(Temporary Redirect) bruges også til omdirigering .

Genoptag og download af fragmenter

Lad os sige, at en fiktiv organisation tilbyder at downloade en video af den tidligere konference fra webstedet på: "http://example.org/conf-2009.avi" - cirka 160 MB i størrelse . Lad os overveje, hvordan denne fil genoptages i tilfælde af fejl, og hvordan downloadmanageren ville organisere multi- trådede download af flere fragmenter.

I begge tilfælde vil klienter fremsætte deres første anmodning således:

GET /conf-2009.avi HTTP/1.0 Vært: example.org Acceptere: */* Brugeragent: Mozilla/4.0 (kompatibel; MSIE 5.0; Windows 98) Henviser: http://example.org/

Titlen Refererangiver, at filen blev anmodet om fra webstedets hovedside. Download-administratorer angiver det normalt også for at efterligne overgangen fra webstedssiden. Uden det kan serveren reagere 403(Adgang forbudt), hvis anmodninger fra andre websteder ikke er tilladt. I vores tilfælde returnerede serveren et vellykket svar:

HTTP/1.1 200 OK Dato: tor, 19. februar 2009 12:27:04 GMT Server: Apache/2.2.3 Sidst ændret: ons, 18. juni 2003 16:05:58 GMT ETag: "56d-9989200-1132c580" Indholdstype: video/x-msvideo Indhold-længde: 160993792 Accepter-intervaller: bytes Tilslutning: Luk (tom streng) (binært indhold af hele filen)

Headeren Accept-Rangesinformerer klienten om, at den kan anmode om fragmenter fra serveren ved at angive deres offsets fra begyndelsen af ​​filen i bytes. Hvis denne header mangler, så KAN klienten advare brugeren om, at filen højst sandsynligt ikke vil kunne downloades.

Baseret på overskriftsværdien Content-Lengthvil downloadmanageren opdele hele volumen i lige store fragmenter og anmode om dem separat og organisere flere streams. Hvis serveren ikke angiver en størrelse, vil klienten ikke være i stand til at implementere parallelle downloads, men den vil stadig være i stand til at downloade filen, indtil serveren svarer 416(Requested Range Not Satisfiable).

Lad os sige, at ved den 84. megabyte blev internetforbindelsen afbrudt, og downloadprocessen stoppede. Da internetforbindelsen blev genoprettet, sendte downloadmanageren automatisk en ny anmodning til serveren, men med en instruktion om at returnere indholdet fra den 84. megabyte:

GET /conf-2009.avi HTTP/1.0 Vært: example.org Acceptere: */* Brugeragent: Mozilla/4.0 (kompatibel; MSIE 5.0; Windows 98) Interval: bytes=88080384- Henviser: http://example.org/

Serveren er ikke forpligtet til at huske, hvad og fra hvem anmodninger blev foretaget før, og derfor indsatte klienten headeren igen Referer, som om det var dens allerførste anmodning. Den angivne headerværdi Rangefortæller serveren: "Giv indholdet fra byte 88080384 til slutningen." I denne henseende vil serveren returnere et svar:

HTTP/1.1 206 Delvis indhold Dato: tor, 19. februar 2009 12:27:08 GMT Server: Apache/2.2.3 Sidst ændret: ons, 18. juni 2003 16:05:58 GMT ETag: "56d-9989200-1132c580" Accepter-intervaller: bytes Indholdsområde: bytes 88080384-160993791/160993792 Indhold-længde: 72913408 Tilslutning: Luk Indholdstype: video/x-msvideo (tom streng) (binært indhold fra 84. megabyte)

Headeren Accept-Rangeser ikke længere påkrævet her, da klienten allerede er klar over denne serverfunktion. Det faktum, at et fragment bliver transmitteret, er kendt af klienten af ​​koden 206(Delvis indhold). Headeren Content-Rangeindeholder information om dette fragment: numrene på start- og slutbyten, og efter skråstreg, den samlede størrelse af hele filen i bytes. Vær opmærksom på overskriften Content-Length - den angiver størrelsen af ​​meddelelsesteksten, det vil sige det transmitterede fragment. Hvis serveren returnerer flere fragmenter, Content-Lengthvil den indeholde deres samlede volumen.

Nu tilbage til download-manageren. Ved at kende den samlede størrelse af filen "conf-2009.avi" opdelte programmet den i 10 lige store sektioner.

Den oprindelige manager vil indlæse ved den allerførste anmodning og afbryde forbindelsen, så snart den når begyndelsen af ​​den anden. Resten vil blive anmodet separat. For eksempel vil den 4. sektion blive anmodet om med følgende overskrifter (nogle overskrifter udeladt - se det fulde eksempel ovenfor):

GET /conf-2009.avi HTTP/1.0 Interval: bytes=64397516-80496894

Serversvaret i dette tilfælde vil være følgende (en del af overskrifterne er udeladt - se det fulde eksempel ovenfor):

HTTP/1.1 206 Delvis indhold Accepter-intervaller: bytes Indholdsområde: bytes 64397516-80496894/160993792 Indholdslængde: 16099379 (tom streng) (4. del binært indhold)

Hvis en sådan anmodning sendes til en server, der ikke understøtter fragmenter, vil den returnere et standardsvar 200(OK) som vist i begyndelsen, men uden headeren Accept-Ranges.

Se også delvis GET , byte-intervaller , svar 206 , svar 416 .

Grundlæggende mekanismer i protokollen

Delvise GETs

HTTP giver dig mulighed for at anmode om ikke alt indholdet af ressourcen på én gang, men kun det angivne fragment. Sådanne anmodninger kaldes delvise GET; muligheden for at udføre dem er valgfri (men ønskelig) for servere. Partialer bruges GEThovedsageligt til at genoptage filer og hurtige parallelle downloads i flere tråde. Nogle programmer downloader arkivhovedet, viser den interne struktur for brugeren og anmoder derefter om fragmenter med de angivne arkivelementer.

For at modtage et fragment sender klienten en anmodning til serveren med en header Range, der angiver de nødvendige byte-intervaller i den . Hvis serveren ikke forstår delvise anmodninger (ignorerer overskriften Range), så vil den returnere alt indhold med status 200, ligesom med en normal GET. I tilfælde af vellykket afslutning returnerer serveren et 200svar med status 206(Delvis indhold) i stedet for en kode, inklusive headeren i svaret Content-Range. Fragmenter i sig selv kan overføres på to måder:

Betingede GET'er

Metoden GETændres til "betinget GET", hvis anmodningsmeddelelsen indeholder et overskriftsfelt If-Modified-Since. Som svar på "betinget GET" sendes brødteksten af ​​den anmodede ressource kun, hvis den er ændret siden den dato, der er angivet i overskriften If-Modified-Since. Algoritmen til at bestemme dette inkluderer følgende tilfælde:

Brugen af ​​"betinget GET"-metoden er rettet mod at aflæse netværket, da det tillader ikke at transmittere redundant information over netværket.

Indholdsforhandling

Indholdsforhandling er en  mekanisme til automatisk at bestemme den nødvendige ressource i nærværelse af flere forskellige versioner af et dokument. Forhandlingsemner kan ikke kun være serverressourcer, men også returnerede sider med fejlmeddelelser ( 403 , 404 osv.).

Der er to hovedtyper af aftaler:

Begge typer kan bruges på samme tid eller hver af dem separat.

Hovedprotokolspecifikationen ( RFC 2616 ) fremhæver også den såkaldte transparente forhandling som den foretrukne kombination af begge typer .  Sidstnævnte mekanisme må ikke forveksles med den uafhængige TCN-teknologi (Transparent Content Negotiation) , som ikke er en del af HTTP-protokollen, men som kan bruges sammen med den. Begge har en væsentlig forskel i funktionsprincippet og selve betydningen af ​​ordet "transparent" (transparent). I HTTP-specifikationen betyder transparens, at processen er usynlig for klienten og serveren, og i TCN-teknologien betyder transparens tilgængeligheden af ​​en komplet liste over ressourcemuligheder for alle deltagere i dataleveringsprocessen.

Server administreret

Hvis der er flere versioner af en ressource, kan serveren parse klientens anmodningsheadere for at returnere, hvad den mener er den bedste. Overskrifterne Accept, Accept-Charset, Accept-Encodingog Accept-Languageser hovedsageligt analyseret User-Agent. Det er ønskeligt for serveren at inkludere en header i svaret Vary, der angiver parametrene, hvorved indholdet skelnes af den anmodede URI.

Den geografiske placering af klienten kan bestemmes ud fra den eksterne IP-adresse . Dette er muligt på grund af det faktum, at IP-adresser, ligesom domænenavne , er registreret til en bestemt person eller organisation. Ved tilmelding angiver du det område, hvor det ønskede adresserum skal bruges. Disse data er offentligt tilgængelige, og på internettet kan du finde de tilsvarende frit distribuerede databaser og færdige softwaremoduler til at arbejde med dem (du bør fokusere på nøgleordene "Geo IP").

Det skal huskes, at denne metode er i stand til at bestemme placeringen med en maksimal nøjagtighed af byen (herfra bestemmes landet). I dette tilfælde er oplysningerne kun relevante på tidspunktet for registrering af adresserummet. For eksempel, hvis en Moskva-udbyder registrerer en række adresser, der angiver Moskva, og begynder at give adgang til kunder fra de nærmeste forstæder, så kan dens abonnenter observere på nogle websteder, at de er fra Moskva og ikke fra Krasnogorsk eller Dzerzhinsky .

Serverstyret forhandling har flere ulemper:

  • Serveren antager kun, hvilken mulighed der er mest at foretrække for slutbrugeren, men kan ikke vide præcis, hvad der er behov for i øjeblikket (f.eks. en version på russisk eller engelsk).
  • Der er mange Accepter gruppeoverskrifter, men få ressourcer med flere muligheder. På grund af dette er udstyret overbelastet.
  • Den delte cache er begrænset i sin evne til at udstede det samme svar på identiske anmodninger fra forskellige brugere.
  • Ved at sende Accept-overskrifter kan du også afsløre nogle oplysninger om dets præferencer, såsom anvendte sprog, browser, kodning.
Klientstyret

I dette tilfælde bestemmes indholdstypen kun på klientsiden. For at gøre dette returnerer serveren i et svar med en statuskode 300(Multiple Choices) eller 406(Ikke acceptabelt) en liste over muligheder, blandt hvilke brugeren vælger den passende. Klientstyret forhandling fungerer godt, når indholdet adskiller sig på de mest almindelige måder (såsom sprog og kodning), og der bruges en offentlig cache.

Den største ulempe er overheaden, da du skal lave en ekstra anmodning for at få det ønskede indhold.

Gennemsigtig forhandling

Denne forhandling er fuldstændig gennemsigtig for klienten og serveren. I dette tilfælde bruges en delt cache, som indeholder en liste over muligheder, som for en klientstyret forhandling. Hvis cachen forstår alle disse muligheder, så træffer den selv valget, som i en serverstyret forhandling. Dette reducerer belastningen på oprindelsesserveren og eliminerer den yderligere anmodning fra klienten.

HTTP-kernespecifikationen beskriver ikke den gennemsigtige forhandlingsmekanisme i detaljer.

Flere indhold

HTTP-protokollen understøtter overførsel af flere entiteter inden for en enkelt besked. Desuden kan entiteter overføres ikke kun som en enkelt-niveau sekvens, men også som et hierarki med elementer indlejret i hinanden. Medietyper bruges til at betegne flere indhold multipart/*. Arbejde med sådanne typer udføres i henhold til de generelle regler beskrevet i RFC 2046 (medmindre andet er defineret af en specifik medietype). Hvis modtageren ikke ved, hvordan den skal arbejde med typen, så behandler den den på samme måde som multipart/mixed.

Grænseparameteren betyder adskillelsen mellem de forskellige typer meddelelser, der sendes. For eksempel sender DestAddress-parameteren, der sendes fra formularen, værdien af ​​e-mail-adressen, og attachedFile1-elementet efter det sender det binære indhold af .jpg-billedet

På serversiden kan beskeder med flere indhold sendes som svar på delviseGET beskeder, når der anmodes om flere ressourcefragmenter. I dette tilfælde bruges medietypen multipart/byteranges.

På klientsiden, når du indsender en HTML- formular, er POST. Et typisk eksempel er e-mail-indsendelsessider med vedhæftede filer. Når du sender et sådant brev, genererer browseren en meddelelse af typen multipart/form-data, der integreres i den som separate dele indtastet af brugeren, emnet for brevet, modtagerens adresse, selve teksten og vedhæftede filer:

POST /send-message.html HTTP/1.1 Vært: mail.example.com Henviser: http://mail.example.com/send-message.html Bruger-agent: BrowserForDummies/4.67b Indholdstype: multipart/form-data; boundary="Asrf456BGe4h" Indhold-længde: (samlet længde inklusive underordnede overskrifter) Forbindelse: holde i live Hold i live: 300 (tom streng) (manglende præamble) --Asrf456BGe4h Indhold-Disposition: form-data; name="DestAddress" (tom linje) brutal-vasya@example.com --Asrf456BGe4h Indhold-Disposition: form-data; name="MessageTitle" (tom linje) Jeg ærgrer mig --Asrf456BGe4h Indhold-Disposition: form-data; name="MessageText" (tom linje) Hej Vasily! Din kæledyrsløve efterlod du mig i sidste uge, rev hele min sofa fra hinanden. Venligst afhent den snart! Vedhæftet er to billeder af efterspillet. --Asrf456BGe4h Indhold-Disposition: form-data; name="AttachedFile1"; filename="horror-photo-1.jpg" Indholdstype: billede/jpeg (tom streng) (binært indhold af første foto) --Asrf456BGe4h Indhold-Disposition: form-data; name="AttachedFile2"; filename="horror-photo-2.jpg" Indholdstype: billede/jpeg (tom streng) (binært indhold af andet billede) --Asrf456BGe4h-- (mangler epilog)

I eksemplet i overskrifterne matcher Content-Dispositionparameteren nameattributten namei HTML-tags <INPUT>og <TEXTAREA>. Parameteren filenameer lig med det originale filnavn på brugerens computer. Se RFC 1867 for mere information om HTML-formulargenerering og filvedhæftning .

Udviklingshistorie

HTTP/0.9 HTTP blev foreslået i marts 1991 af Tim Berners-Lee , dengang ved CERN , som en mekanisme til at få adgang til dokumenter på internettet og lette navigation ved brug af hypertekst . Den tidligste version af HTTP/0.9-protokollen blev først offentliggjort i januar 1992 (selvom implementeringen går tilbage til 1990 ). Protokolspecifikationen førte til en strømlining af reglerne for interaktion mellem HTTP-klienter og servere, samt en klar adskillelse af funktioner mellem disse to komponenter. De vigtigste syntaktiske og semantiske bestemmelser blev dokumenteret. HTTP/1.0 I maj 1996 blev RFC 1945 udstedt til den praktiske implementering af HTTP , som danner grundlaget for implementeringen af ​​de fleste af komponenterne i HTTP/1.0. HTTP/1.1 Moderne version af protokollen; vedtaget i juni 1999 [4] . Nyt i denne udgivelse var en "vedvarende forbindelse"-tilstand: en TCP - forbindelse kan forblive åben, efter at et svar på en anmodning er blevet sendt, hvilket gør det muligt at sende flere anmodninger på den samme forbindelse. Klienten skal nu sende information om navnet på den vært , den har adgang til, hvilket har gjort det muligt at organisere delt hosting lettere . HTTP/2 Den 11. februar 2015 blev de endelige versioner af udkastet til den næste version af protokollen offentliggjort. I modsætning til tidligere versioner er HTTP/2-protokollen binær . Nøglefunktioner omfatter anmodningsmultipleksing , anmodningsprioritering, header-komprimering, indlæsning af flere elementer parallelt over en enkelt TCP - forbindelse, understøttelse af proaktive push-meddelelser på serversiden [5] . HTTP/3 HTTP/3  er en foreslået efterfølger til HTTP/2 [6] [7] , der allerede er i brug på nettet baseret på UDP i stedet for TCP som transportprotokol. Ligesom HTTP/2 forælder den ikke tidligere større versioner af protokollen. HTTP/3-understøttelse blev tilføjet til Cloudflare og Google Chrome i september 2019 [8] [9] og kan aktiveres i stabile versioner af Chrome og Firefox [10] .

Se også

Noter

  1. ↑ HTTP -trafikvolumen oversteg P2P for første gang Arkiveret 22. december 2007 på Wayback Machine // Compulenta, 22. juni 2007 ( Hvidt dokument fra Ellacoya Networks Arkiveret 22. juni 2007 på Wayback Machine ).
  2. ↑ 1 2 HTTP/1.1: Metodedefinitioner  (engelsk)  (downlink) . Arkiveret fra originalen den 23. juni 2012.
  3. ↑ Se den første sætning i afsnittet " 6.1.1 Statuskode og årsagssætning " i RFC 2068. Der er også en Augmented BNF -erklæring på side 40.) " extension-code = 3DIGIT" for udvidelseskoder.
  4. ↑ HTTP/1.1-specifikationen blev først offentliggjort i januar 1997 RFC 2068 ; i den moderne version af RFC 2616 er stavefejl blevet rettet, terminologi og formatering er nogle steder blevet forbedret. Det præciserede også den acceptable adfærd hos klienten (browseren), serveren og proxyserverne i nogle tvivlsomme situationer. Det vil sige, at version 1.1 trods alt dukkede op i 1997.
  5. ↑ HTTP/2-udkast . Hentet 25. februar 2015. Arkiveret fra originalen 20. februar 2015.
  6. ↑ Bishop, Mike Hypertext Transfer Protocol Version 3 (HTTP/3  ) . tools.ietf.org (9. juli 2019). Hentet 16. august 2019. Arkiveret fra originalen 31. august 2019.
  7. ↑ Cimpanu, Catalin . HTTP-over-QUIC skal omdøbes til HTTP/3 | ZDNet  (engelsk) , ZDNet . Arkiveret fra originalen den 13. november 2018. Hentet 10. august 2020.
  8. ↑ Cimpanu, Catalin Cloudflare, Google Chrome og Firefox tilføjer HTTP/3-understøttelse . ZDNet (26. september 2019). Hentet 27. september 2019. Arkiveret fra originalen 26. september 2019.
  9. ↑ HTTP/3: fortiden, nutiden og  fremtiden . Cloudflare-bloggen (26. september 2019). Hentet 30. oktober 2019. Arkiveret fra originalen 26. september 2019.
  10. ↑ Firefox Nightly understøtter HTTP 3 - Generelt - Cloudflare Community (19. november 2019). Hentet 23. januar 2020. Arkiveret fra originalen 6. juni 2020.

Links

 URI- ordninger
Officiel
uofficiel
 semantisk web
Grundlæggende
Underafsnit
Ansøgninger
relaterede emner
Standarder
  • Historie : Almindelig gammel semantisk HTML
  • DAML+OLIE
 HTTP
Generelle begreber
Metoder
Titler
Statuskoder