Протокол QUIC: перехід від Web TCP до UDP

Протокол QUIC (назва розшифровується як Quick UDP Internet Connections) — абсолютно новий спосіб передачі інформації в інтернеті, побудований поверх протоколу UDP, замість загальноприйнятого раніше використання TCP. Деякі люди називають його (в жарт) TCP/2. Перехід до UDP — найбільш цікава і потужна особливість протоколу, з якої випливають деякі інші особливості.

Сьогоднішній Web побудований на протоколі TCP, який був обраний за його надійність і гарантованість доставки пакетів. Для відкриття TCP-з'єднання використовується так зване «трикратне рукостискання». Це означає додаткові цикли відправлення-приймання повідомлень для кожного нового з'єднання, що збільшує затримки.

image

Якщо ви захочете встановити захищене SSL-з'єднання, доведеться переслати ще більше пакетів.

image

Деякі інновації, на зразок Fast TCP Open, поліпшать деякі аспекти ситуації, але ця технологія поки не дуже широко поширена.

Протокол UDP, з іншого боку, побудований на ідеї «відправити пакет і забути про нього». Повідомлення, відправлене за UDP, буде доставлено одержувачу (не гарантовано, з деякою ймовірністю успіху). Яскраве перевага тут в меншому часу встановлення з'єднання, такий же яскравий недолік — негарантированность доставки або порядку приходу пакетів одержувачу. Це означає, що для забезпечення надійності доведеться побудувати певний механізм поверх UDP, який гарантує доставку пакетів.

І тут на сцену виходить QUIC від Google.

Протокол QUIC може відкрити з'єднання і узгодити всі параметри SSL (HTTPs) за 1 або 2 пакети (1 або 2 — залежить від того, чи відкривається з'єднання до нового сервера або до вже знайомого).

image

Це неймовірно прискорює відкриття з'єднання і початок завантаження даних.

Навіщо потрібен QUIC?



Плани команди розробників протоколу QUIC виглядають дуже амбітно: протокол спробує поєднати швидкість UDP з надійністю TCP.

Ось що про це пише Вікіпедія:

Поліпшення протоколу TCP є довготривалою метою для Google, а протокол QUIC створений як еквівалент незалежного TCP-з'єднання, але з меншими затримками і поліпшеною в дусі SPDY підтримкою мультиплексування. Якщо QUIC покаже свою ефективність, то ці можливості можуть увійти в наступну версію протоколів TCP і TLS (розробка яких займає більше часу).


В цій цитаті є важливий момент: якщо QUIC доведе свою ефективність, то є шанс, що випробувані в ньому ідеї стануть частиною наступної версії TCP.

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

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

Де ж сьогодні місце QUIC?

Якщо ви подивитеся на рівні, складові сучасне HTTPs-з'єднання, то побачите, що QUIC замінює собою весь TLS-стек і частина HTTP/2.

Так, протокол QUIC реалізує власний крипто-шар, що дозволяє уникнути використання TLS 1.2.

image

Поверх QUIC працює невеликий прошарок HTTP/2 API, використовувана для спілкування з віддаленими серверами. Вона менше повної реалізації HTTP/2, оскільки мультиплексування і установка з'єднання вже реалізовані в QUIC. Залишається лише реалізація протоколу HTTP.

Блокування початку рядка (Head-of-line blocking)

Протоколи SPDY і HTTP/2 використовують одне TCP-з'єднання з сервером замість окремих сполук для кожної сторінки. Це єдине з'єднання може бути використано для незалежних запитів та отримання окремих ресурсів.

image

Оскільки весь обмін даними тепер побудований на одному TCP-з'єднання, ми автоматично отримуємо один недолік: блокування початку рядка (Head-of-line blocking). У протоколі TCP потрібно, щоб пакети приходили (точніше оброблялися) в правильному порядку. Якщо пакет загубився на шляху до сервера — він повинен бути надісланий повторно. TCP-з'єднання в цей час має очікувати (блокуватися) і лише після повторного отримання втраченого пакету триває обробка всіх пакетів в черзі — тільки так можна дотримати умова коректного порядку обробки пакетів.

image

Протокол QUIC вирішує цю проблему фундаментально — відмовою від протоколу TCP на користь UDP, який не вимагає дотримання порядку обробки прийнятих пакетів. І, хоча втрати пакетів, звичайно, все так само можливі, це буде впливати тільки на обробку тих ресурсів (індивідуальних HTML\CSS\JS-файлів), до яких відноситься втрачений пакет.

image

QUIC дуже елегантно комбінує кращі частини SPDY\HTTP2 (мультиплексування) з неблокируемым транспортним протоколом.

