Varför behövs http-protokollet? Grunderna för webbapplikationer

För World Wide Web. Sådana protokoll är strukturerad text som använder logiska kopplingar (hyperlänkar) mellan noder som innehåller specifik data. Det är alltså ett sätt att utbyta eller överföra hypertext.

HTTP-protokollet fungerar som en begäran-svarsfunktion i en klient-server-beräkningsmodell. Således fungerar webbläsaren som en klient, och webbhotellet är servern. Klienten skickar ett HTTP-begäranmeddelande till en server som tillhandahåller vissa resurser (som HTML-filer och annat material) och returnerar sedan ett svarsmeddelande. Svaret innehåller information om begäran och kan även innehålla det begärda innehållet i meddelandets brödtext.

Webbläsaren är ett grundläggande exempel på en användaragent (klient). Andra typer av användaragenter inkluderar programvara som används för indexering av sökleverantörer, mobilapplikationer och andra resurser som konsumerar eller visar webbinnehåll.

HTTP-protokollet är utformat för att tillhandahålla mellanliggande nätverkselement för att förbättra eller möjliggöra kommunikation mellan klienter och servrar. Webbplatser med hög trafik drar ofta nytta av cachade webbservrar som serverar innehåll på uppdrag av uppströmsresurser, vilket minskar laddningstiderna. Webbläsarens cache tillåter användaren att minska nätverkstrafiken. Proxyservrar som använder HTTP-protokollet på ett lokalt nätverk kan tillhandahålla kommunikation för klienter som inte tillåter global adressdirigering genom att vidarebefordra meddelanden från externa servrar.

En HTTP-session är en sekventiell process av förfrågningar och svar. Klienten initierar en förfrågan genom att göra en TCP-anslutning till en specifik port på servern, och servern lyssnar på den porten och väntar på förfrågningsmeddelandet. När det tas emot skickar servern ett svarsmeddelande. Brödtexten i detta meddelande representerar vanligtvis den begärda resursen, även om ett felmeddelande eller annan information kan visas.

När man överväger syftet med HTTP-protokollet bör det noteras att det definierar metoder med syftet att specificera den önskade åtgärden som ska utföras på identifierade resurser. I det här fallet beror typen av information som visas (pre-existerande data eller dynamiskt genererad) på serverimplementeringen. Ofta motsvarar en sådan resurs en fil eller ett skript som finns på webbhotellet.

Vissa metoder som HTTP Hypertext Transfer Protocol använder är endast avsedda för hämtning av information och bör inte ändra serverns tillstånd. De har med andra ord ingen allvarlig inverkan, förutom de relativt ofarliga effekterna av cachning eller ökande besöksstatistik.

Å andra sidan kan HTTP-protokollet också använda metoder som är avsedda för åtgärder som kan påverka antingen servern eller andra externa resurser – för att aktivera finansiella transaktioner eller överföra e-post. Ibland används sådana metoder av webbrobotar eller vissa webbplatser och kan göra förfrågningar oavsett huvuduppgiften.

.) Det är tack vare möjligheten att specificera hur ett meddelande är kodat som klienten och servern kan utbyta binär data, även om detta protokoll är textbaserat.

Proxyservrar

Utvecklingshistoria

HTTP/0.9

Utöver den vanliga GET-metoden finns det även en distinktion. Villkorliga GET-förfrågningar innehåller If-Modified-Since, If-Match, If-Range och liknande rubriker. Partiella GET innehåller intervall i begäran. Förfarandet för att utföra sådana förfrågningar definieras separat av standarderna.

HUVUD

Liknar GET-metoden, förutom att det inte finns någon kropp i serversvaret. HEAD-begäran används vanligtvis för att hämta metadata, kontrollera om det finns en resurs (URL-validering) och se om den har ändrats sedan den senast användes.

Svarsrubriker kan cachelagras. Om en resurs metadata inte matchar motsvarande information i cachen, markeras kopian av resursen som inaktuell.

POSTA

Används för att överföra användardata till en specificerad resurs. Till exempel på bloggar kan besökare vanligtvis skriva in sina kommentarer på inlägg i ett HTML-formulär, varefter de läggs upp på servern och placeras på sidan. I det här fallet inkluderas de överförda uppgifterna (i exemplet med bloggar, texten i kommentaren) i förfrågan. På samma sätt laddas filer vanligtvis upp till servern med POST-metoden.

Till skillnad från GET-metoden anses POST-metoden inte vara idempotent, vilket innebär att upprepade POST-förfrågningar om och om igen kan ge olika resultat (till exempel, efter varje kommentar kommer en kopia av den kommentaren att visas).

Om exekveringsresultatet är 200 (Ok), bör ett meddelande om slutförandet av begäran inkluderas i svarskroppen. Om en resurs har skapats SKA servern returnera ett 201 (Skapat) svar med URI:n för den nya resursen i platshuvudet.

Serverns svarsmeddelande till POST-metoden cachelagras inte.

SÄTTA

Används för att ladda förfrågningsinnehållet till den URI som anges i begäran. Om en resurs inte finns vid den givna URI:n skapar servern den och returnerar status 201 (Skapad). Om resursen har ändrats returnerar servern 200 (Ok) eller 204 (Inget innehåll). Servern FÅR INTE ignorera ogiltiga Content-*-rubriker som skickas av klienten tillsammans med meddelandet. Om någon av dessa rubriker inte kan kännas igen eller inte är giltiga under nuvarande förhållanden, måste en felkod på 501 (ej implementerad) returneras.

Den grundläggande skillnaden mellan POST- och PUT-metoderna är förståelsen av syftet med resurs-URI. POST-metoden förutsätter att den angivna URIn kommer att bearbeta innehållet som skickas av klienten. Genom att använda PUT antar klienten att innehållet som laddas ner matchar resursen som finns på den givna URI:n.

Serversvarsmeddelanden till PUT-metoden cachelagras inte.

LAPPA

Liknar PUT, men gäller endast en del av resursen.

RADERA

Tar bort den angivna resursen.

SPÅR

Returnerar den mottagna begäran så att klienten kan se vilken information mellanservrar lägger till eller ändrar i begäran.

LÄNK

Upprättar en koppling mellan den angivna resursen och andra.

AVLÄNK

Tar bort anslutningen av den angivna resursen med andra.

ANSLUTA

Konverterar en begärananslutning till en transparent TCP/IP-tunnel, vanligtvis för att underlätta upprättandet av en säker SSL-anslutning via en okrypterad proxy.

Statuskoder

Statuskoden är en del av den första raden i serversvaret. Det representerar ett heltal av tre arabiska siffror. Den första siffran anger tillståndets klass. Svarskoden följs vanligtvis av en förklarande fras på engelska avgränsad med ett mellanslag, vilket förklarar för personen orsaken till just detta svar. Exempel:

201 Webbsida skapad 403 Åtkomst tillåts endast för registrerade användare 507 Otillräcklig lagring

Kunden lär sig av svarskoden om resultatet av sin begäran och bestämmer vilka åtgärder som ska vidtas härnäst. Uppsättningen av statuskoder är en standard och de beskrivs i motsvarande RFC:er. Införandet av nya koder bör endast göras efter överenskommelse med IETF. Klienten kanske inte känner till alla statuskoder, men den måste svara enligt kodens klass.

Det finns för närvarande fem klasser av statuskoder.

1xx informativ (ryska) Informationsinformation)

Denna klass innehåller koder som informerar om överföringsprocessen. I HTTP/1.0 bör meddelanden med sådana koder ignoreras. I HTTP/1.1 måste klienten vara beredd att acceptera denna klass av meddelanden som ett normalt svar, men behöver inte skicka något till servern. Själva meddelanden från servern innehåller endast startraden för svaret och, om så krävs, några svarsspecifika rubrikfält. Proxyservrar måste skicka sådana meddelanden vidare från servern till klienten.

2xx Framgång (ryska) Framgång)

Meddelanden från denna klass informerar om fall av framgångsrikt godkännande och bearbetning av en kundförfrågan. Beroende på status kan servern också sända meddelandets rubriker och brödtext.

3xx omdirigering (ryska) Omdirigering )

Klass 3xx-koder berättar för klienten att för att framgångsrikt slutföra operationen är det nödvändigt att göra en ny begäran (vanligtvis till en annan URI). Av denna klass hänför sig fem koder , , , och direkt till omdirigeringar (omdirigering). Servern anger adressen till vilken klienten ska göra förfrågan i platshuvudet. Det är dock möjligt att använda fragment i mål-URI.

4xx klientfel (ryska) Klientfel)

Kodklassen 4xx är avsedd att indikera fel på klientsidan. När du använder alla metoder utom HEAD måste servern returnera en hypertextförklaring till användaren i meddelandets brödtext.

För att komma ihåg värdena för koder från 400 till 417 finns det illustrativa mnemoniktekniker

