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
Protokollfunktioner
De flesta protokoll tillhandahåller etablering av en TCP-session, under vilken auktorisering sker en gång, och ytterligare åtgärder utförs i samband med denna auktorisering. HTTP, å andra sidan, upprättar en separat TCP-session för varje begäran; Senare versioner av HTTP tillät att flera förfrågningar gjordes under en enda TCP-session, men webbläsare begär vanligtvis bara sidan och dess inkluderade objekt (bilder, överlappande stilar, etc.) och avslutar sedan TCP-sessionen omedelbart. För att stödja auktoriserad (icke-anonym) åtkomst använder HTTP cookies; Dessutom tillåter denna auktoriseringsmetod dig att spara sessionen även efter att du har startat om klienten och servern.
Vid åtkomst till data via FTP eller filprotokoll bestäms filtypen (mer exakt vilken typ av data den innehåller) av filnamnstillägget, vilket inte alltid är bekvämt. HTTP, innan själva data överförs, sänder "Content-Type: type/subtype"-huvudet, vilket gör det möjligt för klienten att unikt bestämma hur de skickade data ska behandlas. Detta är särskilt viktigt när du arbetar med CGI-skript, när filnamnstillägget inte indikerar vilken typ av data som skickas till klienten, men behovet av att köra denna fil på servern och skicka till klienten resultaten av programmet som skrivits i denna fil (i det här fallet, samma fil i beroende på begärans argument och dess egna överväganden, den kan generera svar av olika typer - i det enklaste fallet bilder i olika format).
Dessutom tillåter HTTP klienten att skicka parametrar till servern som kommer att skickas till CGI-skriptet som startas. För detta ändamål introducerades formulär i HTML.
De listade funktionerna i HTTP gjorde det möjligt att skapa sökmotorer (av vilka den första var AltaVista, skapad av DEC), forum och internetbutiker. Detta kommersialiserade Internet, företag uppstod vars huvudsakliga verksamhetsområde var att tillhandahålla internetåtkomst (leverantörer) och skapa webbplatser.
Anteckningar
se även
Länkar
Om du ville veta hur data överförs på Internet är den här artikeln för dig. Jag kommer att berätta allt jag vet om HTTP- och HTTPS-protokollen, visa skillnaden och skillnaderna mellan dem. Njut av att läsa!
HTTP 1.1 - vad är detta protokoll?
HTTP (engelska: "Hypertext Transfer Protocol") är ett nätverksprotokoll på toppnivå för att överföra hypertext och godtyckliga data på Internet.
Med HTTP tar webbläsaren emot data från webbservrar och kan visa den i en form som är acceptabel och förståelig för Internetanvändare. Den omvända processen sker på exakt samma sätt - att skicka tillbaka användardata till servern (till exempel under registrering).
Innehåll som skickas från och till servern kan presenteras i vilken form som helst: bilder, filer, dokument, länkar och kod – i alla fall är det tack vare HTTP som människor kan använda Internet och ladda hundratals webbsidor i webbläsaren.
Den nuvarande protokollversionen är 1.1. Dess beskrivning finns i RFC-specifikationen.
HTTP används i klient-serverns dataöverföringsinfrastruktur. Hur det fungerar? Applikationen på "klient"-sidan genererar en begäran om behandling på "server"-sidan, varefter svaret skickas tillbaka till "klienten". "Kunden" kan sedan initiera ytterligare förfrågningar och få nya svar. Och så vidare.
Den vanligaste "klient"-applikationen är en webbläsare genom vilken webbresurser nås. Med utvecklingen av mobilteknologier har mobilapplikationer lagts till webbläsare på en mängd olika smartphones och surfplattor. Dessutom kan serversidan av moderna multidisciplinära applikationer samtidigt bearbeta data från både webbläsaren och smartphonen. Allt detta görs via HTTP-protokollet.
Dessutom fungerar HTTP ofta som ett transportprotokoll för att överföra andra applikationsprotokoll och deras API:er: WebDAV, XML-RPC, REST, SOAP. Tja, data som överförs via API:et kan ha en mängd olika format: XML, JSON och andra.
Hur överförs denna data? Oftast över en TCP/IP-anslutning: klientapplikationen använder TCP-port 80 som standard, och servern kan använda vilken som helst annan, men vanligtvis är detta också port 80.
Ett HTTP-manipulationsobjekt är en resurs som specificeras i begäran URI för en klientapplikation för att korrekt identifiera "vad som faktiskt behövs." Vanligtvis är dessa filer, data eller logiska objekt som lagras på en server. I det här fallet kan begäran ange exakt hur samma data ska presenteras: vilket format, kodning, språk att välja. Denna "funktion" låter dig utbyta inte bara hypertext, utan även binär data.
Den andra egenskapen hos HTTP är att den inte sparar tillstånd mellan på varandra följande begäran-svar-par. Men detta är inget problem eftersom applikationskomponenter på klient- eller serversidan själva kan lagra information om tillståndet för de senaste förfrågningarna och svaren. På klientsidan kallas sådan information cookies, på serversidan - sessioner.
Samtidigt är det inte ett problem för klientens webbläsare att övervaka serverns svarsfördröjning, och för servern är det inte ett problem att lagra rubrikerna för de senaste förfrågningarna och klientens IP-adresser. Men, jag betonar än en gång, protokollet i sig vet ingenting om detta - det överför bara data.
Mellanhänder (proxyservrar) kan också delta i dataöverföring för att särskilja proxyservrar från slutservrar (den så kallade ”källservern”).
Magin börjar när samma program (klient eller server) kan utföra funktionerna som en mellanhand, en klient eller en server - beroende på uppgifterna.
HTTP/2 - vad är detta för protokoll?
Den ursprungliga versionen av HTTP-protokollet dök upp på CERN 1991. Redan 1992 publicerades den offentliga versionen av HTTP 0.9 och dess specifikation, tack vare vilken reglerna för interaktion mellan klient- och serverapplikationer strömlinjeformades, samt en tydlig avgränsning av funktionalitet.
HTTP/1.0 dök upp 1996 och den moderna versionen av protokollet - HTTP/1.1 - 1999. Vid millennieskiftet lärde sig HTTP-protokollet att stödja beständigt anslutningsläge, d.v.s. lämna anslutningen öppen efter att ett svar på en begäran har mottagits. Detta gjorde det möjligt att skicka flera förfrågningar samtidigt i en anslutning, snarare än att öppna och stänga sessionen varje gång.
Tiden gick och allt eftersom internet utvecklades ökade storleken på sidorna, antalet förfrågningar växte – allt mer resurser krävdes. Så här uppstod behovet av ett nytt protokoll.
Och sexton år senare, 2015, publicerades den slutliga versionen av utkastet till specifikation för nästa version av protokollet, HTTP/2. Det binära protokollet HTTP/2 är mer förberett för moderna realiteter än sin föregångare HTTP 1.1 eftersom det nya protokollet löser det mest betydande problemet med dataöverföring på Internet - flera öppna anslutningar.
Och allt för att nuvarande webbplatser laddar många element, både från deras server och från CDN: JS-skript, CSS-stilar, typsnitt och bilder. När en komplett uppsättning filer överförs med HTTP 1.1-protokollet skapas flera anslutningar. Om vi i framtiden byter till HTTP/2-protokollet kommer överföringen att ske inom en enda anslutning mellan klienten och servern, vilket avsevärt kommer att påskynda och optimera laddningen av webbplatsinnehåll.
Nyckelfunktioner i HTTP/2 som kommer att vara användbara för webbplatser:
- Ordna och hantera prioriteringar av förfrågningar/flöden - klienten ställer självständigt in prioritet för resurser och data för servern
- HTTP-huvudkomprimering;
- Begär multiplexering eller parallellladdning av flera platselement över en TCP-anslutning - flera förfrågningar skickas via en anslutning, och klienten kan ta emot svar i valfri ordning, d.v.s. behöver inte längre flera öppna TCP-anslutningar;
- Tillgänglighet och support från servern av proaktiva push-meddelanden - servern kan självständigt skicka data till klienten som klienten ännu inte har begärt (till exempel baserat på information om vilken sida användaren kommer att öppna efter denna).
Naturligtvis är det viktigaste här stream multiplexing. Funktionsprincipen är lätt att förklara: TCP/IP-anslutningspaket blandas i en anslutning. I blandat läge är således flera "databilar" kopplade till ett "tåg", som separeras "vid ankomst". Tidigare var "bilarna" tvungna att resa längre och separat, men nu kommer de att resa tillsammans och snabbare.
Ovanstående fördelar med HTTP/2-protokollet gör det möjligt för webbutvecklare att andas djupt och överge sådana "kryckor" som:
- Användning av ett större antal relaterade domäner för att säkerställa upprättandet av ett stort antal TCP/IP-anslutningar (för nedladdning av filer);
- Image sprites - när bilder kombineras till en fil för att minska antalet förfrågningar till webbservern (och själva filen "sväller upp" eftersom fler bilder skrivs till den);
- Kombinera CSS- och JS-filer, som också är gjorda för att minska förfrågningar.
Den sista uppenbara fördelen är att du inte behöver göra något extra med själva webbplatsen (för att aktivera HTTP/2) - allt arbete utförs på servern med nästan "1 klick", och för klienter med delad och VPS-hosting det kommer i allmänhet att gå obemärkt förbi.
Med ett ord, vi kommer att leva!
HTTP/2 skapades och utvecklades baserat på utkastet till SPDY/3-protokollet (Google) och överträffade det - Google insåg fördelarna med HTTP/2 som mer lovande och kommer att överge stödet för SPDY/2 i framtiden.
Den förväntade accelerationen av serversvaret via HTTP/2-protokollet kommer att vara cirka 30 % - riktiga tester har redan visat hastigheter 19-23 % högre och detta är inte gränsen.
Enligt resultaten av tester av Airi.rf är hastighetsökningen från att bara aktivera HTTP/2-protokollet 13-18 % (utan optimering). Varför är det viktigt?
Trots att en webbplats stöd för HTTP/2-protokollet för närvarande inte direkt påverkar rankningen av webbplatser i Google och Yandex, påverkas positionerna i sökresultaten av laddningshastigheten. Och eftersom protokollet visar en högre nedladdningshastighet (vilket är en ganska betydande faktor) påverkar det indirekt rankningen.
Främst på grund av beteendefaktorer. Laddningsacceleration tillåter användare att vara mindre trötta och mer fokuserade på att utforska webbplatsen: se fler sidor och inte lämna webbplatsen på grund av långa laddningstider (studsar minskas).
De flesta moderna webbläsare stöder redan HTTP/2 - ~70 % av internettrafiken passerar genom dem:
- Chrome 41-52 och Chrome 46+ på Android;
- Firefox 36-48 och Firefox 41+ på Android;
- Opera 28-34 och Opera 30+ på Android;
- Safari 9 och Safari i iOS 9.1;
- IE 11 på Windows 10 och Edge-webbläsaren 12, 13.
Det är ännu inte klart när en fullständig övergång till HTTP/2 kommer att ske - med största sannolikhet inom en mycket snar framtid. Huvudsaken är att ingen hastigt kommer att överge HTTP/1.x. Som de säger: "Om det fungerar, rör det inte."
Vad betyder HTTPS-protokollet och var används det?
Tja, du vet redan allt om datautbyte med HTTP-protokollet: all dataöverföring utförs genom förfrågningar som använder detta transportprotokoll. Varför behöver vi då HTTPS och vad är det? Vi levde trots allt normalt utan honom?
Problemet är att data via HTTP inte är skyddad och överförs i klartext. Internet är ett globalt distribuerat nätverk av noder. Och om du överför öppna data med ett osäkert protokoll (Wi-Fi i ett köpcentrum gäller också här), då kan en av dessa noder avlyssna det.
Inte med avsikt, naturligtvis, det kan bara vara hacking av kriminella. HTTPS skapades för att säkerställa att anslutningen är säker och att data överförs i krypterad form med SSL/TLS-krypteringsprotokollet. Detta är en speciell "wrapper" ovanpå HTTP, den krypterar data, vilket gör den otillgänglig för inkräktare och obehöriga.
HTTPS - engelska "Säkert Hypertext Transfer Protocol".
Så, till skillnad från standardporten 80 i HTTP, använder HTTPS TCP-port 443 och har en krypteringsnyckel. Nyckeln kan vara 40, 56, 128 eller 256 bitar lång en tillräcklig säkerhetsnivå börjar för närvarande med 128-bitars nycklar.
Nu stöder alla webbläsare HTTPS - den slås på automatiskt när det är möjligt och servern kräver det.
Det är viktigt att använda HTTPS i följande tjänster:
- Elektroniska betalningssystem (banker, elektroniska pengar, etc.);
- Tjänster som tar emot och skickar privat information och personlig data, till exempel, Yandex har: Pass, Taxi, Direct, Metrica, Mail, Money, Webmaster och andra;
- Sociala nätverk och personliga konton i Internettjänster;
- Sökmotorer.
HTTPS fungerar helt enkelt. Jag ska förklara med ett exempel.
Du lägger viktig information (inloggning, lösenord, kortuppgifter, personlig data) i en cell, "låser den med en nyckel": cellen krypterar dina data med denna nyckel.
Skicka det nu via post till adressaten. Adressaten tar emot paketcellen, men kan inte öppna den - han har inte nyckeln. Sedan låser (krypterar) han cellen med ett andra lås och returnerar paketet till dig. Du får ett paket med två lås, men du har nyckeln till ett. Nu kan du låsa upp ditt lås (dekryptera data) och skicka tillbaka paketet igen till den ursprungliga mottagaren.
Samtidigt förblir datan skyddad - trots allt har den inte setts eller ändrats av någon och tills den tas emot av mottagaren skyddas den av en krypterad nyckel. Adressaten tar emot paketet, redan med ett lås, dekrypterar det och behandlar dina uppgifter. Till exempel utför den din transaktion.
Det är det – det är så HTTPS fungerar.
Tricket här är att under det första sådana utbytet utbyts krypteringsnyckeln så att den är känd för båda slutmottagarna, men inte känd för någon av noderna längs datavägen. Efter att ha bytt chiffer kan du fritt utbyta meddelanden (krypterade) utan rädsla för avlyssning av dessa data, för utan chiffernyckeln kommer det inte att vara möjligt att öppna och läsa den.
Den enda varningen här är att du behöver veta att du skickar data exakt dit den behövs. Och att den sista punkten är destinationen. Men du måste bekräfta och veta säkert att slutdestinationen finns och styrs av just den server dit data skickas.
För att göra detta får servrar speciella HTTPS-säkerhetscertifikat från certifieringscenter, som bekräftar destinationens "finalitet" (att webbplatsen inte är en nod som vidarebefordrar data) och funktionaliteten hos SSL/TLS-krypteringstekniken, d.v.s. anslutningssäkerhet.
Och så här ser själva certifikatet ut:
För närvarande är HTTPS inbyggt i alla moderna webbläsare och allt som krävs av användaren för att upprätthålla säkerheten för att skicka data via HTTPS är att regelbundet uppdatera mjukvaran för att surfa, ta emot och skicka viktig data på Internet.
Genom att utföra klient-server-interaktion via HTTPS-protokollet behöver du inte oroa dig för säkerheten för dina data - du är tillförlitligt skyddad från avlyssning av din nätverksanslutning: snifferattacker och man-in-the-middle-attacker.
Vad betyder den överstrukna HTTPS-ikonen och den gröna HTTPS-ikonen, vad är skillnaden? I säkerhet. Grönt är säkert, rött och överstruket är osäkra.
Och det är väldigt bekvämt att den överkorsade HTTPS-ikonen betyder att anslutningen inte är säker trots användningen av detta protokoll. Detta händer när webbplatselement inte laddas via HTTPS eller när certifikatet har löpt ut. Användaren kan omedelbart se - ja, det är osäkert. Och han kan lämna webbplatsen eller riskera sin data.
Vilket är bättre HTTP 1.1, HTTP/2 eller HTTPS?
För att sammanfatta kommer jag att beröra ämnet att föredra användning av protokoll.
Det är tydligt att för tillfället är HTTP 1.1 det vanligaste protokollet och används som standard. Tiden för HTTP/2 har ännu inte kommit, men snart kommer den mesta internettrafiken att gå genom den andra versionen av HTTP-protokollet. Detta kommer att göra livet enklare för användarna eftersom webbplatser laddas snabbare. Server- och webbplatsadministratörer kommer också att vara glada, eftersom det nya protokollet låter dig optimera webbplatser på ett nytt sätt, vilket påskyndar laddningen och uppladdningen av data.
Samtidigt är det knappast möjligt att alla sajter går över till HTTPS, för i syfte att konsumera underhållningsinnehåll är kryptering värdelös. Ja, nu använder 10 % av webbplatserna HTTPS i Alexa-rankningen av de mest besökta webbresurserna. Men detta är bara tio procent, inklusive sådana jättar som Google, PayPal, Amazon, Aliexpress och andra. Det vill säga, det finns många webbplatser där att inte använda HTTPS innebär att man bryter mot Internetanvändarens rätt till säkerhet och dataintegritet.
Men vanliga sajter som bloggen för sju bloggare behöver inte HTTPS - det finns ingen mottagning av personlig information eller betalningsdata, ingen registrering och ingen sändning av viktiga meddelanden.
Så inom en snar framtid kommer vi gradvis att gå bort från HTTP 1.1 till förmån för HTTP/2 och HTTPS.
Huvudprotokollet för sidor på Internet är HTTP. Detta protokoll används varje gång du besöker en ny sida, när text eller bild visas på sidan, när du klickar på länkar.
Hela Internet är baserat på HTTP, även om de flesta användare inte har någon aning om hur populär HTTP är i deras dagliga liv.
HTTP är det protokoll som används för att överföra hypertext (HyperText Transfer Protocol).
Interaktionen mellan din webbläsare och servern med information baseras på detta protokoll. Tack vare sin enkelhet ansluter webbläsaren och servern mycket snabbt. Men vi behöver inte fördjupa oss i alla detaljer i protokollet, vi kommer bara att förklara den grundläggande principen för dess funktion.
Det finns många protokoll du kan använda på Internet, HTTP är bara ett av många, som har sina egna uppgifter och syften.
Det är så enkelt att du redan är bekant med programvaran som behövs för att arbeta med HTTP - din webbläsare.
Oavsett namnet på webbläsaren läggs protokollnamnet alltid till i adressfältet som standard: "http://". Du kanske inte ser den här texten om webbläsaren döljer den. Men du behöver bara kopiera namnet på webbplatsen, och HTTP-protokollet kommer att infogas tillsammans med det på rätt plats.
- Vad betyder prefixet "http://" före webbplatsens namn?
– Det betyder att du kommer åt resursen via HTTP-protokollet.
Varför skapades HTTP-protokollet?
Med dess hjälp överförs hypertextdokument, eller, enklare, sidor på de webbplatser vi behöver.
Klienten (webbläsaren) tar emot webbsidor och servern skickar sidorna. Denna teknik kallas klient-server-teknik.
Tack vare HTTP har det blivit möjligt att överföra webbsidor på Internet. Men vad finns i själva sidorna som servern skickar till oss? Vanlig HTML-kod som kommer in i webbläsaren, som bara kan tolka den mottagna informationen korrekt och visa dig den färdiga sidan.
Så sent som 2006 kom nästan hälften av Nordamerikas HTTP-trafik från strömmande ljud och video.
Hur HTTP fungerar
- Webbläsaren skickar en begäran som begär den önskade serversidan.
- Servern tar emot begäran och börjar söka efter sidan.
- Webbläsaren får ett svar från servern med resultatet av begäran:
- Kod för den begärda sidan och tjänstinformation - om sidan hittas.
- Felkod och serviceinformation vid fel.
När en webbläsare gör en begäran om en fil, innehåller begäran ett speciellt HTTP-kommando. Om den begärda filen faktiskt finns på servern skickas filen. Men den mottagande sidan måste bestämma om filen ska visas på skärmen, sparas på disk eller göra något annat med resultatet.
För att identifiera resurser i nätverket använder HTTP-protokollet globala URI:er. Skillnaden mellan HTTP och andra protokoll är att det inte sparar sitt tillstånd. Det vill säga att tillståndet mellan begäran-svarsparet inte sparas.
HTTP är inte det enda protokollet som används på Internet. Används även:
- FTP (File Transfer Protocol) är ett filöverföringsprotokoll.
- POP (Post Office Protocol) och SMTP (Simple Mail Transport Protocol) - för utbyte av e-postmeddelanden.
- SHTTP (Secure Hypertext Transfer Protocol) är en krypterad version av HTTP. Information som överförs via detta protokoll är krypterad. Vanligtvis är säkerheten viktig när känslig information utbyts.
Och andra protokoll som har en bra egenskap - de fungerar alla obemärkt för dig och mig.
Mars 1991 - Tim Berners-Lee föreslog att använda HTTP.
Det var Berners-Lee som utvecklade alla de första sakerna som var kopplade till Internet: webbläsaren, servern, hyperlänkar, den första webbplatsen (info.cern.ch Du kan se hur den första webbplatsen såg ut genom att följa länken).
Versioner av HTTP har förbättrats med tiden; HTTP 1.1 har blivit populärt, vilket gör att du kan lämna anslutningen mellan servern och webbläsaren öppen under lång tid, vilket gjorde protokollet mer effektivt.
2015 dök HTTP/2 upp, som blev binärt, och sättet som information bröts upp i fragment förändrades.
HTTP-säkerhet
HTTP i sig innebär inte kryptering av information. Men det finns en protokollförlängning som kan packa data i SSL- eller TLS-protokollet.
HTTPS (S - Secure) är en populär lösning som inte tillåter avlyssning av överförd information och skyddar information från "man-in-the-middle" MITM-attacker eller man-in-the-middle-attacker.
MITM är i grunden en skadad telefon där information avsiktligt ändras. Varken klienten eller servern känner till ersättningen.
Vad består HTTP av?
Vi har nämnt mycket att servern och klienten skickar och tar emot förfrågningar. Så vad innehåller dessa förfrågningar? Varje HTTP-meddelande består av tre delar:
- Startraden, som anger meddelandetypen.
- Rubriker som kännetecknar meddelandets brödtext.
- Meddelandets brödtext, som redan innehåller nödvändig information.
Tack vare funktionerna i HTTP kunde de skapa sökmotorer, forum och onlinebutiker. Handel kom till Internet, Internetleverantörer och andra företag vars verksamhet sker på Internet började dyka upp. Och allt tack vare HTTP-protokollet, som du nu är mycket bekant med.
HTTP-protokollet eller HyperText Transfer Protocol är huvudprotokollet (på World Wide Web). Huvuduppgiften för protokollet är att säkerställa överföringen av hypertext på nätverket. Protokollet beskriver exakt meddelandeformatet för utbyte av klienter och servrar.
HTTP-protokollet beskrivs i RFC 2616(HTTP1.1).
Grunden för protokollet är att säkerställa interaktion mellan klienten och servern genom att använda en ASCII-begäran och följande svar på den i RFC 822 MIME-standarden.
I praktiken fungerar HTTP-protokollet på port 80, men kan konfigureras annorlunda. Och även om TCP/IP inte är obligatoriskt är det fortfarande att föredra, eftersom det tar hand om att dela upp och sammanställa meddelanden och inte "anstränger" varken webbläsaren eller servern.
Det bör noteras att HTTP-protokollet inte bara kan användas i webbteknologier utan även i andra OOP-applikationer (objektivt orienterade).
URL
Grunden för klient-server webbkommunikation är begäran. Begäran skickas med en URL – Uniform Internet Resource Locator. Låt mig påminna dig om vad en URL är.
En tydlig och enkel URL-struktur består av följande element:
- Protokoll;
- Värd;
- Hamn;
- Resurskatalog;
- Etiketter (Fråga).
Obs: http-protokollet är ett protokoll för enkla, osäkra anslutningar. Säkra anslutningar fungerar med https-protokollet. Det är säkrare för datautbyte.
HTTP-begäransmetoder
En av URL-parametrarna anger namnet på den värd som vi vill kommunicera med. Men detta räcker inte. Du måste bestämma vilken åtgärd som måste vidtas. Detta kan göras med en metod som definieras av HTTP-protokollet.
HTTP-metoder
- Metod/beskrivning
- HEAD/Läs titeln på webbsidan
- GET/Läs webbsida
- POST/Lägg till på webbsida
- PUT/Spara webbsida
- TRACE/Skicka tillbaka begäran
- DELETE/Ta bort en webbsida
- ALTERNATIV/Visningsalternativ
- ANSLUT/Reserverad för framtida bruk
Låt oss titta på HTTP-metoder mer i detalj
GET-metoden. begär en sida (fil, objekt) kodad med MIME-standarden. Detta är den mest använda metoden. Metodstruktur:
GET filnamn HTTP/1.1
HEAD-metod. Denna metod begär meddelandehuvudet. Sidan laddas dock inte. Den här metoden låter dig ta reda på när sidan senast uppdaterades, vilket är nödvändigt för att hantera sidcachen. Med den här metoden kan du kontrollera funktionen hos den begärda webbadressen.
PUT-metoden. Denna metod kan placera sidan på servern. PUT-begäran innehåller sidan som ska vara värd, vilken är MIME-kodad. Denna metod kräver klientidentifikation.
POST-metoden. Denna metod lägger till innehåll på en befintlig sida. Används som exempel för att lägga till ett inlägg i ett forum.
DELETE-metod. Denna metod förstör sidan. Raderingsmetoden kräver bekräftelse av användarens rättigheter att radera.
TRACE-metoden. Detta är en felsökningsmetod. Den instruerar servern att skicka tillbaka begäran och låter den veta om klientens begäran är skadad eller inte när den återvänder från servern.
CONNECT-metoden– reservmetoden, används inte.
OPTIONS metod låter dig fråga serveregenskaper och egenskaper för vilken fil som helst.
Vid begäran-svar-kommunikation mellan klienten och servern genererar servern nödvändigtvis ett svar. Detta kan vara en webbsida eller en statusrad med en statuskod. Du känner till statuskoden väl. En av koderna är den välkända koden 404 – Sidan hittades inte.
Statuskodgrupper
1хх: Serverberedskap, kod 100 – servern är redo att behandla klientförfrågningar;
2xx: Framgång.
- Kod 200 – begäran behandlades framgångsrikt;
- Kod 204 – Inget innehåll.
3xx: Omdirigering.
- Kod 301 – Den begärda sidan har flyttats;
- Kod 304 – Sidan i cachen är fortfarande relevant.
4xx: Klientfel.