Чому зменшити кількість пересилаються пакетів так важливо

Якщо у вас швидке Інтернет-з'єднання, то затримки передачі пакетів між вашим комп'ютером і віддаленим сервером становлять близько 10-50 мс. Кожен пересылаемый від вас по мережі пакет буде отримано сервером через цей проміжок часу. Для такого порядку величин переваги QUIC можуть бути не дуже зрозумілі. Але варто нам розглянути питання обміну даними з сервером на іншому континенті або використання мобільних мереж — і ось у нас вже з'являються затримки порядку 100-150 мс.

image

У підсумку на мобільному пристрої, при доступі знаходиться далеко сервера, різниця між 4 пакетами TCP+TLS і одним пакетом QUIC може скласти близько 300 мс, що вже є істотною величиною, спостерігається неозброєним оком.

Превентивна корекція помилок
Витонченою фичей протоколу QUIC є превентивна корекція помилок (Forward Error Correction, FEC). Кожен пересылаемый пакет містить в собі деяку кількість даних інших пакетів, що дозволяє реконструювати будь втрачений пакет з даними у його сусідів, без необхідності запитувати переотправку втраченого пакету і чекати його вмісту. Це, по суті, реалізація RAID 5 на мережному рівні.

Але ви вже й самі бачите недолік цього рішення: кожен пакет стає трохи більше. Поточна реалізація встановлює цей оверхед рівним 10%, тобто зробивши кожен пересылаемый пакет на 10% більше ми тим самим отримуємо можливість відновлення даних без перезапроса у разі, якщо буде губитися не більше кожного десятого пакета.

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

Відновлення сесії і паралельні завантаження

Ще однією цікавою особливістю використання протоколу UDP є те, що ви більше не прив'язані до IP сервера. У протоколі TCP з'єднання визначається чотирма параметрами: IP-адреси сервера і клієнта, портами сервера і клієнта. Linux ви можете перевірити ці параметри для кожного встановленого з'єднання за допомогою команди netstat:

$ netstat -anlp | grep ':443'
...
tcp6 0 0 2a03:a800:a1:1952::f:443 2604:a580:2:1::7:57940 TIME_WAIT -
tcp 0 0 31.193.180.217:443 81.82.98.95:59355 TIME_WAIT -
...


Якщо будь-який з цих чотирьох параметрів потрібно змінити — нам потрібно відкривати нове TCP-з'єднання. Ось чому важко підтримувати стабільний зв'язок на мобільних пристроях при перемиканні між WiFi і 3G/LTE.

image

В QUIC, з його використанням UDP, цього набору параметрів більше немає. QUIC вводить поняття ідентифікатора з'єднання, званого Connection UUID. З'являється можливість перейти з WiFi на LTE із збереженням Connection UUID, таким чином уникнувши витрат на нарощування з'єднання. Схожим чином працює Mosh Shell, зберігаючи SSH-з'єднання активним при зміні IP-адреси.

Також даний підхід відкриває двері можливості використання кількох джерел для запиту контенту. Якщо Connection UUID може бути використано для переходу від WiFi до мобільної мережі, то ми можемо, теоретично, використовувати і їх обидві одночасно для отримання даних паралельно. Більше каналів зв'язку — більше пропускна здатність.

Практичні реалізації QUIC

Браузер Chrome має експериментальну підтримку QUIC з 2014-го року. Якщо ви хочете потестувати QUIC, то можете включити його підтримку у Chrome і спробувати попрацювати з сервісами Google, які його підтримують. Це суттєва перевага Google — можливість використовувати комбінацію свого браузера і своїх веб-ресурсів. Включивши QUIC в самому популяром в світі браузері (Chrome) і високонавантажених сайтах (Youtube.com, Google.com), вони зможуть отримати більшу, наочну статистику використання протоколу, що дозволить виявити всі істотні проблеми практичного використання QUIC.

плагін для Chrome, який показує у вигляді іконки підтримку сервером протоколів HTTP/2 і QUIC.

Ви також можете побачити відкриті QUIC-з'єднання відкривши вкладку chrome://net-internals/#quic прямо зараз (зверніть увагу в таблиці на параметр Connection UUID, згаданий раніше)

image

Ви можете піти ще далі і переглянути всі відкриті з'єднання і всі передані за ним пакети: chrome://net-internals/#events&q=type:QUIC_SESSION%20is:active.

image

Як при цьому всьому працюють файрволы?

Якщо ви — сисадмін або мережевий інженер, то, можливо, злегка сіпнулися, коли почули про те, що QUIC використовує UDP замість TCP. Так, напевно, у вас є на те свої причини. Можливо у вас (як, наприклад, і у нас в компанії), налаштування доступу до веб-сервера виглядають так:

image

Найголовніше тут, звичайно ж, стовпчик протоколу, в якому явно написано «TCP». Подібні установки використовуються тисячами веб-серверів по всьому світу, оскільки вони розумні. 80 і 443 порти, тільки TCP — і більше нічого на продакшн-вебсервере дозволено бути не повинно. Ніякого UDP.

Ну, якщо ми хочемо використовувати QUIC, доведеться додати і дозвіл UDP-з'єднань на 443-ий порт. У великих ентерпрайз-мережах це може бути проблемою. Як показує статистика Google, UDP подекуди блокується:

image

Ці цифри були отримані в ході недавнього дослідження в Швеції. Відзначимо кілька ключових моментів:
  • Оскільки QUIC тестувався тільки з сервісами Google, можна припустити, що недоступності із-за невірно налаштованого файрвола на сервері не було.
  • Цифри відображають успішність вихідних запитів від користувачів на 443-ий порт UDP.
  • QUIC може бути відключений в Chrome з різних причин. Тримаю парі, що в деяких ентерпрайз-середовищах його відключили превентивно, просто на всяк випадок.
  • Оскільки протокол QUIC за замовчуванням використовує шифрування, нам слід турбуватися тільки про доступ до 443-му порту, доступність або недоступність 80-го не повинна впливати.


Перевага шифрування за замовчуванням в тому, що різні інструменти Deep Packet Inspection не можуть розшифрувати зашифровану інформацію і модифікувати дані, вони бачать бінарний потік і (хочеться вірити) просто пропускають його.

Використання QUIC на стороні сервера

На даний момент QUIC підтримується вебсервером Caddy (з версії 0.9). І клієнтська і серверна реалізація QUIC ще на стадії експериментальної підтримки, так що будьте обережні з практичним застосуванням QUIC. Оскільки ні у кого за замовчуванням не включений QUIC, то, ймовірно, буде безпечним включити його на своєму сервері і експериментувати зі своїм браузером (Оновлення з версії 52 QUIC включений за замовчуванням у Chrome).

Продуктивність QUIC

У 2015-му році Google опублікувала деякі результати вимірів продуктивності QUIC.

Як і очікувалося, QUIC затьмарює класичний TCP на поганих каналах зв'язку, даючи виграш в півсекунди на завантаження стартової сторінки www.google.com на 1% найбільш повільних з'єднань. Цей виграш ще більш помітний на відеосервісах зразок YouTube. Користувачі на 30% менше скаржилися на затримки з-за буферизації при перегляді відео при використанні QUIC.


Статистика Youtube особливо цікава. Якщо поліпшення подібного масштабу дійсно можливі, то ми побачимо дуже швидку адаптацію QUIC як мінімум у сфері відеосервісів зразок Vimeo, а також на ринку «відео для дорослих».

Висновки

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

Коментар до статті від Jim Roskind, одного з розробників QUIC


Я витратив багато років на дослідження, дизайн і розробку реалізації протоколу QUIC, і хотів би додати до статті деякі свої думки. У тексті було вірно помічено момент про ймовірну недоступності протоколу QUIC у деяких користувачів з-за суворих корпоративних політик щодо протоколу UDP. Це і було причиною того, що ми отримали середню доступність протоколу на рівні 93%.

Якщо ми повернемося трохи в минуле, то побачимо, що ще зовсім недавно корпоративні системи часто забороняли навіть вихідний трафік до 80-го порту, з аргументацією «це зменшить кількість часу, яку працівники витрачають на серфінг в збиток роботі». Пізніше, як ви знаєте, переваги доступу до веб-сайтів (у тому числі у виробничих цілях) змусило більшість корпорацій переглянути свої правила, дозволивши вихід в інтернет з робочого місця рядового співробітника. Я очікую чогось аналогічного і з протоколом QUIC: як тільки стане зрозуміло, що з новим протоколом зв'язок може бути швидше, завдання виконуються оперативніше — він проб'є собі шлях і в ентерпрайз.

Я розраховую, що QUIC масово замістить собою TCP, і це навіть крім того, що він подарує наступної версії TCP ряд своїх ідей. Справа в тому, що TCP реалізується в ядрах операційних систем, в залізі, а значить адаптація до нової версії може зайняти 5-15 років, в той час як впровадити QUIC поверх загальнодоступного і всіма підтримуваного UDP можна в окремо взятому продукті\сервісі буквально за кілька тижнів або місяців.


Більше інформації по темі:
Джерело: Хабрахабр

0 коментарів

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