5xx serverfel (ryska) Serverfel)

Koder 5xx tilldelas för fall av misslyckad drift på grund av fel på servern. För alla andra situationer än att använda HEAD-metoden måste servern inkludera en förklaring i meddelandet som klienten kommer att visa för användaren.

Rubriker

Meddelandetext

HTTP-meddelandekroppen (message-body), om sådan finns, används för att förmedla huvuddelen av objektet som är associerat med begäran eller svaret. Meddelandetexten skiljer sig från entitetskroppen endast när överföringskodning tillämpas, vilket indikeras av fältet Transfer-Encoding-huvud.

Message-body = entity-body |

Fältet Transfer-Encoding måste användas för att indikera eventuell överföringskodning som tillämpas av applikationen för att säkerställa att meddelandet överförs säkert och korrekt. Fältet Transfer-Encoding är en egenskap för meddelandet, inte objektet, och kan därför läggas till eller tas bort av vilken applikation som helst i begäran/svarskedjan.

Reglerna för huruvida en meddelandetext är acceptabel i ett meddelande är olika för förfrågningar och svar.

Förekomsten av en meddelandekropp i en begäran indikeras genom att lägga till ett innehållslängds- eller överföringskodningshuvudfält till förfrågningshuvudena. En meddelandetext (message-body) KAN läggas till i en begäran endast när begäranmetoden tillåter en enhetskropp.

Huruvida en meddelandetext är inkluderad i svarsmeddelandet eller inte beror på både förfrågningsmetoden och svarsstatuskoden. Alla svar på en begäran med HEAD-metoden får inte innehålla en meddelandekropp, även om entitetshuvudfält finns för att få en att tro att entiteten är närvarande. Inga svar med statuskoderna 1xx (Informativ), 204 (Inget innehåll) och 304 (Ej ändrad) måste innehålla en meddelandetext. Alla andra svar innehåller en meddelandetext, även om den har noll längd.

Exempel på HTTP-dialoger

Vanlig GET-förfrågan

Det finns två huvudtyper av godkännanden:

  • Serverhanterad Serverdriven).
  • Kundhanterade Agentdriven).

Båda typerna eller var och en av dem separat kan användas samtidigt.

Huvudprotokollspecifikationen (RFC 2616) lyfter också fram den så kallade transparenta förhandlingen. Transparent förhandling) som det föredragna alternativet för att kombinera båda typerna. Den senare mekanismen bör inte förväxlas med den oberoende teknologin Transparent Content Negotiation (TCN, ryska. Transparent innehållsförhandling , se RFC 2295), som inte är en del av HTTP-protokollet, men som kan användas med det. Båda har betydande skillnader i funktionsprincipen och själva innebörden av ordet "transparent". I HTTP-specifikationen betyder transparens att processen är osynlig för klienten och servern, och i TCN-tekniken innebär transparens tillgången till en komplett lista med resursalternativ för alla deltagare i dataleveransprocessen.

Serverhanterad

Om det finns flera versioner av en resurs kan servern analysera klientens förfrågningsrubriker för att producera vad den anser är den mest lämpliga versionen. De huvudrubriker som analyseras är Acceptera, Acceptera-Charset, Acceptera-Kodning, Acceptera-språk och User-Agent. Det är tillrådligt för servern att inkludera en Vary-rubrik i svaret som anger parametrarna med vilka innehållet i den begärda URI:n skiljer sig åt.

Den geografiska platsen för klienten kan bestämmas av fjärr-IP-adressen. Detta är möjligt på grund av att IP-adresser, som domännamn, är registrerade på en specifik person eller organisation. Vid registrering anger du i vilken region det önskade adressutrymmet ska användas. Dessa data är allmänt tillgängliga, och på Internet kan du hitta motsvarande fritt distribuerade databaser och färdiga programvarumoduler för att arbeta med dem (du bör fokusera på nyckelorden "Geo IP").

Man bör komma ihåg att denna metod är kapabel att bestämma platsen till maximalt en stad (härifrån bestäms landet). I detta fall är informationen relevant endast vid tidpunkten för registrering av adressutrymmet. Till exempel, om en Moskva-leverantör registrerar ett antal adresser som indikerar Moskva och börjar ge åtkomst till kunder från närmaste Moskva-region, kan dess abonnenter på vissa webbplatser observera att de är från Moskva, och inte från Krasnogorsk eller Dzerzhinsky.

