Що означає мультиплексування в HTTP / 2

Хтось може пояснити мультиплексування стосовно HTTP / 2 і як це працює?

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

А тепер набагато складнішу відповідь ...

Коли ви завантажуєте веб-сторінку, вона завантажує HTML-сторінку, вона бачить, що їй потрібні CSS, трохи JavaScript, завантаження зображень ... тощо.

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

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

Як приклад, припустимо, що 10 веб-сторінок потрібно завантажити після завантаження самого HTML (що є дуже маленьким сайтом за сучасними стандартами, оскільки 100+ ресурсів є загальним, але ми будемо робити це простим і підемо з цим приклад). Припустимо, що кожен запит вимагає 100 мс для подорожі через Інтернет до веб-сервера та назад, а час обробки в будь-якому кінці незначний (скажімо, 0 для цього прикладу для простоти). Оскільки вам доведеться надсилати кожен ресурс і чекати відповіді по черзі, для завантаження всього сайту знадобиться 10 * 100 мс = 1000 мс або 1 секунда.

Щоб обійти це, браузери зазвичай відкривають кілька підключень до веб-сервера (зазвичай 6). Це означає, що браузер може запускати кілька запитів одночасно, що набагато краще, але ціною того, що потрібно налаштовувати та керувати кількома з’єднаннями (що впливає як на браузер, так і на сервер). Давайте продовжимо попередній приклад, а також скажемо, що є 4 з'єднання, а для простоти, скажімо, всі запити рівні. У цьому випадку ви можете розділити запити на всі чотири з'єднання, тому два матимуть 3 ресурси для отримання, а два матимуть 2 ресурси, щоб отримати повністю десять ресурсів (3 + 3 + 2 + 2 = 10). У цьому випадку найгірший випадок - 3 рази раунду або 300 мс = 0,3 секунди - хороше покращення, але цей простий приклад не включає витрати на встановлення цих кількох з'єднань,

HTTP / 2 дозволяє відправляти кілька запитів на одномуз'єднання - тому вам не потрібно відкривати кілька з'єднань, як зазначено вище. Тож ваш браузер може сказати "Дай мені цей файл CSS. Дай мені той файл JavaScript. Дай мені image1.jpg. Дай мені image2.jpg ... І т. Д." для повного використання єдиного з'єднання. Це має очевидну перевагу в продуктивності, не затримуючи надсилання тих запитів, які чекають на безкоштовне з'єднання. Усі ці запити проходять через Інтернет до сервера (майже) паралельно. Сервер відповідає на кожного, і тоді вони починають прокладати шлях назад. Насправді це навіть потужніше, оскільки веб-сервер може реагувати на них у будь-якому порядку і відправляти назад файли в іншому порядку, або навіть розбивати кожен запитуваний файл на частини та змішувати файли між собою.випуск блокування рядка ). Потім веб-браузеру доручено скласти всі частини назад. У кращому випадку (якщо не передбачається обмеження пропускної здатності - див. Нижче), якщо всі 10 запитів виконуються майже одночасно паралельно і на них сервер негайно відповідає, це означає, що ви в основному маєте одну поїздку в обидва кінці або 100 мс або 0,1 секунди, щоб завантажити всі 10 ресурсів. І це не має жодних мінусів, які мали кілька з'єднань для HTTP / 1.1! Це також набагато масштабніше, оскільки ресурси на кожному веб-сайті зростають (в даний час браузери відкривають до 6 паралельних з'єднань за протоколом HTTP / 1.1, але чи повинні вони зростати в міру ускладнення сайтів?).

Ця схема показує відмінності, і є також анімована версія .

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

У коментарях нижче висвітлено одне, як пропускна здатність впливає на нас тут. Звичайно, ваше з’єднання з Інтернетом обмежується тим, скільки ви можете завантажити, і HTTP / 2 не вирішує цього. Отже, якщо ці 10 ресурсів, про які йшлося у наведених вище прикладах, є масовими зображеннями якості друку, то завантаження їх все одно буде повільним. Однак для більшості веб-браузерів пропускна здатність є меншою проблемою, ніж затримка. Отже, якщо ці десять ресурсів є невеликими елементами (зокрема, текстовими ресурсами, такими як CSS та JavaScript, які можна зібрати в мініатюру), як це дуже часто зустрічається на веб-сайтах, то пропускна здатність насправді не є проблемою - саме обсяг ресурсів часто є проблема, і HTTP / 2 прагне вирішити цю проблему. Ось чому конкатенація використовується в HTTP / 1.1 як ще одне обхідне рішення, тому, наприклад, усі CSS часто об'єднуються в один файл:анти-шаблон під HTTP / 2 - хоча є аргументи проти того, щоб повністю його повністю позбутися).

Для прикладу з реального світу: припустимо, ви повинні замовити 10 товарів у магазині для доставки додому:

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

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

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

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

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

Сподіваюся, що це допомагає.

Подати запит на мультиплексування

HTTP / 2 може надсилати кілька запитів на дані паралельно через одне TCP-з'єднання. Це найдосконаліша функція протоколу HTTP / 2, оскільки вона дозволяє завантажувати веб-файли асинхронно з одного сервера. Більшість сучасних браузерів обмежують TCP-з'єднання одним сервером. Це зменшує додатковий час поїздки в обидва кінці (RTT), пришвидшуючи завантаження веб-сайту без будь-якої оптимізації, і робить непотрібним шардінг домену.

Прості відповіді ( джерело ):

Мультиплексування означає, що ваш браузер може надсилати кілька запитів і отримувати кілька відповідей, "згрупованих" в єдине TCP-з'єднання. Таким чином, робоче навантаження, пов’язане з пошуком і рукостисканням DNS, зберігається для файлів, що надходять з того самого сервера.

Складний / Детальний відповідь:

Зверніть увагу на відповідь, надану @BazzaDP.

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

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

Оскільки відповідь @Juanma Menendez правильна, хоча його діаграма заплутана, я вирішив вдосконалити її, пояснивши різницю між мультиплексуванням та конвеєризацією, поняття, які часто поєднуються.

Трубопровід (HTTP / 1.1)

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

Мультиплексування (HTTP / 2)

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

Сподіваємось, покращене зображення прояснить різницю: