• Переклад

Нещодавно вийшла Нова версіястандарту HTTP. У травні 2015 року було затверджено HTTP/2, який набув поширення серед браузерів та веб-серверів (включаючи NGINX та NGINX Plus). на Наразібільше 60% браузерів підтримують HTTP/2, причому ця цифра продовжує збільшуватися з кожним місяцем.

Стандарт HTTP/2 базується на протоколі SPDY, розробленому компанією Google. У Google Chromeпідтримка SPDY буде здійснюватися до початку 2016 року. NGINX одним із перших реалізував протокол SPDY і зараз грає провідну роль у просуванні HTTP/2. Була опублікована , в якій дано докладний опис HTTP/2, наводиться порівняння зі SPDY і докладно описується процес застосування нового протоколу.

Основні особливості HTTP/2 аналогічні SPDY:

• HTTP/2 бінарний, а не текстовий протокол, що робить його компактнішим та ефективнішим.
• У HTTP/2 використовується тільки одне мультиплексирующее з'єднання до хоста, замість безлічі з'єднань, що передають по одному файлу.
• У HTTP/2 використовується стиснення заголовків спеціалізованим протоколом HPACK (замість gzip, який використовувався SPDY).
• У HTTP/2 застосовується складний механізмпріоритезації, щоб віддавати браузерам найбільше необхідні файлинасамперед (у SPDY використовувався простіший алгоритм).

Тепер необхідно заглибитись та розглянути докладніше особливості нового протоколу. Ця стаття написана з метою допомогти прийняти рішення про перехід на HTTP/2, а також розглядає можливу оптимізацію при впровадженні протоколу.

1. Термінуйте HTTP/2
2. Почніть із використання SPDY
3. Відмовтеся від HTTP/1.x оптимізації
4. Введіть HTTP/2 або SPDY
5. Перегляньте HTTP/1.x оптимізації
6. Розгляньте дружній HTTP/2 шардинг

Примітка: строго кажучи, для використання SPDY та HTTP/2 не потрібно TLS, але основні переваги виявляються при включенні SSL/TLS, тому браузери підтримують SPDY та HTTP/2 лише за наявності SSL/TLS.

Оцініть необхідність використання HTTP/2

Впровадити HTTP/2 не складає і процес докладно описаний. Однак варто розуміти, що HTTP/2 не є універсальним рішеннямі для одних додатків може бути корисним, а для інших ні.

Наприклад, з великою ймовірністю, HTTP/2 прискорить сайт, який вже використовує SSL/TLS (далі використовується скорочення TLS), інакше перед включенням HTTP/2 необхідно включити TLS. Слід зауважити, що від використання TLS може статися падіння продуктивності, яке може звести нанівець прискорення від HTTP/2. Тому спершу варто перевірити цей випадок.

1. Використовується лише одне з'єднання з сервером замість безлічі з'єднань, що передають по одному файлу. Іншими словами, зменшується кількість сполук, що є особливо корисним при використанні TLS.
2. Ефективне використання TLS. HTTP/2 робить тільки один TLS хендшейк, а мультиплексування дозволяє ефективно використовувати це з'єднання. HTTP/2 також стискає дані заголовка, а усунення HTTP/1.x оптимізації (таких як конкатенація файлів) дозволяє алгоритму кешування працювати більш ефективно.
3. Спрощення веб-застосунків. При використанні HTTP/2 можна позбутися HTTP/1.x оптимізацій, які завдають позбавлення незручності та розробникам.
4. Відмінно підходить для складних веб-сторінок. HTTP/2 відмінно підходить для веб-сторінок, які одночасно використовують HTML, CSS, JavaScript, картинки та відеоролики. Браузери можуть пріоритезувати запити до файлів, щоб найнеобхідніші частини сторінки надсилалися в першу чергу.
5. Безпека з'єднання. Хоча при використанні HTTP/2 може статися втрата продуктивності через використання TLS, але в той же час TLS зробить веб-застосунки більш безпечними для користувачів.

І п'ять відповідних недоліків, з якими можна зіткнутися:

1. Великі витрати на одне з'єднання. Алгоритм стиснення даних HPACK вимагає підтримки таблиці перетворення обох кінцях. Також для одного з'єднання потрібно більше пам'яті.
2. Можливе використання TLS надмірно. Якщо інформація, що передаєтьсяне потребує захисту або вже захищена за допомогою DRM (або іншого шифрування), то в цьому випадку TLS навряд чи буде корисним.
3. Пошук та видалення існуючих HTTP/1.x оптимізації необхідні для збільшення продуктивності HTTP/2, що є додатковою роботою.
4. Не дає переваг при завантаженні великих файлів. Якщо веб-програма в основному розрахована на завантаження великих файлів або відеострімінг, то, швидше за все, використання TLS буде помилковим, а мультиплексування не принесе жодної користі.
5. Безпека не є важливою. Можливо, відвідувачам не важливо, що відео з котиками, якими вони діляться на вашому сайті, не захищене TLS і HTTP/2 (що може бути вірно).

Все зводиться до продуктивності і тут є гарні та погані новини.

Хороші новини в тому, що виходячи з тестів, які були проведені в NGINX, слідують результати передбачені з теорії: для складних веб-сторінок, запитаних з типовими затримками (latency), продуктивність HTTP/2 вище, ніж HTTP/1.x і HTTPS. Результати поділені на три групи залежно від типового round-trip time (RTT):

• Дуже низький RTTs (0-20 мс): ніякої різниці між HTTP/1.x, HTTP/2, і HTTPS не спостерігається.
• Середня (типова для інтернету) RTTs (30-250 мс): HTTP/2 швидше ніж HTTP/1.x, і обидва швидше ніж HTTPS. Для сусідніх міст у США RTT складає близько 30 мс, і близько 70 мс від одного берега до іншого (близько 3000 миль). За одним з найкоротших маршрутів між Токіо та Лондоном, RTT складає близько 240 мс.
• Висока RTTs (300 мс і вище): HTTP/1.x швидше ніж HTTP/2, який швидше за HTTPS.

На малюнку показано час до початку малювання - тобто час до моменту, коли користувача бачить перший вміст веб-сторінки. Цей час часто сприймається як визначальне значення для сприйняття користувачами чуйності веб-сайту.

Більш детально з процесом тестування та результатами можна ознайомитись у презентаціїіз конференції nginx.conf 2015.

