HTTP2 Поширені запитання
Це найчастіші запитання щодо HTTP/2.
Загальні питання
Навіщо переглядати HTTP?
HTTP/1.1 добре служить Інтернету вже більше п'ятнадцяти років, але його вік починає показуватися.
Завантаження веб-сторінки вимагає більше ресурсів, ніж будь-коли раніше (див. Статистику розміру сторінки в архіві HTTP), а ефективне завантаження всіх цих ресурсів складно, оскільки HTTP практично дозволяє лише один невиконаний запит на TCP-з'єднання.
Раніше браузери використовували кілька TCP-з'єднань для видачі паралельних запитів. Однак цьому є межі; якщо використовується занадто багато з'єднань, це одночасно і контрпродуктивно (контроль перевантажень TCP ефективно заперечується, що призводить до подій перевантажень, що шкодить продуктивності та мережі), і це принципово несправедливо (оскільки браузери забирають більше, ніж їх частка мережевих ресурсів).
У той же час велика кількість запитів означає багато дубльованих даних “по дроту”.
Обидва ці фактори означають, що запити HTTP/1.1 пов’язані з багатьма накладними витратами; якщо надто багато запитів, це шкодить продуктивності.
Це призвело галузь до місця, де вважається найкращою практикою робити такі справи, як спрайт, дані: вбудовування, шардінг доменів та конкатенація. Ці хаки є ознаками основних проблем у самому протоколі та самі по собі викликають низку проблем при використанні.
Хто створив HTTP/2?
HTTP/2 була розроблена робочою групою HTTP IETF, яка підтримує протокол HTTP. Він складається з ряду розробників HTTP, користувачів, операторів мережі та експертів HTTP.
Зверніть увагу, що, хоча наш список розсилки розміщений на сайті W3C, це не зусилля W3C. Однак Тім Бернерс-Лі та W3C TAG в курсі прогресу робочої групи.
Велика кількість людей внесла свої зусилля, але найактивнішими учасниками є інженери "великих" проектів, таких як Firefox, Chrome, Twitter, стек HTTP від Microsoft, Curl та Akamai, а також ряд реалізаторів HTTP такими мовами, як Python, Ruby та NodeJS.
Щоб дізнатись більше про участь у IETF, див. Дао IETF; Ви також можете зрозуміти, хто робить внесок у специфікацію на графіку співробітників Github, а хто реалізує в нашому списку реалізації.
Які стосунки з SPDY?
HTTP/2 вперше було обговорено, коли стало очевидним, що SPDY набирає популярності з реалізаторами (такими як Mozilla та nginx) і демонструє значні покращення порівняно з HTTP/1.x.
Після конкурсу пропозицій та процесу відбору, SPDY/2 був обраний основою для HTTP/2. З тих пір відбувся ряд змін, заснованих на обговоренні в Робочій групі та відгуках виконавців.
Протягом усього процесу основні розробники SPDY брали участь у розробці HTTP/2, включаючи як Майка Белше, так і Роберто Пеона.
У лютому 2015 року Google оголосив про плани скасувати підтримку SPDY на користь HTTP/2.
Це HTTP/2.0 або HTTP/2?
Робоча група вирішила залишити незначну версію (".0"), оскільки це спричинило багато плутанини в HTTP/1.x.
Іншими словами, версія HTTP вказує лише сумісність проводів, а не набори функцій або “маркетинг”.
Які ключові відмінності від HTTP/1.x?
На високому рівні HTTP/2:
- є двійковим, а не текстовим
- є повністю мультиплексованим, замість упорядкованого та блокуючого
- тому може використовувати один зв’язок для паралелізму
- використовує стиснення заголовка для зменшення накладних витрат
- дозволяє серверам активно "штовхати" відповіді в кешах клієнта
Чому HTTP/2 є двійковим?
Бінарні протоколи ефективніше аналізувати, більш компактні "по дроту", і головне, вони набагато менше схильні до помилок, порівняно з текстовими протоколами, такими як HTTP/1.x, оскільки вони часто мають ряд можливостей "допомогти" ”З такими речами, як обробка пробілів, використання великих літер, закінчення рядків, порожні рядки тощо.
Наприклад, HTTP/1.1 визначає чотири різні способи синтаксичного аналізу повідомлення; у HTTP/2 існує лише один шлях до коду.
Це правда, що HTTP/2 не використовується через telnet, але ми вже маємо певну підтримку інструментів, наприклад, плагін Wireshark.
Чому мультиплексується HTTP/2?
HTTP/1.x має проблему під назвою "блокування голови рядка", де фактично лише один запит може бути виконаний для з'єднання одночасно.
HTTP/1.1 намагався виправити це за допомогою конвеєризації, але це не повністю вирішило проблему (велика або повільна реакція все одно може заблокувати інших, що стоять позаду). Крім того, конвеєризм виявилося дуже важким для розгортання, оскільки багато посередників та серверів не обробляють його належним чином.
Це змушує клієнтів використовувати низку евристичних методів (часто вгадуючи), щоб визначити, які запити ставити, яке зв’язок із початком початку; оскільки загальноприйнята ситуація, коли сторінка завантажується в 10 разів (або більше) від кількості доступних з’єднань, це може суттєво вплинути на продуктивність, що часто призводить до «водоспаду» заблокованих запитів.
Мультиплексування вирішує ці проблеми, дозволяючи одночасно виконувати декілька повідомлень запитів та відповідей; можливо навіть змішувати частини одного повідомлення з іншим на дроті.
Це, в свою чергу, дозволяє клієнту використовувати лише одне підключення для кожного джерела для завантаження сторінки.
Чому лише одне TCP-з'єднання?
За допомогою HTTP/1 браузери відкривають від чотирьох до восьми з'єднань на кожне джерело. Оскільки багато сайтів використовують кілька джерел, це може означати, що завантаження однієї сторінки відкриває більше тридцяти з'єднань.
Один додаток, що відкриває стільки підключень, одночасно порушує багато припущень, на яких побудовано TCP; оскільки кожне підключення спричинить потік даних у відповіді, існує реальний ризик переповнення буферів у проміжній мережі, що спричинить перевантаження та повторно передасть.
Окрім того, використання такої кількості з’єднань несправедливо монополізує мережеві ресурси, «викрадаючи» їх у інших додатків, що працюють краще (наприклад, VoIP).
У чому перевага Server Push?
Коли браузер запитує сторінку, сервер надсилає HTML у відповідь, а потім потрібно дочекатися, поки браузер проаналізує HTML і видасть запити для всіх вбудованих активів, перш ніж почне надсилати JavaScript, зображення та CSS.
Server Push потенційно дозволяє серверу уникнути цього зворотного затримки, "штовхаючи" відповіді, які, на його думку, потрібні клієнту, у свій кеш.
Однак натискання відповідей не є “магічним” - якщо неправильно використовувати, це може зашкодити продуктивності. Правильне використання Server Push є постійною сферою експериментів та досліджень.
Навіщо нам стиснення заголовка?
Патрік Макманус з Mozilla яскраво продемонстрував це, розрахувавши ефект заголовків для середнього завантаження сторінки.
Якщо ви припускаєте, що сторінка має близько 80 ресурсів (що є консервативним у сучасній мережі Інтернет), і кожен запит має 1400 байт заголовків (знову ж таки, не рідкість, завдяки Cookies, Referer тощо), це займе принаймні 7-8 кругові поїздки, щоб витягнути заголовки "на дроті". Це не враховуючи час відповіді - це просто для того, щоб витягнути їх із клієнта.