Serverdriven förhandling har flera nackdelar:

  • Servern antar bara vilket alternativ som är mest att föredra för slutanvändaren, men kan inte veta exakt vad som behövs för tillfället (till exempel en version på ryska eller engelska).
  • Det har skickats många Acceptera grupprubriker, men få resurser med flera alternativ. På grund av detta utsätts utrustningen för stor belastning.
  • Den delade cachen är begränsad i sin förmåga att producera samma svar på identiska förfrågningar från olika användare.
  • Att skicka Accept-rubriker kan också avslöja viss information om dess preferenser, såsom språk som används, webbläsare, kodning.

Kunddriven

I det här fallet bestäms innehållstypen endast på klientsidan. För att göra detta returnerar servern med statuskod 300 (flerval) eller 406 (inte godtagbart) en lista med alternativ från vilka användaren väljer lämpligt. Klientdriven avstämning är bra när innehållet varierar på vanliga sätt (som språk och kodning) och en offentlig cache används.

Den största nackdelen är den extra belastningen, eftersom du måste göra en ytterligare begäran för att få önskat innehåll.

Transparent godkännande

Denna förhandling är helt transparent för klienten och servern. I det här fallet används en delad cache som innehåller en lista med alternativ, liknande klientdriven förhandling. Om cachen förstår alla dessa alternativ, gör den själva valet, som i serverdriven förhandling. Detta minskar belastningen på ursprungsservern och eliminerar ytterligare begäran från klienten.

Den grundläggande HTTP-specifikationen beskriver inte den transparenta förhandlingsmekanismen i detalj.

Flera innehåll

HTTP-protokollet stöder överföring av flera enheter inom ett enda meddelande. Entiteter kan dessutom överföras inte bara i form av en ennivåsekvens, utan i form av en hierarki med inkapsling av element i varandra. Medietyperna multipart/* används för att indikera flera innehåll. Arbete med sådana typer utförs enligt de allmänna reglerna som beskrivs i RFC 2046 (om inte annat anges av en specifik mediatyp). Om mottagaren inte vet hur den ska hantera typen, behandlar den den på samma sätt som multipart/mixed .

Gränsparametern betyder avgränsaren mellan de olika typerna av meddelanden som sänds. Till exempel skickar parametern DestAddress som skickas från formuläret värdet för e-postadressen, och elementet AttachedFile1 som följer efter det skickar det binära innehållet i bilden i .jpg-formatet

På serversidan kan meddelanden med flera innehåll skickas som svar på förfrågningar om flera resursfragment. I detta fall används mediatypen multipart/byteranges.

På klientsidan, när man skickar in ett HTML-formulär, används oftast POST-metoden. Ett typiskt exempel: e-postsändande sidor med bifogade filer. När du skickar ett sådant brev genererar webbläsaren ett meddelande av typen multipart/form-data, som integreras i det som separata delar som angetts av användaren, ämnet för brevet, mottagarens adress, själva texten och bifogade filer:

POST /send-message.html HTTP/1.1 Host: mail.example.com Referent: http://mail.example.com/send-message.html User-Agent: BrowserForDummies/4.67b Content-Type: multipart/form- data; boundary="Asrf456BGe4h" Innehållslängd: (total volym inklusive underordnade rubriker) Anslutning: keep-alive Keep-alive: 300 (tom rad) (saknas ingress) --Asrf456BGe4h Innehåll-Disposition: form-data; name="DestAddress" (tom rad) [e-postskyddad]--Asrf456BGe4h Innehåll-Disposition: form-data; name="MessageTitle" (tom rad) Jag är indignerad --Asrf456BGe4h Innehåll-Disposition: form-data; name="MessageText" (tom rad) Hej Vasily! Ditt husdjurslejon, som du lämnade hos mig förra veckan, rev sönder hela min soffa. Snälla hämta honom snart! Bifogat två bilder med konsekvenserna. --Asrf456BGe4h Innehåll-Disposition: form-data; name="AttachedFile1"; filename="horror-photo-1.jpg" Innehållstyp: image/jpeg (tom rad) (binärt innehåll i det första fotot) --Asrf456BGe4h Innehåll-Disposition: form-data; name="AttachedFile2"; filename="horror-photo-2.jpg" Innehållstyp: image/jpeg (tom rad) (binärt innehåll i andra bilden) --Asrf456BGe4h-- (saknar epilog)

I exemplet i Content-Disposition-rubrikerna motsvarar namnparametern namnattributet i HTML-taggarna Och