HTTP — протокол передачі даних, що використовується в комп'ютерних мережах. Назва скорочена від HyperText Transfer Protocol, протокол передачі гіпертекстових документів
HTTP належить до протоколів моделі OSI 7-го прикладного рівня.
Основним призначенням протоколу HTTP є передача вебсторінок (текстових файлів з розміткою HTML, зображеннь та застосунків), проте за його допомогою успішно передаються й інші файли (в цьому плані HTTP складає конкуренцію складнішому FTP).
HTTP припускає, що клієнтська програма — веббраузер — здатна відображати гіпертекстові вебсторінки та файли інших типів у зручній для користувача формі. Для правильного відображення HTTP дозволяє клієнтові дізнатися мову та кодування символів вебсторінки, запитати версію сторінки з потрібною мовою чи в потрібному кодуванні, використовуючи позначення зі стандарту MIME.
Якщо в URL зі схемою http:// не вказаний порт, то за замовчуванням береться 80, (для схеми https — 443).
Структура протоколу
HTTP — протокол прикладного рівня, схожими на нього є FTP та SMTP. Обмін повідомленнями йде за звичайною схемою «запит-відповідь». Для ідентифікації ресурсів HTTP використовує глобальні URI. На відміну від багатьох інших протоколів, HTTP не зберігає свого стану. Це означає відсутність збереження проміжного стану між парами «запит-відповідь». Компоненти, що використовують HTTP, можуть самостійно здійснювати збереження інформації про стан, пов'язаний з останніми запитами та відповідями. Браузер, котрий посилає запити, може відстежувати затримки відповідей. Сервер може зберігати IP-адреси та заголовки запитів останніх клієнтів. Проте, згідно з протоколом, клієнт та сервер не мають бути обізнаними з попередніми запитами та відповідями, у протоколі не передбачена внутрішня підтримка стану й він не ставить таких вимог до клієнта та сервера.
Кожен запит/відповідь складається з трьох частин:
- стартовий рядок;
- заголовки;
- тіло повідомлення, що містить дані запиту, запитаний ресурс або опис проблеми, якщо запит не виконано.
Обов'язковим мінімумом запиту є стартовий рядок. Починаючи з HTTP/1.1 обов'язковим став заголовок Host: (щоб розрізнити кілька доменів, які мають одну й ту ж IP-адресу).
Запит
Стартові рядки розрізняються для запиту й відповіді. Рядок запиту виглядає так:
‹Метод› ‹URI› HTTP/‹Версія›
де ‹Метод› можливо:
- OPTIONS
- Повертає методи HTTP, які підтримуються сервером. Цей метод може служити для визначення можливостей вебсервера.
- GET
- Запитує вміст вказаного ресурсу. Запитаний ресурс може приймати параметри (наприклад, пошукова система може приймати як параметр шуканий рядок). Вони передаються в рядку URI (наприклад: http://www.example.net/resource?param1=value1¶m2=value2[недоступне посилання]). Згідно зі стандартом HTTP, запити типу GET вважаються ідемпотентними — багаторазове повторення одного і того ж запиту GET повинне приводити до однакових результатів (за умови, що сам ресурс не змінився за час між запитами). Це дозволяє кешувати відповіді на запити GET. Якщо назва ресурсу не вказана (у URI наявні лише схема та доменне ім'я), то вебсервер повертає індекс директорії вебсервера.
- HEAD
- Аналогічний методу GET, за винятком того, що у відповіді сервера відсутнє тіло. Це корисно для витягання метаінформації, заданої в заголовках відповіді, без пересилання всього вмісту. Зокрема, клієнт чи проксі, перевіривши заголовок Last-Modified: (останній час модифікації), таким чином може переконатися, що сторінка на сервері не змінилася від часу попереднього запиту.
- POST
- Передає призначені для користувача дані (наприклад, з HTML-форми) заданому ресурсу. Наприклад, в блогах відвідувачі зазвичай можуть вводити свої коментарі до записів в HTML-форму, після чого вони передаються серверу методом POST, і він поміщає їх на сторінку. При цьому передані дані (у прикладі з блогами — текст коментаря) включаються в . На відміну від методу GET, метод POST не вважається ідемпотентним, тобто багаторазове повторення одних і тих же запитів POST може повертати різні результати (наприклад, після кожного відправлення коментаря з'являтиметься одна копія цього коментаря).
- PUT
- Завантажує вказаний ресурс на сервер.
- PATCH
- Завантажує певну частину ресурсу на сервер.
- DELETE
- Видаляє вказаний ресурс.
- TRACE
- Повертає отриманий запит так, що клієнт може побачити, що проміжні сервери додають або змінюють в запиті.
- CONNECT
- Для використання разом з проксі-серверами, які можуть динамічно перемикатися в тунельний режим SSL.
Переважно використовуються методи GET і POST.
Відповідь сервера
Перший рядок відповіді має такий вигляд:
HTTP/‹Версія› ‹Код статусу› ‹Опис статусу›
Коди статусу:
- 1хх — інформаційний: запит прийнятий, продовжуй процес.
- 2хх — успіх: дія була успішно передана, зрозуміла, та прийнята.
- 3хх — перенаправлення: наступні дії мають бути успішно виконані для реалізації запиту.
- 4хх — помилка клієнта: запит містить синтаксичні помилки або не може бути виконаний.
- 5хх — помилка сервера: сервер не зміг виконати правильно сформований запит.
Найбільш поширені статуси:
- 200 OK — запит виконано успішно.
- 301 Moved Permanently — ресурс переміщено.
- 403 Forbidden — доступ до запитаного ресурсу заборонений.
- 404 Not Found — ресурс не знайдений.
- 503 Service Unavailable — сервіс недоступний.
Заголовки
Заголовки HTTP — це рядки, кожен з яких складається з імені параметра, за яким слідує двокрапка і його значення. Вони несуть інформацію для браузера або для серверних програм (таких, як CGI-застосунки). Між заголовками і тілом обов'язково повинен бути порожній рядок.
Приклад HTTP діалогу
Запит
GET /wiki/HTTP HTTP/1.1 Host: uk.wikipedia.org User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 Connection: close
Відповідь
HTTP/1.1 200 OK Server: Apache Content-Language: uk Content-Type: text/html; charset=utf-8 Content-Length: 1234 (пустий рядок) (далі йде текст html-сторінки)
Важливо: HTTP-заголовок відокремлюється від повідомлення пустою стрічкою (послідовністю CRLF CRLF
). Довжина повідомлення в байтах вказується в параметрі Content-Length
.
В першій стрічці відповіді вказується протокол, код відповіді.
Кешування
Цікавою особливістю мережевих програм є те, що найкраща швидкість роботи досягається, якщо не використовувати мережу. Тому її використання намагаються уникнути запам'ятовуванням попередніх запитів (вебкешуванням), зменшенням частоти запитів або взагалі відсутністю необхідності деяких запитів за допомогою переміщення обробника даних ближче до даних, які він обробляє (див. [en]).
Цей розділ потребує доповнення. (січень 2017) |
HTTP/2
У лютому 2015 комітет IETF (Internet Engineering Task Force), що займається розвитком протоколів і архітектури Інтернет, надав специфікації HTTP/2.0 статус «пропозиції стандарту», а також приступив до формування окремих RFC для протоколу HTTP/2.0 і формату стиснення заголовків HPACK.
Основним завданням створення HTTP/2.0 є підвищення ефективності використання мережевих ресурсів і зниження затримок при з'єднанні і обміні даними між клієнтом і сервером в сучасних умовах, при яких для завантаження сайту потрібно відправити низку окремих запитів (у середньому приблизно 100), пов'язаних з отриманням CSS, файлів JavaScript і картинок. Протокол HTTP/1.1, в силу блокувань при конвеєрній передачі даних і високих накладних витрат на віддачу ресурсів невеликого розміру, не може забезпечити належну ефективність і змушує встановлювати кілька одночасних TCP-з'єднань до сервера. В основу HTTP/2.0 покладений протокол SPDY, розроблений компанією Google — він дозволяє прискорити завантаження сайтів на 15-50 %.
Основні особливості (PDF) HTTP/2.0:
- Застосування бінарного протоколу, що оперує передачею бінарних кадрів. Кожен кадр має заголовок з інформацією про тип, розмір, опції та ідентифікаторі потоку. Кадри з типом DATA використовуються для передачі даних, HEADERS — HTTP-заголовків, RST_STREAM — для дострокового переривання відправлення даних;
- Мультиплексування і розпаралелювання потоків в рамках одного TCP-з'єднання. Пакети різних потоків змішуються і, на відміну від конвеєрної передачі HTTP/1.1, не очікують закінчення відправлення запиту. Підтримка ефективної двобічної передачі даних. Можливість мультиплексування при зверненні до різних хостів, що дозволяє додатково прискорити одночасне завантаження вебконтенту з різних сайтів (у SPDY мультиплексування підтримується тільки для одного хоста);
- Можливість встановлення пріоритетів і залежностей для потоків, що дозволяє виділити найважливіші потоки, які потрібно виконати в першу чергу, а також визначити залежність одного потоку від іншого;
- Стиснення HTTP-заголовків. У тому числі підтримується усунення дублікатів заголовків і Cookie, повторюваних для серії запитів до одного сайту. Допускається визначення окремих заголовків що не підлягають стисненню;
- Низька чутливість до затримок;
- Засоби для узгодження протоколу між клієнтом і сервером, що дозволяють вибрати HTTP/1.1, HTTP/2.0 і інші протоколи: сервер надає список підтримуваних протоколів, які може вибрати клієнт. Для шифрованих з'єднань параметри TLS узгоджуються за допомогою протоколу ALPN, при якому клієнт повідомляє список підтримуваних опцій, а сервер вибирає найоптимальніший для себе варіант;
- Забезпечення високого рівня сумісності з HTTP/1.1: збережені заголовки, схема URI, коди стану і методи (GET, POST тощо). Забезпечена можливість створення проксі для доступу клієнтів HTTP/1.1 до серверів HTTP/2.0;
- Можливість встановлення шифрованих (HTTPS) і не шифрованих з'єднань (HTTP). Шифрування здійснюється з використанням TLS 1.3 або новішої версії. Незважаючи на те, що специфікація дозволяє створення нешифрованих сполучень, розробники Firefox і Google Chrome мають намір забезпечити роботу HTTP/2.0 тільки поверх TLS;
- Підтримка технології Server push для передачі даних від сервера до клієнта (наприклад, коли сервер вважає, що після певного запиту обов'язково будуть затребувані інші дані, він може відправити ці дані не чекаючи фактичного запиту);
- Підтримка HTTP/2.0 на час пропозиції стандарту вже реалізована в браузерах
Google Chrome і Firefox, вони вже багато років підтримують цю технологію, і Apple додала підтримку в браузер Safari в 2014 році. В Internet Explorer 11 підтримка реалізована лише для Windows 10.
Великі мобільні браузери, в тому числі Android-браузер, Chrome для Android і iOS, а також Safari в iOS 8 і вище підтримують HTTP/2 для мобільного доступу до Інтернету.
Див. також
Примітки
- RFC 2616 Стандарт HTTP/1.1
- RFC 2818 HTTP Over TLS
- Fielding Roy. Architectural Styles and the Design of Network-based Software Architectures. — Каліфорнійський університет в Ірвайні, 2000. — 30 June. з джерела 19 лютого 2009. Процитовано 2009-02-20.
- . Архів оригіналу за 19 квітня 2015. Процитовано 1 травня 2015.
- . IEBlog. Архів оригіналу за 19 липня 2020. Процитовано 24 квітня 2018.
- Lardinois, Frederic (26 червня 2013). . TechCrunch. AOL. Архів оригіналу за 7 жовтня 2013. Процитовано 10 вересня 2013.
- Foley, Mary Jo (7 листопада 2013), , архів оригіналу за 22 листопада 2014, процитовано 7 листопада 2013
Ця стаття потребує додаткових для поліпшення її . (серпень 2019) |
Це незавершена стаття про Інтернет. Ви можете проєкту, виправивши або дописавши її. |
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
HTTP protokol peredachi danih sho vikoristovuyetsya v komp yuternih merezhah Nazva skorochena vid HyperText Transfer Protocol protokol peredachi gipertekstovih dokumentiv HTTP nalezhit do protokoliv modeli OSI 7 go prikladnogo rivnya Osnovnim priznachennyam protokolu HTTP ye peredacha vebstorinok tekstovih fajliv z rozmitkoyu HTML zobrazhenn ta zastosunkiv prote za jogo dopomogoyu uspishno peredayutsya j inshi fajli v comu plani HTTP skladaye konkurenciyu skladnishomu FTP HTTP pripuskaye sho kliyentska programa vebbrauzer zdatna vidobrazhati gipertekstovi vebstorinki ta fajli inshih tipiv u zruchnij dlya koristuvacha formi Dlya pravilnogo vidobrazhennya HTTP dozvolyaye kliyentovi diznatisya movu ta koduvannya simvoliv vebstorinki zapitati versiyu storinki z potribnoyu movoyu chi v potribnomu koduvanni vikoristovuyuchi poznachennya zi standartu MIME Yaksho v URL zi shemoyu http ne vkazanij port to za zamovchuvannyam beretsya 80 dlya shemi https 443 Struktura protokoluHTTP protokol prikladnogo rivnya shozhimi na nogo ye FTP ta SMTP Obmin povidomlennyami jde za zvichajnoyu shemoyu zapit vidpovid Dlya identifikaciyi resursiv HTTP vikoristovuye globalni URI Na vidminu vid bagatoh inshih protokoliv HTTP ne zberigaye svogo stanu Ce oznachaye vidsutnist zberezhennya promizhnogo stanu mizh parami zapit vidpovid Komponenti sho vikoristovuyut HTTP mozhut samostijno zdijsnyuvati zberezhennya informaciyi pro stan pov yazanij z ostannimi zapitami ta vidpovidyami Brauzer kotrij posilaye zapiti mozhe vidstezhuvati zatrimki vidpovidej Server mozhe zberigati IP adresi ta zagolovki zapitiv ostannih kliyentiv Prote zgidno z protokolom kliyent ta server ne mayut buti obiznanimi z poperednimi zapitami ta vidpovidyami u protokoli ne peredbachena vnutrishnya pidtrimka stanu j vin ne stavit takih vimog do kliyenta ta servera Kozhen zapit vidpovid skladayetsya z troh chastin startovij ryadok zagolovki tilo povidomlennya sho mistit dani zapitu zapitanij resurs abo opis problemi yaksho zapit ne vikonano Obov yazkovim minimumom zapitu ye startovij ryadok Pochinayuchi z HTTP 1 1 obov yazkovim stav zagolovok Host shob rozrizniti kilka domeniv yaki mayut odnu j tu zh IP adresu Zapit Startovi ryadki rozriznyayutsya dlya zapitu j vidpovidi Ryadok zapitu viglyadaye tak Metod URI HTTP Versiya de Metod mozhlivo OPTIONS Povertaye metodi HTTP yaki pidtrimuyutsya serverom Cej metod mozhe sluzhiti dlya viznachennya mozhlivostej vebservera GET Zapituye vmist vkazanogo resursu Zapitanij resurs mozhe prijmati parametri napriklad poshukova sistema mozhe prijmati yak parametr shukanij ryadok Voni peredayutsya v ryadku URI napriklad http www example net resource param1 value1 amp param2 value2 nedostupne posilannya Zgidno zi standartom HTTP zapiti tipu GET vvazhayutsya idempotentnimi bagatorazove povtorennya odnogo i togo zh zapitu GET povinne privoditi do odnakovih rezultativ za umovi sho sam resurs ne zminivsya za chas mizh zapitami Ce dozvolyaye keshuvati vidpovidi na zapiti GET Yaksho nazva resursu ne vkazana u URI nayavni lishe shema ta domenne im ya to vebserver povertaye indeks direktoriyi vebservera HEAD Analogichnij metodu GET za vinyatkom togo sho u vidpovidi servera vidsutnye tilo Ce korisno dlya vityagannya metainformaciyi zadanoyi v zagolovkah vidpovidi bez peresilannya vsogo vmistu Zokrema kliyent chi proksi perevirivshi zagolovok Last Modified ostannij chas modifikaciyi takim chinom mozhe perekonatisya sho storinka na serveri ne zminilasya vid chasu poperednogo zapitu POST Peredaye priznacheni dlya koristuvacha dani napriklad z HTML formi zadanomu resursu Napriklad v blogah vidviduvachi zazvichaj mozhut vvoditi svoyi komentari do zapisiv v HTML formu pislya chogo voni peredayutsya serveru metodom POST i vin pomishaye yih na storinku Pri comu peredani dani u prikladi z blogami tekst komentarya vklyuchayutsya v Na vidminu vid metodu GET metod POST ne vvazhayetsya idempotentnim tobto bagatorazove povtorennya odnih i tih zhe zapitiv POST mozhe povertati rizni rezultati napriklad pislya kozhnogo vidpravlennya komentarya z yavlyatimetsya odna kopiya cogo komentarya PUT Zavantazhuye vkazanij resurs na server PATCH Zavantazhuye pevnu chastinu resursu na server DELETE Vidalyaye vkazanij resurs TRACE Povertaye otrimanij zapit tak sho kliyent mozhe pobachiti sho promizhni serveri dodayut abo zminyuyut v zapiti CONNECT Dlya vikoristannya razom z proksi serverami yaki mozhut dinamichno peremikatisya v tunelnij rezhim SSL Perevazhno vikoristovuyutsya metodi GET i POST Vidpovid servera Pershij ryadok vidpovidi maye takij viglyad HTTP Versiya Kod statusu Opis statusu Kodi statusu 1hh informacijnij zapit prijnyatij prodovzhuj proces 2hh uspih diya bula uspishno peredana zrozumila ta prijnyata 3hh perenapravlennya nastupni diyi mayut buti uspishno vikonani dlya realizaciyi zapitu 4hh pomilka kliyenta zapit mistit sintaksichni pomilki abo ne mozhe buti vikonanij 5hh pomilka servera server ne zmig vikonati pravilno sformovanij zapit Najbilsh poshireni statusi 200 OK zapit vikonano uspishno 301 Moved Permanently resurs peremisheno 403 Forbidden dostup do zapitanogo resursu zaboronenij 404 Not Found resurs ne znajdenij 503 Service Unavailable servis nedostupnij Zagolovki Zagolovki HTTP ce ryadki kozhen z yakih skladayetsya z imeni parametra za yakim sliduye dvokrapka i jogo znachennya Voni nesut informaciyu dlya brauzera abo dlya servernih program takih yak CGI zastosunki Mizh zagolovkami i tilom obov yazkovo povinen buti porozhnij ryadok Priklad HTTP dialoguZapit GET wiki HTTP HTTP 1 1 Host uk wikipedia org User Agent firefox 5 0 Linux Debian 5 0 8 en US rv 1 8 1 7 Gecko 20070914 Firefox 2 0 0 7 Connection close Vidpovid HTTP 1 1 200 OK Server Apache Content Language uk Content Type text html charset utf 8 Content Length 1234 pustij ryadok dali jde tekst html storinki Vazhlivo HTTP zagolovok vidokremlyuyetsya vid povidomlennya pustoyu strichkoyu poslidovnistyu CRLF CRLF Dovzhina povidomlennya v bajtah vkazuyetsya v parametri Content Length V pershij strichci vidpovidi vkazuyetsya protokol kod vidpovidi KeshuvannyaCikavoyu osoblivistyu merezhevih program ye te sho najkrasha shvidkist roboti dosyagayetsya yaksho ne vikoristovuvati merezhu Tomu yiyi vikoristannya namagayutsya uniknuti zapam yatovuvannyam poperednih zapitiv vebkeshuvannyam zmenshennyam chastoti zapitiv abo vzagali vidsutnistyu neobhidnosti deyakih zapitiv za dopomogoyu peremishennya obrobnika danih blizhche do danih yaki vin obroblyaye div en Cej rozdil potrebuye dopovnennya sichen 2017 HTTP 2U lyutomu 2015 komitet IETF Internet Engineering Task Force sho zajmayetsya rozvitkom protokoliv i arhitekturi Internet nadav specifikaciyi HTTP 2 0 status propoziciyi standartu a takozh pristupiv do formuvannya okremih RFC dlya protokolu HTTP 2 0 i formatu stisnennya zagolovkiv HPACK Osnovnim zavdannyam stvorennya HTTP 2 0 ye pidvishennya efektivnosti vikoristannya merezhevih resursiv i znizhennya zatrimok pri z yednanni i obmini danimi mizh kliyentom i serverom v suchasnih umovah pri yakih dlya zavantazhennya sajtu potribno vidpraviti nizku okremih zapitiv u serednomu priblizno 100 pov yazanih z otrimannyam CSS fajliv JavaScript i kartinok Protokol HTTP 1 1 v silu blokuvan pri konveyernij peredachi danih i visokih nakladnih vitrat na viddachu resursiv nevelikogo rozmiru ne mozhe zabezpechiti nalezhnu efektivnist i zmushuye vstanovlyuvati kilka odnochasnih TCP z yednan do servera V osnovu HTTP 2 0 pokladenij protokol SPDY rozroblenij kompaniyeyu Google vin dozvolyaye priskoriti zavantazhennya sajtiv na 15 50 Osnovni osoblivosti PDF HTTP 2 0 Zastosuvannya binarnogo protokolu sho operuye peredacheyu binarnih kadriv Kozhen kadr maye zagolovok z informaciyeyu pro tip rozmir opciyi ta identifikatori potoku Kadri z tipom DATA vikoristovuyutsya dlya peredachi danih HEADERS HTTP zagolovkiv RST STREAM dlya dostrokovogo pererivannya vidpravlennya danih Multipleksuvannya i rozparalelyuvannya potokiv v ramkah odnogo TCP z yednannya Paketi riznih potokiv zmishuyutsya i na vidminu vid konveyernoyi peredachi HTTP 1 1 ne ochikuyut zakinchennya vidpravlennya zapitu Pidtrimka efektivnoyi dvobichnoyi peredachi danih Mozhlivist multipleksuvannya pri zvernenni do riznih hostiv sho dozvolyaye dodatkovo priskoriti odnochasne zavantazhennya vebkontentu z riznih sajtiv u SPDY multipleksuvannya pidtrimuyetsya tilki dlya odnogo hosta Mozhlivist vstanovlennya prioritetiv i zalezhnostej dlya potokiv sho dozvolyaye vidiliti najvazhlivishi potoki yaki potribno vikonati v pershu chergu a takozh viznachiti zalezhnist odnogo potoku vid inshogo Stisnennya HTTP zagolovkiv U tomu chisli pidtrimuyetsya usunennya dublikativ zagolovkiv i Cookie povtoryuvanih dlya seriyi zapitiv do odnogo sajtu Dopuskayetsya viznachennya okremih zagolovkiv sho ne pidlyagayut stisnennyu Nizka chutlivist do zatrimok Zasobi dlya uzgodzhennya protokolu mizh kliyentom i serverom sho dozvolyayut vibrati HTTP 1 1 HTTP 2 0 i inshi protokoli server nadaye spisok pidtrimuvanih protokoliv yaki mozhe vibrati kliyent Dlya shifrovanih z yednan parametri TLS uzgodzhuyutsya za dopomogoyu protokolu ALPN pri yakomu kliyent povidomlyaye spisok pidtrimuvanih opcij a server vibiraye najoptimalnishij dlya sebe variant Zabezpechennya visokogo rivnya sumisnosti z HTTP 1 1 zberezheni zagolovki shema URI kodi stanu i metodi GET POST tosho Zabezpechena mozhlivist stvorennya proksi dlya dostupu kliyentiv HTTP 1 1 do serveriv HTTP 2 0 Mozhlivist vstanovlennya shifrovanih HTTPS i ne shifrovanih z yednan HTTP Shifruvannya zdijsnyuyetsya z vikoristannyam TLS 1 3 abo novishoyi versiyi Nezvazhayuchi na te sho specifikaciya dozvolyaye stvorennya neshifrovanih spoluchen rozrobniki Firefox i Google Chrome mayut namir zabezpechiti robotu HTTP 2 0 tilki poverh TLS Pidtrimka tehnologiyi Server push dlya peredachi danih vid servera do kliyenta napriklad koli server vvazhaye sho pislya pevnogo zapitu obov yazkovo budut zatrebuvani inshi dani vin mozhe vidpraviti ci dani ne chekayuchi faktichnogo zapitu Pidtrimka HTTP 2 0 na chas propoziciyi standartu vzhe realizovana v brauzerah Google Chrome i Firefox voni vzhe bagato rokiv pidtrimuyut cyu tehnologiyu i Apple dodala pidtrimku v brauzer Safari v 2014 roci V Internet Explorer 11 pidtrimka realizovana lishe dlya Windows 10 Veliki mobilni brauzeri v tomu chisli Android brauzer Chrome dlya Android i iOS a takozh Safari v iOS 8 i vishe pidtrimuyut HTTP 2 dlya mobilnogo dostupu do Internetu Div takozhHTTPS zahishenij shifruvannyam analog HTTP Veb FTP URLPrimitkiRFC 2616 Standart HTTP 1 1 RFC 2818 HTTP Over TLS Fielding Roy Architectural Styles and the Design of Network based Software Architectures Kalifornijskij universitet v Irvajni 2000 30 June z dzherela 19 lyutogo 2009 Procitovano 2009 02 20 Arhiv originalu za 19 kvitnya 2015 Procitovano 1 travnya 2015 IEBlog Arhiv originalu za 19 lipnya 2020 Procitovano 24 kvitnya 2018 Lardinois Frederic 26 chervnya 2013 TechCrunch AOL Arhiv originalu za 7 zhovtnya 2013 Procitovano 10 veresnya 2013 Foley Mary Jo 7 listopada 2013 arhiv originalu za 22 listopada 2014 procitovano 7 listopada 2013 Cya stattya potrebuye dodatkovih posilan na dzherela dlya polipshennya yiyi perevirnosti Bud laska dopomozhit udoskonaliti cyu stattyu dodavshi posilannya na nadijni avtoritetni dzherela Zvernitsya na storinku obgovorennya za poyasnennyami ta dopomozhit vipraviti nedoliki Material bez dzherel mozhe buti piddano sumnivu ta vilucheno serpen 2019 Ce nezavershena stattya pro Internet Vi mozhete dopomogti proyektu vipravivshi abo dopisavshi yiyi