Проте всі веб-сторінки та сеанси користувачів відрізняються один від одного. Наприклад, якщо у вас є стрімінг відео або великі файли, що завантажуються, то ваші результати можуть відрізнятися або навіть бути протилежними.

Суть у тому, що спочатку необхідно зрозуміти можливі витрати та найбільші вигодипід час використання HTTP/2. Після цього варто провести тестування продуктивності своїх програм, а потім зробити вибір.

Термінуйте HTTP/2

Термінування означає, що клієнт може підключатися до проксі-сервера через заданий протокол, наприклад HTTP/2, а далі проксі-сервер підключається до серверних програм, баз даних і т.д. користуючись зовсім іншим протоколом (див. нижче).

При використанні окремих серверівз'являється можливість перейти до мультисерверної архітектури. Сервера можуть розділятися фізично, віртуально або можна використовувати хмарне оточення, таке як AWS . Це ускладнює архітектуру, порівняно з односерверним рішенням або комбінацією сервер+база даних, але дає багато переваг і є необхідністю для високонавантажених сайтів.

Після того, як фізичний або віртуальний сервервстановлюється перед існуючою системою, стають доступними додаткові можливості. Новий серверрозвантажує інші сервери від обробки клієнтських повідомлень. Крім того, він може бути використаний для балансування навантаження, статичного кешування файлів та будь-яких інших цілей. Стає набагато простіше додавати та замінювати серверні програмита інші сервери в міру потреби.

NGINX і NGINX Plus часто використовуються для всіх цих цілей - термінування TLS та HTTP/2, балансування навантаження та багато іншого. Існуюче середовище не потребує жодних змін, за винятком частини взаємодії користувачів з сервером NGINX.

Почніть із використання SPDY

SPDY є попередником протоколу HTTP/2 та його продуктивність можна порівняти з HTTP/2. Оскільки SPDY існує вже протягом кількох років, все популярні браузерипідтримують його, на відміну від HTTP/2, який з'явився порівняно недавно. Тим не менш, на момент написання статті, розрив скорочується і понад 60% браузерів вже підтримують HTTP/2, тоді як SPDY підтримують понад 80%.

Якщо є потреба терміново реалізувати новий транспортний протокол, причому використовувати протокол з максимальною підтримкою серед користувачів, варто почати зі SPDY. Пізніше, на початку 2016 року, коли підтримка SPDY буде видалена, перейти на HTTP/2. До цього моменту вже більше користувачів буде використовувати браузери, які підтримують HTTP/2, тому такий перехід може бути оптимальним з точки зору більшості користувачів.

Відмовтеся від HTTP/1.x оптимізації

Перед використанням HTTP/2 необхідно виявити оптимізації для HTTP/1.x. Далі перераховано чотири типи оптимізації, на які варто звернути увагу:

1. Шардінг. Розміщення файлів різних доменах для паралельної передачі браузеру; мережі доставки контенту (CDNs) роблять це автоматично. Така оптимізація може зашкодити продуктивності HTTP/2. Ви можете використовувати дружній HTTP/2 шардинг для користувачів HTTP/1.x (див. дружній HTTP/2 шардинг).
2. Використання спрайтів. Спрайт називають колекції картинок, які передаються у вигляді одного файлу; після цього на стороні клієнта картинки за потребою витягуються з колекції. Ця оптимізація менш ефективна при використанні HTTP/2, хоча все одно може бути корисною.
3. Об'єднання файлів. Подібно до спрайтів, частина файлів, які зазвичай зберігаються окремо, об'єднуються в один. Після чого браузер знаходить і запускає код у міру необхідності в рамках склеєного файлу.
4. Вбудовування файлів. CSS, JavaScript і навіть зображення вставляються безпосередньо в HTML-файл, що зменшує кількість переданих файлів, рахунок збільшення вихідного HTML-файла.

Останні три типи оптимізації об'єднання маленьких файлів у більші, скорочення нових зв'язків та ініціалізації додаткових з'єднань, особливо важливі при використанні TLS.

Перша оптимізація, шардинг, працює інакше - вона змушує відкрити більше з'єднань, використовуючи додаткові домени. Водночас ці, здавалося б суперечливими, методи можуть бути досить ефективними у підвищенні продуктивності HTTP/1.x сайтів. Проте всі вони витрачають час, зусилля та ресурси для розробки, впровадження, управління та підтримки роботи.

Перед впровадженням HTTP/2, слід знайти ці оптимізації та з'ясувати, як вони в даний час впливають на дизайн програми та робочий процес. Це слід зробити, щоб була можливість змінити або скасувати оптимізацію після переїзду на HTTP/2.

Введіть HTTP/2 або SPDY

Насправді перехід на HTTP/2 чи SPDY досить простий. Для користувачів NGINX необхідно просто «включити» протокол у конфігурації NGINX, як описано на прикладі HTTP/2. Після цього, сервер повідомлятиме браузер клієнта про можливість використання HTTP/2 або SPDY.

Після увімкнення HTTP/2 на сервері користувачі, браузери яких підтримують HTTP/2, будуть підключатися та працювати з веб-додатками через HTTP/2. Людям зі старими версіями браузерів доведеться працювати через HTTP/1.x (див. малюнок нижче). При впровадженні HTTP/2 або SPDY на високонавантажені сайти слід виміряти продуктивність до і після і відкотити зміни у разі прояву негативних наслідків.

Примітка: Оскільки при увімкненні HTTP/2 використовується одне з'єднання, деякі налаштування конфігурації в NGINX стають більш важливими. Рекомендується переглянути конфігурацію NGINXз особливою увагоюдо налаштування та тестування параметрів таких директив, як output_buffers, proxy_buffers та ssl_buffer_size. Слід звернути увагу на , конкретні поради щодо TLS ( і ), і про продуктивність NGINX при використанні TLS.

Примітка: При використанні шифрів разом з HTTP/2 слід звернути увагу на наступне: RFC для HTTP/2 має довгий список шифрів, яких слід уникати. Якщо у вас є бажання налаштувати список шифрів самостійно, то в такому випадку рекомендується розглянути налаштування ssl_ciphers та включення ssl_prefer_server_ciphers on , після чого протестувати відповідні шифри з усіма популярними версіями браузерів. Індикатор для популярних браузерів Qualys' SSL Server test (листопад 2015) вважається ненадійним для підрахунку HTTP/2 хендшейків .

Як це не дивно, але видалення або зміна HTTP/1.x оптимізації є найбільш творчою частиною впровадження HTTP/2. Є кілька питань, які потрібно розглянути.

Перш ніж вносити зміни, слід враховувати користувачів старих браузерів, які можуть постраждати. Маючи це на увазі, є три основні стратегії для скасування або перегляду оптимізації HTTP/1.x:

• Все вже готово. Якщо програми не були оптимізовані під HTTP/1.x або були зроблені незначні зміни, все готово, щоб використовувати HTTP/2.
• Змішаний підхід. Можна зменшити конкатенацію даних, але не повністю усунути. Наприклад, деякі спрайти зображень можуть залишитися, в той же час позбавитися даних, вбудованих в HTML.
• Повна відмова від HTTP/1.x оптимізації (але див. дружній HTTP/2 шардинг та примітки). Можна просто повністю позбутися оптимізації.

Кешування має деякі особливості. Теоретично кешування працює ефективно у разі, коли застосовується до безлічі невеликих файлів. Проте, у разі виконується велика кількість операцій I/O. Тому об'єднання пов'язаних між собою файлів може бути корисним як для робочого процесу, так і для продуктивності додатків. Шардинг є, мабуть, найпростішим, і водночас, можливо, найуспішнішою стратегією оптимізації HTTP/1.x. Шардинг можна використовувати для підвищення продуктивності HTTP/1.x, але для HTTP/2 (у якому використовується лише одне з'єднання) він здебільшого ігнорується.

Для використання шардингу в парі з HTTP/2 слід зробити дві речі:

• Зробити так, щоб доменні іменадля шардингових ресурсів резолвувалися в однакові IP-адреси.
• Переконатися у тому, що використовується wildcard-сертифікат - у разі він буде валідним всім доменних імен, використовуваних при шардингу. Або переконатися, чи є в наявності відповідного мультидоменного сертифіката.

Детальну інформацію можна знайти.

При виконанні цих умов шардинг відбуватиметься для HTTP/1.x - оскільки домени відрізняються, що дозволяє браузерам створювати додаткові набориз'єднань - і не відбуватиметься для HTTP/2, так як окремі домени розглядаються як один, і з'єднання може отримати доступ до будь-якого з них.

Висновок

Швидше за все HTTP/2 з TLS допоможе збільшити продуктивність вашого сайту та дозволить користувачам бути впевненими, що їхнє з'єднання захищене. Причому впровадження підтримки HTTP/2, швидше за все, не вимагатиме великої кількостізусиль.

Поради, описані вище, повинні допомогти досягти найкращої продуктивності HTTP/2 з найменшими зусиллями так, щоб решту часу присвятити створенню швидких, ефективних та безпечних програм.

Теги: Додати теги

Торік у світі мережевих технологійвідбулася дуже важлива подія: було затверджено та стандартизовано нову версію протоколу HTTP — HTTP/2. HTTP/2 вже підтримується в популярних веб-серверах: Apache та Nginx. Йде робота з впровадження HTTP/2 у IIS. Реалізовано підтримку і в більшості сучасних браузерів.

Використання HTTP/2 за Останнім часомзначно розширилося.

За даними на середину 2015 року, відсоток сайтів та веб-сервісів, що перейшли на HTTP/2, був невеликий – лише 0,4%. Зовсім свіжа статистика (січень 2016 р.) свідчить про значне зростання: з 0,4 до 6,5%. Є всі підстави вважати, що найближчим часом темпи зростання збільшуватимуться.

Замислитися про практичні аспектипереходу на HTTP/2 стоїть вже зараз. Цю тему ми хотіли б торкнутися в сьогоднішній статті. Особливо нас цікавитиме проблема адаптації існуючих прийомівоптимізувати продуктивність веб-сайтів під специфіку нового протоколу.
Перш ніж перейти безпосередньо до розгляду цього питання, звернемося до історії протоколу HTTP/2 та коротко опишемо основні нововведення, що відрізняють його від HTTP/1.1.

Від HTTP до HTTP/2

Трохи історії

Перший опис протоколу HTTP (HyperText Transfer Protocol) було опубліковано у 1991 році. У 1999 році була розроблена та описана версія HTTP 1.1, яка використовується і досі. У те далекий час(Майже 20 років тому) веб-сайти були зовсім не такими, як зараз. За відносно невеликий періодчасу сайти стали "важити" набагато більше. Домашня сторінкасередньостатичного сучасного сайту містить приблизно 1,9 МБ даних: зображення, JS, CSS та багато іншого.

Через обмеження на кількість одночасних підключень до HTTP/1.1 завантаження сторінок, що містять велику кількість «важкого» контенту, здійснюється повільно. Можна виділити два шляхи вирішення цієї проблеми. Перший полягає у використанні різних технік оптимізації продуктивності (про деякі з них ми вже писали), а другий у спробі модифікації самого протоколу HTTP з метою усунення можливих вузьких місць. Розглянемо такі спроби докладніше.

Перший масштабний проект реформування HTTP було представлено у 2009 році інженерами Google. Це протокол SPDY, метою якого в першу чергу було прискорення роботи веб-сайтів та додатків шляхом модифікації традиційних способівприйому та відправлення запитів.

SPDY вимагає підтримки як за сервера, і за клієнта. Розробники Googleстворили спеціалізовані модулі для Apache (mod_spdy) та Nginx (ngx_http_spdy_module). Підтримується він практично у всіх популярних браузерах.

HTTP/2, представлений шістьма роками пізніше, багато в чому ґрунтується на SPDY. Нова версія HTTP була створена робочою групою Hypertext Transfer Protocol working group. У травні 2015 року специфікація HTTP/2 була опублікована як RFC 7540.

Протокол HTTP/2 назад сумісний із HTTP/1.1. Зміни, спрямовані на усунення вузьких місць та підвищення продуктивності, продовжують лінію SPDY. Розглянемо коротко найважливіші з них.

HTTP/2: основні нововведення

Мультиплексування

Можливо, це найголовніша перевага HTTP/2. У HTTP/1.1 для кожного запиту потрібно встановлювати окреме з'єднання TCP. Мультиплексування дозволяє браузеру виконувати безліч запитів в рамках одного TCP-з'єднання:

У сучасних браузерах кількість одночасних TCP-з'єднань обмежена. Тому сторінки з великою кількістюстатичного контенту завантажуються не так швидко, як хотілося б.

У HTTP/2 завдяки мультиплексуванню статичні елементизавантажуються паралельно, і завдяки цьому суттєво покращується продуктивність.

Пріоритети

Ще одне нововведення HTTP/2 – це пріоритизація. Кожному запиту можна визначити пріоритет.
Існує два підходи до призначення пріоритетів: на основі ваги та на основі залежностей.

У першому підході кожен потік отримує певну вагу. Потім з урахуванням ваги сервер розподіляє навантаження між потоками. Такий підхід уже використовувався у протоколі SPDY.

Другий спосіб, що є основним в HTTP/2, полягає в наступному: браузер просить сервер завантажувати певні елементи контенту в першу чергу. Наприклад, браузер може попросити сервер спочатку завантажити CSS-файли або JavaScript, а вже потім HTML або зображення.

У HTTP/2 пріоритизація не обов'язковим, а бажаним методом. Однак мультиплексування без неї працювати належним чином не буде. Швидкість завантаження може бути навіть нижчою, ніж HTTP/1.1. Ресурси з нижчим пріоритетом займатимуть смугу, що призведе до зниження продуктивності.

Стиснення HTTP-заголовків

Сучасна веб-сторінка складається з багатьох елементів: зображення, JS, CSS та інші. У запиті на завантаження кожного з цих елементів браузер передає заголовок HTTP. Надсилаючи запитані елементи, сервер також додає до них заголовок. Все це пов'язано із зайвим витрачанням ресурсів.

У HTTP/2 заголовки передаються у стислому вигляді. Завдяки цьому зменшується кількість інформації, якою обмінюються між собою сервер та браузер. Замість алгоритмів gzip/deflate використовується HPACK. Це знижує вразливість до атак типу BREACH.

HTTP/2 та безпека

Однією з найважливіших вимог протоколу SPDY є обов'язкове шифрування (HTTPS) з'єднання між клієнтом та сервером. У HTTP/2 воно обов'язкового характеру немає. Однак розробники браузерів вирішили впровадити новий протокол лише для TLS(HTTPS)-з'єднань. Тому тим, хто думає про перехід на HTTP/2, потрібно спочатку перейти на HTTPS.

Це потрібно не лише для HTTP/2. У пошуку Googleвикористання безпечного з'єднанняє одним із критеріїв ранжирування. Браузери (див. і ) скоро позначатимуть сайти, що не підтримують https, як «небезпечні». Додамо також, що багато можливостей HTML5 - наприклад, геолокація - без безпечного з'єднання будуть недоступні.

Базове налаштування HTTP/2 в Nginx та Apache

Наведемо короткі інструкціїпо включенню та базовому налаштуванню HTTP/2 в Nginx та Apache. Як вже було сказано вище, більшість сучасних браузерів працюють з HTTP/2 тільки через TLS, тому конфігурації вашого веб-сервера повинні бути прописані відповідні налаштування.

Nginx

Підтримка HTTP/2 реалізована лише у новітніх версіях Nginx (1.9.5 і від). Якщо ви інсталюєте іншу версію, вам потрібно буде оновити її.

Після цього відкрийте конфігураційний файл/etc/nginx/nginx.conf і знайдіть у секції server наступний рядок:

Listen 443 ssl;

І замініть її на:

Listen 443 ssl http2;

Збережіть внесені зміни та перезавантажте Nginx:

$ sudo service nginx reload

Apache

В Apache HTTP/2 підтримується лише у версіях 2.4.17 та вище. Якщо у вас встановлено більше рання версія, виконайте оновлення та підключіть модуль mod_http2. Після цього додайте до конфігураційного файлу наступні рядки:

# for a https server Protocols h2 http/1.1 # for a http server Protocols h2c http/1.1

Після цього перезапустіть Apache. Ось і все - для базового налаштуванняцього цілком достатньо.

HTTP/2 та оптимізація сайтів

HTTP/2 назад сумісний із HTTP/1.1. Тому ви в принципі можете не робити жодних дій: роботі вашого сервісу нічого не загрожує.
Але при переході популярних веб-серверів і веб-браузерів на HTTP/2 ви побачите, що ваш сайт, який колись був оптимізований для збільшення швидкості завантаження сторінок і підвищення продуктивності, вже працює не так швидко, як раніше.

Багато способів оптимізації, які успішно використовуються в HTTP/1.1, у HTTP/2 не працюватимуть. Деякі з них потрібно модифікувати, а від деяких - відмовитися взагалі. Розглянемо це питання докладніше.

Об'єднання зображень у спрайти

У HTTP/1.1 було зручніше завантажити одне велике зображення, ніж робити безліч запитів та завантажувати багато маленьких. Це пов'язано з тим, що запити ставляться в чергу один за одним. Найпоширеніший спосіб збільшення швидкості завантаження полягав у поєднанні множинних невеликих зображень у спрайт-файл.

Спрайт повертався у відповідь єдиний запит. Навіть якщо користувач заходив на сторінку, на якій знаходиться одне невелике зображення, потрібно було завантажити весь спрайт.

У HTTP/2 з його мультиплексування таких проблем немає, проте використання спрайтів в певних ситуаціях може виявитися корисним. Об'єднання кількох зображень у спрайт (особливо якщо всі ці зображення знаходяться на одній сторінці) допомагає покращити стиск і таким чином знизити загальний об'ємзавантажених даних.

Вбудовування зображень за допомогою DataURI

Ще один популярний спосібвирішення проблеми множинних HTTP-запитів у HTTP/1.1 - вбудовування зображень з використанням Data URI. Це значно збільшує у вигляді таблицю стилів.

Якщо одночасно з вбудовуванням зображень для оптимізації використовується ще й конкатенація JS і CSS, користувачі швидше за все доведеться завантажити весь відповідний код, навіть якщо він не відвідуватиме сторінку з цими зображеннями.
У HTTP/2 така практика швидше погіршить, а не покращить продуктивність.

Конкатенація JS та CSS

Для оптимізації роботи сайтів часто використовується конкатенація невеликих файлів CSS і JS. Багато маленьких файлів поєднуються в один великий. Таким чином, вдається обійти ліміт на кількість HTTP-запитів.

Однак при використанні конкатенації може виникнути та сама проблема, що і зі спрайтами: зайшовши на якусь одну сторінку сайту, користувач завантажить всі файли, що використовуються на ньому, СSS- і JS-файли (при цьому дуже ймовірно, що більшість з цих файлів йому ніколи не знадобляться). Звичайно, можна ретельно відбирати файли для кожної сторінки сайту, але це буде займати багато часу.

Ще одна складність у тому, що це елементи конкатенированного файлу потрібно вичищати з кешу одночасно. Неможливо зробити так, щоб для одних елементів була виставлена ​​одна дата закінчення терміну дії, а для інших (які, до того ж, і використовуються набагато частіше) — інша. Якщо змінити хоча б один рядок у CSS, термін дії закінчиться відразу у всіх елементів.

Чи варто користуватися конкатенацією в HTTP/2? Якщо HTTP-запити не вимагають істотних витрат ресурсів, то без неї можна обійтися. Завантаження безлічі невеликих файлів стилів жодної проблеми не становитиме. Не буде і труднощів із закінченням термінів дії та кешуванням.

Доменне шардування

HTTP/1.1 має обмеження на кількість відкритих з'єднань. Щоб обійти це обмеження, доводиться завантажувати статичні ресурси з кількох піддоменів одного домену. Такий прийом називається доменним шардуванням; він часто використовується, наприклад, для сторінок із великою кількістю зображень. Це допомагає збільшити швидкість завантаження, але водночас і створює додаткові проблеми.

З переходом HTTP/2 необхідність домену шардировании відпадає. Ви можете запросити стільки ресурсів, скільки вам потрібно. Більш того, у випадку з HTTP/2 шардування не покращить продуктивність, а приведе швидше до протилежного ефекту, оскільки створить додаткові TCP-з'єднання і заважатиме пріорітизації.

Коли йти?

Коли планувати перехід на HTTP/2? Однозначної відповіді це питання немає і не може. Проте дамо одну підказку: регулярно переглядайте логи відвідуваності вашого сервісу. Коли ви побачите, що більшість відвідувачів використовують підтримуючі HTTP/2 браузери - можна переходити. на поточний моментпідтримка HTTP/2 реалізована в Chrome (у тому числі і в мобільної версіїдля Android), Firefox, Opera, Edge, Safari.

При плануванні переходу слід враховувати особливості вашого проекту. Якщо у вас багато користувачів, які приходять до вас з мобільних пристроїв, то це означає, що вам бажано перейти на HTTP/2 якнайшвидше. На смартфонах та планшетах переваги нового протоколу будуть особливо очевидними. Однак і тут потрібно враховувати безліч нюансів: наприклад, у багатьох регіонах світу досі багато користувачів браузера Opera Mini, а він HTTP/2 поки що не підтримує.

Якщо ви плануєте запускати новий веб-сервіс, подумайте про перспективу переходу на HTTP/2. Звичайно, вам ще доведеться використовувати HTTP/1.1 протягом якогось часу, але вже зараз ви можете вжити заходів для оптимізації, які полегшать вам життя в майбутньому.

Корисні посилання

Насамкінець наведемо для зацікавлених читачів кілька корисних посилань

HTTP/2 - нова версія мережевого протоколу HTTP, заснована на розробленому компанією Google протоколі SPDY. Попередня версіяпротоколу HTTP/1.1 прийнято далекого 1999 року, коли сайти дуже відрізнялися від сучасних. В наш час веб-технології розвиваються надто стрімко, тому нова версія протоколу – дуже важливе та потрібне нововведення, спрямоване на підвищення безпеки, ефективності та швидкості роботи сайтів.

Ключові особливості HTTP/2

• Мультиплексування.У HTTP/1.1 для кожного запиту потрібно встановлювати окреме з'єднання TCP, одночасна кількістьяких обмежено. Мультиплексування в HTTP/2 дозволяє браузеру виконувати безліч запитів у межах одного з'єднання TCP. Таким чином, статичні елементи завантажуються паралельно, запити та відповіді не блокують один одного. Як результат, швидке завантаженнята візуалізація сторінки сайту.

• Стиснення HTTP-заголовків.При надсиланні запитів клієнтом та відповідей сервером передаються HTTP-заголовки, які містять додаткову інформацію. Якщо сторінка, що завантажується, містить велику кількість елементів - всі заголовки будуть займати пристойний обсяг. У HTTP/2 заголовки передаються у стислому вигляді, що дозволяє істотно скоротити обсяг інформації, якою обмінюються сервер та клієнт. Крім того, для стиснення використовується спеціальний алгоритм HPACK, який знижує ризики атак по перехопленню інформації.
• Пріоритизація.Призначення пріоритетів запиту дозволяє забезпечити візуальну швидкість завантаження сторінки для користувача. Наприклад, браузер може попросити сервер відправити в першу чергу файли CSS, оскільки вони дуже важливі визначення виду сторінки.
• Server Push.У разі використання HTTP/1.1 сервер відправляє у відповідь на запит HTML-код і очікує від браузера запитів на елементи сторінки. У HTTP/2 додано функцію Server Push, яка дозволяє серверу відразу відправляти додаткові елементи, які можуть знадобитися браузеру в майбутньому
• Бінарність.Протокол HTTP/2 є бінарним, тоді як HTTP/1.1 – текстовий. Тому він більш ефективний для аналізу та обробки сервером, більш компактний при передачі і менше схильний до помилок.

Підтримка браузерами

На сьогоднішній день усі популярні браузери для комп'ютерів та мобільних пристроїв підтримують роботу за протоколом HTTP/2. Протокол HTTP/1.1 буде використовуватись у тому випадку, якщо браузер не підтримує новий протокол. Таким чином, HTTP/2 включається автоматично завжди, коли це можливо.

Важливо!Протокол HTTP/2 не вимагає обов'язкового шифрування, проте розробники браузерів вирішили реалізувати роботу з новим протоколом лише через TLS (HTTPS). Тому наявність встановленого (комерційного чи безкоштовного) є обов'язковою умовою для роботи за протоколом HTTP/2.

Нижче представлені версії браузерів, для яких реалізована підтримка протоколу HTTP/2 (виділені зеленим фоном). У Internet Explorer 11 новий протокол підтримується тільки в Windows 10, Safari - OSX 10.11 і вище.

Сьогодні все більше відвідувачів використовують для доступу до сайтів мобільні пристрої. Можливості HTTP/2 добре працюють для зменшення затримок при доступі до ресурсів мобільних мереж передачі даних, в яких пропускна здатністьзалежить від різних факторів, а якість зв'язку не завжди прийнятна. Враховуючи підтримку HTTP/2 усіма основними мобільними браузерамипереваги нового протоколу на мобільних пристроях є особливо очевидними.

HTTP/2 та пошукова оптимізація(SEO)

Безперечно, багатьох власників веб-сайтів хвилює питання оптимізації своїх ресурсів для пошукових систем. Одним з важливих факторівРанжування для пошукових систем є швидкість завантаження сайтів. Тому сайти, які працюють за протоколом HTTP/2, отримають бонус у ранжируванні саме за швидкість завантаження. Відзначимо, що тепер ще вигідніше переходити на HTTPS, тому що це дозволить додатково отримати бонус у ранжируванні пошукових систем та за використання HTTPS.

HTTP/2 та оптимізація сайтів

Для протоколу HTTP/1.1 веб-розробники успішно використовували низку оптимізації, щоб уникнути обмеження протоколу. Але не всі оптимізації добре працюватимуть у HTTP/2 - деякі з них необхідно модифікувати, а від деяких зовсім відмовитися. Нагадаємо, що HTTP/2 назад сумісний з HTTP/1.1, тому можна не робити жодних дій - сайт працюватиме як і раніше. Нижче розглянемо детально, на що слід звернути увагу.

• Об'єднання зображень у спрайт.У HTTP/1.1 об'єднання невеликих зображень в один спрайт ефективно, тому що потрібно лише одне HTTP-з'єднання і не виникає черги запитів. Але якщо на сторінці використовується лише одне зображення - потрібно завантажити весь спрайт. У HTTP/2 з мультиплексуванням черга запитів більше не є проблемою, тому в багатьох випадках оптимально завантажувати багато дрібних зображень, які використовуються на сторінці. Однак, у деяких випадках об'єднання зображень в один спрайт може бути корисним, оскільки покращується стиснення та зменшується обсяг завантаження, особливо якщо всі зображення використовуються на сторінці.
• Вбудовування зображень з допомогою data URI.Ще один спосіб вирішення проблеми з численними запитами – вбудовування зображень у CSS за допомогою data URI. За рахунок цього може істотно збільшуватися розмір файлу зі стилями, але потрібно менше з'єднань HTTP. У HTTP/2 такий підхід може бути корисним, але навряд чи допомагатиме поліпшенню продуктивності.
• Об'єднання CSS та JavaScript.Ще один спосіб обмеження кількості з'єднань HTTP. При такому підході всі файли css/js поєднуються в один великий файл. А значить, при завантаженні однієї сторінки завантажуються відразу всі таблиці стилів і js-код, навіть якщо вони не використовуються на поточній сторінці. Крім того, браузером кешується відразу весь загальний файл і невелика зміна коду вимагатиме повторного завантаження всього файлу. З мультиплексуванням в HTTP/2 завантаження безлічі дрібних файлів не є проблемою, тому розподіл файлів css/js тільки на потрібні сторінкибуде набагато ефективніше та сприятиме збільшенню швидкості завантаження сайту.
• Доменний шардинг. Цей спосіб полягає в завантаженні статичних ресурсів з різних доменівабо піддоменів основного домену та актуальний лише для HTTP/1.1. Причина та сама - обмеження на кількість паралельних HTTP-з'єднань. У HTTP/2 такий підхід негативно впливає на продуктивність за рахунок відкриття додаткових TCP-з'єднань та перешкоди в обробці пріоритетів ресурсів.

Як перевірити, чи підтримує сайт протокол HTTP/2

• Онлайн-сервіси.

Існують онлайн-сервіси, за допомогою яких можна легко та швидко перевірити наявність підтримки HTTP/2. Наприклад, .

• Розширення для браузерів.

Для браузерів є розширення, які іконкою-індикатором сповіщають про те, що сайт відкритий за протоколом HTTP/2.

• Інструменти розробника у браузері.

Розглянемо для прикладу перегляд протоколу в інструментах розробника в браузерах Chromeта Firefox.

1. Відкриваємо інструменти розробника: натискаємо правою кнопкоюмиші на сторінці і вибираємо в контекстному меню«Переглянути код» або натискаємо Ctrl+Shift+I.
2. Переходимо на вкладку "Network" і натискаємо кнопку F5 для оновлення сторінки
3. Натискаємо правою кнопкою миші на назві якогось стовпця і вибираємо в контекстному меню «Protocol», додавши тим самим відповідний стовпець.

Для кожного ресурсу в стовпці "Protocol" відображається протокол, за яким він завантажений:

Firefox:

1. Відкриваємо інструменти розробника: натискаємо правою кнопкою миші на сторінці та вибираємо у контекстному меню «Дослідити елемент» або натискаємо Ctrl+Shift+I.
2. Переходимо на вкладку «Мережа» та натискаємо кнопку F5 для оновлення сторінки
3. Натискаємо правою кнопкою миші на назві якогось стовпця і вибираємо в контекстному меню «Протокол», додавши тим самим відповідний стовпець.

Для кожного ресурсу в стовпці «Протокол» відображається протокол, за яким він завантажений:

Ми запровадили підтримку HTTP/2 на нових серверах.HTTP – це протокол, який регулює зв'язок між вашим сервером та браузерами відвідувачів вашого сайту.HTTP/2 - це перше оновлення протоколу з 1999р. І воно обіцяє нам, що сайти стануть набагато швидшими для всіх.Наскільки протокол HTTP/2 швидше за HTTP/1.1 ви можете побачити

Які можливості нового протоколу?

У HTTP/2 більше широкі можливостіта переваги, ніж у попередньої версії.Основне – сайти завантажуються набагато швидше.Досягається це завдяки низці нововведень:

Мультиплексування

Завдяки мультиплескування в протоколі HTTP/2 всі дані передаються через одне з'єднання TCP.Тоді як у HTTP/1.1 для отримання кожного елемента, що становить веб-сторінку, необхідно створювати окреме з'єднання. З урахуванням того, що таких з'єднань могло бути одночасно лише близько 6, це суттєво уповільнювало завантаження сторінок.

Мультиплексування дозволяє браузеру виконувати безліч запитів у рамках одного з'єднання TCP

Пріоритетність

Під час розробки HTTP/2 також враховувалося, що потрібно забезпечити візуальну швидкість завантаження сторінки для користувача. Кожному потоку надати пріоритет завантаження.Наприклад, якщо веб-сторінка досить довга, можна спочатку завантажувати контент, розташований у верхній частині сторінки.

Стиснення заголовків

Сучасна веб-сторінка складається з багатьох елементів: зображення, JS, CSS та інші. У запиті на завантаження кожного з цих елементів браузер передає заголовок HTTP. Надсилаючи запитані елементи, сервер також додає до них заголовок. Таким чином, мережевий каналвитрачається також передачі великої кількості службової інформації.

У HTTP/2 заголовки передаються у стислому вигляді. Завдяки цьому зменшується кількість інформації, якою обмінюються між собою сервер та браузер. Розроблено спеціальний алгоритм HPACK, який усуває відомі вразливості, що дозволяють перехопити інформацію.

Server push

Це ще одна потужна можливістьпротоколу HTTP/2. Тепер сервер у відповідь на запит може надсилати додаткові елементи, які знадобляться браузеру. Наприклад, тепер при запиті сторінки сервер може окрім самої сторінки відразу надсилати JavaScript та CSS файлиякі потрібні для її відображення.

SSL та шифрування

Розробники протоколу HTTP/2 принципово реалізували його лише безпечних з'єднань. Отже, якщо ви захочете перейти на протокол HTTP/2, вам знадобиться комерційний SSL сертифікат.

Якщо ви хочете спробувати нові протоколи, ми надаємотестові на місяць. Також, при замовленні нових Proтарифів ми надаємотерміном роком.

Всі інші наші клієнти мають можливість придбати до кінця березня 2016 р.

Як перейти до HTTP/2?

Ми вважаємо, що перехід на протокол HTTP/2 дозволить суттєво прискорити завантаження сайтів більшості наших клієнтів, а також суттєво зменшить навантаження на сервери.

Якщо ви бажаєте, щоб ваш сайт працював за протоколом HTTP/2, просто повідомте нам наі ми перенесемо його на сервер із підтримкою HTTP/2.

Протокол передачі гіпертексту(HTTP, англ. HyperText Transfer Protocol) - протокол, який керує з'єднанням між вашим сервером та браузерами клієнтів. Вперше після 1999 року з'явилася нова версія цього протоколу,і це обіцяє значно прискорити кожний сайт.

У цій статті ми опишемо основиHTTP/2для дизайнерів та розробників. Я поясню деякі ключові особливостінового протоколу, розгляну сумісність (серверну та браузерну) та зупинюся докладніше на речах, над якими потрібно замислитись, оскільки все частіше бачимо впровадженняHTTP/2. Прочитавши цю статтю, ви отримаєте огляд того, що потрібно змінити у вашій роботі у коротко- та довгостроковій перспективі. Також я включу безліч додаткових ресурсів, на той випадок, якщо ви захочете заглибитися у питання. Моя мета – надати достатню кількість знань, яка допоможе прийняти правильне рішення про перехід наHTTP/2.

Для подальшого прочитання

• Все, що ви повинні знати про сайти, оптимізовані для мобільних пристроїв

коротка історія HTTP.

Якщо у ваш сайт використовує тільки http, тоді моя пропозиція якнайшвидше перейти на https, і вже тоді визначиться з HTTP/2стратегією.

Об'єднання безлічі зображень у спрайти

У HTTP/1.1отримання одного великого зображеннянабагато ефективніше для браузерів, ніж багато дрібних запитів. Це відбувається тому, що кілька запитів вишиковуються в чергу один за одним. Об'єднання дрібних файлів у спрайт було тимчасовим вирішенням цієї проблеми.

Результуючий спрайт повертався одним http запитом, запобігаючи проблемі черги запитів. Однак, навіть якщо відвідувач знаходиться на сторінці, де відображаються лише кілька іконок, йому все одно потрібно завантажити набагато більший файл.

З мультиплексуючою здатністю HTTP/2, Черга ресурсів більше не є проблемою. Віддача дрібних зображень буде окремо найкращим рішеннямв багатьох випадках; Вам потрібно обробляти лише те, що потрібно для запитаної сторінки. Але створення спрайтів і надалі буде виправданим у багатьох випадках. HTTP реквести – це лише один аспект продуктивності. Об'єднання деяких зображень разом у спрайт дозволяє досягти кращого стиску, і, як результат, меншого обсягу завантаження, особливо якщо всі зображення використовуються на сторінці. Проте спрайти більше не завжди будуть найкращим рішенням.

Вбудовування зображень за рахунок використання data uri

Інше обхідне вирішення проблеми множини HTTP-запитів - вбудовування зображень у css з використанням data uri . Використання зображень у такий спосіб робить css-файл набагато більше. Якщо ви на додаток використовуєте стиснення та об'єднання ассетів, відвідувачі завантажуватимуть величезну кількість коду, навіть якщо ніколи не перейдуть на сторінку, де він дійсно потрібен.

З оптимізацією HTTP-запитів у HTTP/2, Ця "найкраща практика" більше заважатиме, ніж допомагати поліпшенню продуктивності.

Об'єднання CSS та Javascript

Багато хто з нас використовують об'єднання дрібних css і javascript файлів. Найчастіше ми хочемо утримувати їх окремо під час розробки - для кращого розуміння, але ми знаємо, що завантаження одного файлу браузером набагато ефективніше, ніж п'ять. Ще раз ми обмежуємо кількість HTTP-запитів.

Якщо ви робите це, відвідувач, відкривши головну сторінку, завантажить всі css- та javascript файли, необхідні для роботи сайту, навіть якщо не використовує більшість з них. Як розробник, ви можете зменшити проблему шляхом ретельного підбору файлів, що підключаються для кожної сторінки сайту, але для цього потрібно занадто багато роботи.

Ще одна додаткова проблемаз об'єднанням файлів – очищення кешу: чиститься все разом. Ви не можете вказати файли, які ніколи не змінюються, довгий часжиття, і коротке, що часто змінюється. Весь кеш має бути оновлений, навіть якщо помінявся один рядок у css-файлі.

Припускаю, ви розумієте, чого я хилю! HTTP-запити дешеві в HTTP/2світі. Розподіл ассетів на використовуваних сторінках буде набагато оптимальнішим. Ви зможете віддавати тільки код, що реально використовується. Завантаження безлічі дрібних файлів не матиме значення. Також ви можете розподіляти файли за частотою їх змін.

Розподіл ресурсів між хостами: sharding

C HTTP/1.1, ви обмежені кількістю відкритих з'єднань. Якщо неможливо уникнути завантаження, один із способів вирішення проблеми – отримання ресурсів із різних доменів. Ця методика називається domain sharding. Це хоча й прискорює час завантаження, але може викликати нові проблеми, не кажучи вже про те, що це потребує додаткових витрат під час розробки.

HTTP/2скасовує необхідність domain sharding, тому що знято обмеження кількості ресурсів, що одночасно завантажуються. Більше того, це може погано вплинути на продуктивність, оскільки відкриває додаткові TCP з'єднанняі заважає обробляти HTTP/2пріоритети ресурсів.

Як тепер підготуватися до HTTP/2?

Якщо ви стартуєте довговічний проект проект, але з якоїсь причини не можете запустити його з HTTP/2, можливо, з причин підтримки сервера, краще відразу підготуватися до HTTP/2. Ви можете додати кілька речей, які спростять перехід у майбутньому.

Створіть індивідуальні асети, додатково до спрайтів та data uri

Якщо ви створюєте спрайти, подбайте також про створення та оптимізацію дрібних ассетів або менших спрайтів під індивідуальні сторінки, якщо бачите, що це покращить продуктивність. Це спростить перехід від великих спрайтів до дрібніших, якщо буде потрібно.

Це також стосується та data uri. Якщо ви використовуєте в css, підготуйте також картинки для того часу, коли ви відмовитеся від цієї техніки.

Упорядкуйте ассети за розділами сайту

Через використання об'єднання css і JavaScript файлів, існує спокуса об'єднувати їх і на етапі розробки, так як вони все одно потім збираються в один файл. Коли ви перейдіть на HTTP/2, ви отримаєте кращу продуктивність, якщо ретельно розділяти ресурси, не завантажуючи нічого зайвого. Отже, організація ассетів тепер матиме цінність. Зараз ви можете продовжувати об'єднувати асети, а за необхідності відразу ж почати віддавати їх окремо.

Управління domain sharding

Поточна найкраща практика для HTTP/1.1- обмеження sharding двома хостами. У HTTP/2можливо об'єднати з'єднання, якщо сертифікат TLS валідний для обох хостів і хост резолвується для одного IP-адреси. Оскільки браузерна реалізація вимагає, щоб HTTP/2працював через https, необхідно отримати TLS сертифікат, щоб використовувати HTTP/2. Перегляньте більше на 26 слайді Ilya Grigorik's з Velocity Conference.

Це далеко не все

Зрештою, ми отримаємо безліч кращих практик для HTTP/2. Для кращої продуктивності, цей протокол дасть вам багато можливостей для управління, і вам доведеться ухвалювати рішення для кожного проекту. Я не розповіла в цій статті, як використовувати переваги від нових фіч HTTP/2, таких, як, наприклад, серверний пуш. Ця технологія дозволяє вам вирішувати, які ресурси пріоритетніші і змушує сервер обробляти їх раніше, ніж інші.

Коли перейти?

Для дизайнерів і розробників, які не мають повного контролю над сервером, це може почекати до оновлення серверів. Існують хостинг-провайдери, які пропонують HTTP/2- навіть шаред хостинги, тому ви можете рекомендувати клієнту такі рішення, якщо бачите переваги.

Якщо сайт розміщено на сервері, який підтримує HTTP/2, рішення оптимізувати під HTTP/1.1або HTTP/2має бути прийнято залежно від протоколу, який підтримують браузери більшості користувачів. Пам'ятайте, що HTTP/2назад сумісний - вам не доведеться робити нічого особливого. Рішення, яке вам потрібно ухвалити – коли саме оптимізувати під новий протокол.

Вам потрібно буде ухвалити рішення, користуючись даними аналітики. Якщо більшість користувачів використовує браузери, які підтримують HTTP/2тоді є сенс оптимізувати під цих користувачів. Багато хто з них вже досяг цього моменту. Вам потрібно використовувати дані з таких сайтів, як Can I Use разом із даними, що збираються з власної аналітики та розуміння інтересів аудиторії. Наприклад, більшість переваг HTTP/2відчують користувачі мобільних пристроїв. Якщо у вас більше мобільного трафікуЦе може свідчити про необхідність найближчого переходу. Однак, якщо багато користувачів використовують Opera Mini, тоді потрібно почекати з переходом на HTTP/2, оскільки, незважаючи на безліч користувачів у деяких країнах світу, цей браузер не підтримує новий стандарт.

Якщо ви створюєте новий сайт сьогодні, можна порадити відразу пам'ятати про оптимізацію HTTP/2під час опрацювання. Якщо під час запуску, ви зрозумієте, що потрібно зробити поступку на користь HTTP/1.1через проблеми сумісності сервера/браузерів, оптимізувати можна під час процесу складання, таким чином, залишаючи можливість швидко перейти на HTTP/2.

План дій щодо роботи з HTTP/2

1. Запустіть проект, або перейдіть але TLS зараз.

Це має бути вашим пріоритетом.

2. Підготуйте ваш процес збирання до HTTP/2.

Будь-який сайт у довгостроковій перспективі отримає переваги при переході на HTTP/2. Тож створюйте такий процес складання, який можна оптимізувати під обидва протоколи.

3. Перевірте вашу статистику

Перевіривши статистику використання браузерів та таблицю сумісності Can I Use, ви зможете побачити, скільки відсотків відвідувачів отримувати переваги при оптимізації під HTTP/2.

4. Перевірте свій хостинг

Коли ви досягнете моменту, коли будуть переваги переходу на новий протокол, ви повинні перевірити, що хостинг підтримує HTTP/2. Поговоріть з хостинг провайдером або адміністратором сервера, щоб дізнатися про їхні плани про перехід.

5. Займіться оптимізацією під HTTP/2.

Коли ваш сервер підтримує HTTP/2, решта за вами. Перестаньте використовувати старі кращі практикиі перейдіть на нові. Це означатиме, що користувачі, браузери яких не підтримують HTTP/2, отримають меншу продуктивність, тому вирішальним фактом має стати кількість користувачів, які мають переваги.

Після переходу на HTTP/2, буде чудово протестувати приріст швидкості та побачити, яка техніка найбільше покращила сайт. Я шукаю інформацію, як люди переносили реальні сайти на новий протокол. Ця інформація допоможе нам розробити нове покоління найкращих практик.

Дізнатися більше

Зростаюча кількість інформації про HTTP/2доступні онлайн. Деякі ресурси розміщу тут, частина їх були використані при написанні статті.

• “Hypertext Transfer Protocol Version 2 (HTTP/2)
  • HTTP/2 and SPDY Indicator: Firefox and Chrome

  Цей плагін для браузера показує, чи працює сайт з HTTP/2.

  • Для подальшого прочитання також подивіться на цей