Гісторыя развіцця HTTP
Ці ведаеце вы пра розніцу паміж рознымі версіямі пратакола HTTP?
Калі сумняваецеся ў адказе, - давайце разбірацца!
HTTP (HyperText Transfer Protocol) - гэта пратакол для перадачы даных, які служыць асновай Сусветнага павуціння (World Wide Web).
HTTP - пратакол прыкладнога ўзроўню, які выкарыстоўвае магчымасці пратаколаў TCP/IP.
HTTP/0.9
Быў створаны ў 1991 годзе і першапачаткова не меў звязанага з ім нумара версіі. Пазней, каб адрозніваць ад іншых будучых версій, ён быў названы версіяй 0.9 (HTTP/0.9). Спачатку ствараўся для перадачы гіпертэксту (тэкст са спасылкамі), а пазней і для адвольных даных.
Пратакол атрымаўся просты, з ім можна было працаваць як з графічнага браўзера (WorldWideWeb), так і з тэкставага (Line Mode).
Цікавостка! А вось так выглядаў першы сайт, створаны Цімам Бернарсам-Лі!
Запыт ўяўляе сабой запіс у адзін радок GET-запыт і шлях да дакумента. Завяршыць запыт трэба было зваротам карэткі (CRLF). Не перадаваўся ні сервер, ні пратакол, ні порт.
Сервер вяртае гіпертэкст, перададзены ASCII-знакамі.
Пасля гэтага злучэнне закрываецца.
text1// Request 2 3$telnet GET /index.html
text1// Response 2 3<html>First page</html>
Асаблівасці HTTP/0.9:
- Кліент-серверны пратакол прыкладнога ўзроўню
- Разумеў толькі
ASCII-знакі - Працаваў паверх стэка пратаколаў
TCP/IP - Злучэнне пасля запыта / водкліка зачыняецца
- Порт, сервер і пратакол не перадаваліся.
Чаго яшчэ не было:
- яшчэ не было магчымасці выкарыстоўваць іншыя
HTTP-метады акрамяGET - не існавала загалоўкаў
- не існавала статус-кодаў. Для паведамлення аб праблеме ствараўся асобны
HTML, які мог паведаміць карыстальнікам аб праблеме. - не магчыма было працаваць з рознымі тыпамі файлаў
- не дазваляў атрымаць доступ праз proxy
- не было headers ў
HTML-дакуменце. Толькі самHTML.

