Ілля Григорик про впровадження HTTP/2

Відомий фахівець з серверної і клієнтської оптимізації, співавтор WebRTC, автор книги "High Perfomance Browser Networking" Ілля Григорик з Google опублікував презентацію HTTP/2 all the things!", в якій пояснює, як слід налаштовувати серверну частину під HTTP 2.0, щоб підвищити швидкість завантаження сторінок і зменшити latency, у порівнянні з HTTP 1.1.


Режим Connection View у браузері показує завантаження елементів заголовної сторінки Yahoo.com HTTP 1.1

Ілля починає з того, що для сучасних сайтів більша частина затримок припадає на очікування завантаження ресурсів, при цьому смуга пропускання не є обмежуючим фактором (синім кольором на діаграмі Connection View). За статистикою, для завантаження середньої веб-сторінки браузер робить 78 запитів до 12 різних хостів (загальний розмір завантажених файлів 1232 КБ).

Для 1 млн найбільших сайтів інтернету, за версією Alexa, на 5-мегабитном каналі, середній час завантаження сторінки становить 2,413, при цьому CPU працює лише 0,735 с, а решта припадає на очікування надходження ресурсів з мережі (latency).

Проблеми HTTP 1.1 полягають у великій кількості запитів, обмеженому паралелізм, не працює на практиці конвеєрної обробки запитів, наявності конкурентних TCP-потоків, оверхеде службового трафіку.

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

Проблеми з великою кількістю запитів при розробці програм під HTTP 1.1 теж вирішуються неправильним чином: через concat (створення великих монолітних фрагментів коду, дорога инвалидация кеша, відкладене виконання JSS/CSS) і inline (дублювання ресурсів на кожній сторінці, зламана пріоритизація).

Що робити?

Все дуже просто. Новий HTTP 2.0 виправляє багато недоліки HTTP 1.1, впевнений Ілля Григорик. HTTP 2.0 не вимагає встановлення безлічі сполук і зменшує latency при збереженні звичного семантики HTTP 1.1.



По-перше, всі потоки змішуються шляхом розбиття на фрейми (HEADERS, DATA, ін.), які пересилаються по єдиному TCP-з'єднання. Для фреймів діє пріоритет і контроль потоку. А server-push замінює inline. Ну і, звичайно, ефективне стиснення заголовків, аж до того, що HEADER «стискується» до 9 байт (передаються тільки зміни).



Як конкретно використовувати переваги HTTP 2.0 для оптимізації серверних додатків? Це найцікавіша частина презентації Іллі Григорика.

Усуваємо доменний шардінг
Шардінг конкретно б'є по продуктивності HTTP/2, ламає пріоритизації кадрів, контроль потоку та ін.

У разі необхідності можна реалізувати шардінг через
altName
. Якщо використовується один IP і один сертифікат, то HTTP/2 зможе відкрити єдине з'єднання для всіх шардов.

Позбавляємося від непотрібних оптимізацій (concat, CSS-спрайт)
Потоки більше не є обмеженням, так що можна грамотно розподіляти ресурси по модулям, задавати стратегію кешування для кожного з них.

Впроваджуємо server-push замість inline
Сервер тепер може видавати кілька відповідей на запит. Клієнт замовляє що-то одне, а сервер йому може дати в додачу і щось інше. Кожен ресурс кешується незалежно (при цьому необов'язково кешувати на кожен запит, є smart push). До речі, з допомогою серверного push-повідомлення можна і анулювати запис в клієнтському кеші!

Smart push — взагалі чудова річ. Сервер сам аналізує трафік і будує залежності, які ресурси запитує клієнт, залежно від referrer'а. Наприклад, index.html → {style.css, app.js}. Згідно з цими закономірностями і створюються правила для подальших push-повідомлень новим клієнтам.



Ілля Григорик підкреслює, що у випадку з HTTP/2 сервери обов'язково повинні бути правильно налаштовані. Це не було так критично у часи HTTP/1.1, але тепер так воно і є. Наприклад, HTTP/1.1 браузер сам висилав спочатку важливі запити (index.html, style.css), притримуючи другорядні (hero.jpg, other.jpg, more.jpg та ін.), тепер же немає. Так що якщо не настроїти сервер на обробку важливих запитів у першу чергу, постраждає продуктивність.

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

Тестування показало, що при використанні SPDY затримка (latency) і швидкість завантаження сторінки зменшуються на 30-40%.

Наприклад, Twitter протестував затримку доступу до API у грудні 2013-го. Результати в мілісекундах показано на графіку для 50-й, 75-й, 95-й і 99-ї перцентилі (по медіані). Цікаво, що SPDY приносить більше користі, коли клієнт підключений по гіршого каналу зв'язку (low latency locale).





Компанія Google опублікувала свою статистику по збільшенню швидкості завантаження сторінок ще рік назад.






Google News
Google
Google Drive
Google Maps
По медіані
-43%
-27%
-23
-24%
5-я перцентиль
(швидкі з'єднання)
-32%
-30%
-15%
-20%
95-я перцентиль
(повільні з'єднання)
-44%
-33%
-36%
-28%
Вбудована підтримка HTTP/2 з'явиться в найближчій стабільної версії Chrome 39 і в найближчому стабільної версії Firefox 34, так що всього через кілька місяців більшість браузерів в інтернеті будуть підтримувати HTTP/2 і зможуть користуватися перевагами нового протоколу (оскільки SPDY став частиною HTTP/2, то тепер його окрема інкарнація виводиться з обігу).

На Github ведеться список відомих реалізація HTTP/2 на C#, NodeJS, C++, Perl і т.д. Туди входить і бібліотека nghttp2 на C. загалом, Ілля Григорик закликає всіх оптимізувати свої сервери під HTTP/2 і перевірити коректну роботу TLS.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.