HTTP/1.0
1991 - 1995 гады азначаюцца буйным развіццём HTML, новага пакалення праграм, вядомых як "веб-браўзеры", з'яўленнем і хуткім ростам агульнадаступнай інтэрнэт-інфраструктуры. Патрэбны быў пратакол, які дазваляў не толькі перадаваць гіпертэкставы дакумент, але і прадастаўляць больш пашыраныя метаданыя аб запыце і адказе, дазваляць узгадненне кантэнту, перадаваць іншыя тыпы файлаў і гэтак далей. У адказ на гэта была створана вялікая колькасць эксперыментальных HTTP-сервераў і кліенцкіх рэалізацый.
У траўні 1996 года працоўная група HTTP (HTTP-WG) апублікавала RFC 1945, у якім было задакументавана «агульнае выкарыстанне» многіх рэалізацый HTTP/1.0, якія сустракаліся. Гэта быў толькі інфармацыйны RFC. Таму HTTP/1.0 не з'яўляўся афіцыйнай спецыфікацыяй або інтэрнэт-стандартам.
text1// Request 2GET /index.html HTTP/1.0 3User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) 4 5// Response 1 6200 OK 7Date: Sun, 01 Jan 1995 12:01:00 GMT 8Server: CERN/3.0 libwww/2.17 9Content-Type: text/html 10 11<html> 12Welcome to the <img src="/logo.gif"> example.ai homepage! 13</html> 14 15// Request 2 16GET /logo.gif HTTP/1.0 17User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) 18 19//Response 2 20200 OK 21Date: Sun, 01 Jan 1995 12:01:01 GMT 22Server: CERN/3.0 libwww/2.17 23Content-Type: text/gif 24 25<Encoded data of logo.gif>
Асаблівасці HTTP/1.0:
- Падтрымлівае ужо некалькі метадаў запыту:
GET,HEADіPOST. Цікава адзначыць, штоPOSTбыў уведзены для адпраўкі паведамлення ад сервера да кліента, у той час як раней сувязь была па сутнасці аднабаковай. - З'явіліся новыя тэрміны:
user agent,proxy,gateway,cache,resource,client,server. - Інфармацыя аб версіі HTTP-пратакола адпраўлялаецца ў кожным запыце.
- Замест адпраўкі адмысловага файла з памылкай з'являюцца статусы адказу, якія адлюстроўваюць поспех ці няўдачу, пакідаючы больш магчымасцяў для апрацоўкі адказу браўзеру.
- Загалоўкі могуць складацца з некалькіх радкоў. Для іх выкарыстоўвалася кадзіроўка
ASCII. З загалоўкамі дадалася магчымасць для кадзіравання, кэшавання, аўтарызацыі, выкарыстоўвання proxy і інш. - Адказ можа змяшчаць не толькі гіпертэкст.
- Злучэнне паміж серверам і кліентам зачыняецца пасля кожнага запыту.
То бок, HTTP з пратакола для перадачы гіпертэксту пераўтварыўся ў пратакол для перадачы гіпермедыа, але назва засталася папярэдняй.
Аднак,
HTTP/1.0не з'яўляецца афіцыйным стандартам.
HTTP/1.1
Праца па пераўтварэнні пратакола HTTP у афіцыйны web-стандарт ішла на працягу прыкладна 4 гадоў з 1995 па 1999 гады.
Першы афіцыйны стандарт быў выпушчаны ў студзені 1997 года. Гэта прыкладна праз паўгода пасля з'яўлення HTTP/1.0.
Праз 2.5 гады, у чэрвені 1999 года ў стандарт быў дададзены шэраг паляпшэнняў і ўдакладненняў. Наступны шэраг паляпшэнняў быў дададзены ў червені 2014 года.
Стандарт HTTP/1.1 вырашыў шмат неадназначнасцей пратаколу, выяўленых у больш ранніх версіях, і ўвёў шэраг крытычна важных аптымізацый: злучэнні для падтрымання актыўнасці, перадачы кадзіравання з фрагментамі, запыты дыяпазону байтаў, дадатковыя механізмы кэшавання, кадзіроўкі перадачы і канвеерную перадачу запытаў.
text1// Initial request 2GET /index.html HTTP/1.1 3Host: www.example.ai 4User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) 5Accept: text/html 6Accept-Language: en-US, en; q=0.5 7Accept-Encoding: gzip, deflate 8 9// Response 10200 OK 11Server: Apache 12Date: Thu, 01 Jan 1998 12:01:00 GMT 13Connection: Keep-Alive 14Keep-Alive: timeout=5, max=500 15Content-Encoding: gzip 16Content-Type: text/html; charset=UTF-8 17Last-Modified: Mon, 29 Dec 1997 12:15:00 GMT 18Transfer-Encoding: chunked 19 20<html> 21Welcome to the <img src=”/logo.gif”> example.ai homepage! 22</html> 23 24// Second request (same connection) 25GET /logo.gif HTTP/1.1 26Host: www.example.ai 27User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) 28Accept: */ * 29Accept-Language: en-US, en; q=0.5 30Accept-Encoding: gzip, deflate 31 32// Response 33200 OK 34Age: 8450220 35Cache-Control: public, max-age=315360000 36Connection: Keep-Alive 37Content-Type: image/gif 38Content-Length: 5000 39Date: Thu, 01 Jan 1998 12:01:01 GMT 40Last-Modified: Sun, 01 Jan 1995 12:01:00 GMT 41Server: Apache 42 43<The binary data for a 5K GIF image is included in the message body>
Асаблівасці HTTP/1.1:
- Пасля выконвання запыту
TCP-злучэнне магло заставацца адкрытым і выкарыстоўвацца для наступных запытаў. Напрыклад, калі ўHTML-файле патрабаваліся выявы, то злучэнне не адчыняецца зноў, а выкарыстоўваецца папярэдняе. - Падтрымка віртуальных хастоў, якія дазваляюць серверам абслугоўваць некалькі даменаў на адным
IP-адрасе. - На момант публікацыі першай версіі стандарту ўжо падтрымліваліся метады
GET,POST,PUT,DELETE,HEAD,OPTIONS,TRACE. Крыху пазней дадалісяPATCHіCONNECT. - З'явіліся дадатковыя магчымасці кіраваннем кэшавання, падтрымкі розных моў, тыпаў файлаў, якія робяць магчымымі ўзгадненні паміж кліентам і серверам аб асаблівасцях і перавагах адказу.
- Падтрымка частковых запытаў
- Запыты дыяпазону байтаў
У 1994 годзе з'явілася пашырэнне
HTTPS, якое выкарыстоўвала дадатковы слой для шыфравання -SSL(пазней змяніўся наTSL).
HTTP/2.0
Пад цяжарам уласнага поспеху і па меры таго, як мы ўсё больш працягваем пераносіць наша штодзённае ўзаемадзеянне ў Інтэрнет - сацыяльныя сеткі, электронную пошту, навіны і відэа, і ўсё часцей усю асабістую і працоўную прастору - HTTP-пратакол таксама пачаў выяўляць прыкметы стрэсу. Карыстальнікі і вэб-распрацоўшчыкі цяпер патрабуюць ад HTTP/1.1 хуткасці рэагавання амаль у рэжыме рэальнага часу і прадукцыйнасці пратакола, чаго ён проста не можа выканаць без некаторых мадыфікацый.
11 лютага 2015 года былі апублікаваныя фінальныя версіі чарнавіка версіі пратакола. У адрозненне ад папярэдніх версій, пратакол HTTP/2 з'яўляецца бінарным. Асноўная мэта HTTP/2 заключалася ў памяншэнні затрымкі шляхам уключэння поўнага мультыплексавання запытаў і адказаў, мінімізацыі накладных выдаткаў на пратакол за кошт эфектыўнага сціску палёў загалоўкаў HTTP і дадання падтрымкі прыярытэтаў запытаў і адпраўкі на сервер. Гэта прывяло да стварэння новага бінарнага пласта фармату дадзеных, які не мае зваротнай сумяшчальнасці з HTTP/1.x серверамі і кліентамі.
Важна адзначыць, што ні адна з семантыкі пратаколу высокага ўзроўню не закранаецца: усе HTTP-загалоўкі, метады HTTP, коды стану, URI і выпадкі выкарыстоўвання аднолькавыя. Замест гэтага HTTP/2 змяняе тое, як даныя фарматуюцца (афармляюцца ў кадры) і перадаюцца паміж кліентам і серверам, абодвы з якіх кіруюць усім працэсам, і хаваюць усю складанасць нашых прыкладанняў у новым узроўні кадравання. HTTP/2 дазваляе перамяжоўваць паведамленні запыту і адказу ў адным і тым жа злучэнні праз мультыплексаванне, якое раней было абмежаваннем канвеера.
Мультыплексаванне дазволіла двухнакіраваны паток сегментаў запытаў і адказаў паміж кліентам і серверам без неабходнасці відавочнага парадку паміж імі. Гэта стала магчыма дзякуючы ўвядзенню канцэпцыі патокаў.
Паток - гэта лагічны адзінкавы запыт/адказ, пазначаны агульным ідэнтыфікатарам патоку.
Існавала праблема "head-of-line blocking" ( калі адзін запыт у выніку затрымкі блакуе перадачу наступных запытаў з данымі). Мультыплексаванне дазволіла вырашыць праблему "head-of-line blocking" на узроўні HTTP. Кожны фрэйм (мінімальная частка даных) зараз мае ідэнтыфікатар патоку, таму парадак перадачы больш не важны.
Але на транспартным узроўні (TCP) праблема засталася. TCP успрымае і працуе з данымі як з аднабайтавым патокам. Праблема ўзнікае, калі пакеты, якія змяшчаюць даныя «ў пачатку радка», губляюцца, таму што астатнія пакеты, адпаведна, затрымліваюцца, пакуль не будуць знойдзеныя адсутныя.
Сярод ключавых асаблівасцяў:
- Двайковы пратакол, а не тэкставы. Яго нельга прачытаць і стварыць уручную.
- Мультыплексаванне запытаў для адной крыніцы (некалькі паралельных запытаў могуць выкарыстоўваць адно злучэнне).
- Расстаноўка прыярытэтаў для запытаў (push-паведамленняў). Гэта дазваляе серверу самастойна ініцыяваць перадачу дадзеных. Сервер можа расстаўляць прыярытэты для праштурхоўваемых рэсурсаў - гэта ключавое адрозненне ў прадукцыйнасці
HTTP/2адHTTP/1. - Прымусовае cціскванне загалоўкаў з выкарыстаннем палепшаных алгарытмаў, якія паляпшаюць прадукцыйнасць, а таксама бяспеку.
Выкарыстанне HTTP/2 складае зараз 39.2% ад ўсіх сайтаў. HTTP/2 не патрабуе змен у вэб-сайтах і праграмах. Каб выкарыстоўваць яго, неабходны толькі абноўлены сервер, які ўзаемадзейнічае з апошнімі версіямі браўзера.
HTTP/2- гэта альтэрнатыва, якая не робіцьHTTP/1.1састарэлым. Семантыка тая ж, што азначае зваротную сумяшчальнасць, спосаб перадачы даных палепшаны. У выніку атрымліваецца больш аптымізаваны пратакол з лепшай прадукцыйнасцю і меншай колькасцю абыходных шляхоў, неабходных для вырашэння такіх праблем, як блакіроўка галоўнай лініі. Ён не вырашае ўсіх праблем зHTTP/1.1, але, тым не менш, гэта значнае паляпшэнне ў параўнанні з папярэднікам.
HTTP/3
Са з'яўленнем смартфонаў і мноства іншых партатыўных прылад з бесправадной сувяззю, агульная колькасць вэб трафіку і час затрымкі паміж кліентам і серверам у залежнасці ад адлегласці паміж імі і колькасці пасрэднікаў могуць істотна павялічыцца. HTTP/2, які працуе праз TCP са сваёй праблемай "head-of-line blocking" на транспартным узроўні, мог ствараць затрымкі ў запытах і адказах. Таксама HTTP/2 не меў строгага патрабавання да шыфравання даных, і заставаліся праблемы з бяспекай пры перахопе загалоўкаў запытаў і адказаў.
HTTP/3 - гэта сур'ёзная рэдакцыя стандарту, якая мяняе асноўны сеткавы пратакол транспартнага ўзроўню з пратаколу кіравання перадачай (TCP) на QUIC («хуткія інтэрнэт-злучэнні UDP»). Але семантыка засталася, што і папярэдніх версіях HTTP.
QUIC распрацаваны, каб забяспечыць значна меншую затрымку для злучэнняў HTTP. Як і HTTP/2, гэта мультыплексны пратакол, але HTTP/2 працуе праз адно TCP-злучэнне, таму выяўленне страты пакетаў і іх паўторная перадача на ўзроўні TCP можа блакаваць усе патокі. QUIC запускае некалькі патокаў праз UDP і рэалізуе выяўленне страты пакетаў і рэтрансляцыю незалежна для кожнага патоку, так што ў выпадку ўзнікнення памылкі блакуецца толькі паток з дадзенымі ў гэтым пакеце.
У чэрвені 2022 года быў апублікаваны пратакол HTTP/3 у якасці прапанаванага стандарту, пасля чаго пачалася праца па наданні RFC статусу чарнавога стандарту (Draft Standard), што фактычна азначае поўную стабілізацыю пратакола і ўлік усіх выказаных заўваг.
TLS (пратакол, які выкарыстоўваўся для шыфравання асобна) зараз с'яўляецца часткай QUIC, то бок убудаваны ў новы пратакол.

У цяперашні час падтрымка QUIC і HTTP/3.0 ужо рэалізаваная ва ўсіх папулярных web-браўзэрах.
Як і HTTP/2, ён не аб'яўляе састарэлымі папярэднія асноўныя версіі пратаколу. Зараз выкарыстанне HTTP/3 складае 25.8% ад ўсіх сайтаў.
Асноўныя асаблівасці QUIC:
- Забяспечанне бяспекі, аналагічнай
TLS. - Кантроль за цэласнасцю патоку, які прадухіляе страту пакетаў.
- Страта пакета ўплывае на дастаўку толькі злучанага з ім струменя і не спыняе дастаўку даных у іншых струменях.
- Выкарыстанне спецыяльных кодаў карэкцыі памылак на ўзроўні пакета мінімізуюць затрымкі з-за паўторнай перадачы страчаных пакетаў, калі патрабуецца паўторная перадача даных страчанага пакета.
- Адсутнасць праблем з блакіроўкай чаргі
TCP. - Прыкметны прырост прадукцыйнасці і прапускной здольнасці ў параўнанні з
TCP. - Падтрымка ідэнтыфікатара злучэння (
CID), які дазваляе скараціць час на ўстаноўку паўторнага злучэння для мабільных кліентаў.
Дадатковая інфармацыя:
Каментары
(Каб даслаць каментар залагуйцеся ў свой уліковы запіс)