Комітет IETF (Internet Engineering Task Force), що займається розвитком протоколів та архітектури інтернету, завершив формування RFC для протоколу QUIC і опублікував пов'язані з ним специфікації під ідентифікаторами RFC 8999 (незалежні від версії якості протоколу), RFC 9000 (транспорт над UDP9001, RFC) (TLS-шифрування каналу зв'язку QUIC) та RFC 9002 (управління перевантаженням та визначення втрати пакетів при передачі даних).
RFC отримали статус «Запропонованого стандарту», після чого розпочнеться робота з надання RFC статусу чорнового стандарту (Draft Standard), що фактично означає повну стабілізацію протоколу та облік усіх висловлених зауважень. Протокол HTTP/3, який визначає використання протоколу QUIC як транспорт для HTTP/2, поки що знаходиться на стадії чорнової специфікації, але найближчим часом і він буде остаточно стандартизований в IETF.
Очікується, що стандартизація QUIC дасть поштовх для ширшого впровадження даного протоколу, а також для розвитку заснованих на ньому розширень, таких як WebTransport (технологія для надсилання та прийому даних між браузером та сервером) та MASQUE (технологія проксування з'єднань, що розширює можливості SOCKS та HTTP CONNECT, та використовуюча HTTPS поверх QUIC як транспорт).
Нагадаємо, що протокол QUIC (Quick UDP Internet Connections) з 2013 року розвивається компанією Google як альтернатива зв'язці TCP+TLS для Web, що вирішує проблеми з великим часом встановлення та узгодження з'єднань у TCP та усуває затримки при втраті пакетів у процесі передачі даних. QUIC є надбудовою над протоколом UDP, що підтримує мультиплексування декількох з'єднань і забезпечує методи шифрування, еквівалентні TLS/SSL. У процесі розробки в IETF стандарту в протокол були внесені зміни, що призвело до виникнення двох паралельно існуючих гілок, одна для HTTP/3, а друга підтримується Google (Chrome підтримує обидва варіанти, а Firefox варіант IETF).
Основні особливості QUIC:
- Висока безпека, аналогічна TLS (насправді QUIC надає можливість використання TLS поверх UDP);
- Контроль за цілісністю потоку, що запобігає втраті пакетів;
- Можливість миттєво встановити з'єднання (0-RTT, приблизно в 75% випадків дані можна передавати відразу після відправки пакета установки з'єднання) та забезпечити мінімальні затримки між відправкою запиту та отриманням відповіді (RTT, Round Trip Time);
- Використання при повторній передачі пакета іншого номера послідовності, що дозволяє уникнути двозначності щодо отриманих пакетів і позбутися таймаутів;
- Втрата пакета впливає на доставку тільки пов'язаного з ним потоку і не зупиняє доставку даних паралельно передаються через поточне з'єднання потоках;
- Засоби корекції помилок, які мінімізують затримки через повторну передачу втрачених пакетів. Використання спеціальних кодів корекції помилок на рівні пакета для скорочення ситуацій, що вимагають повторної передачі даних втраченого пакета.
- Кордони криптографічних блоків вирівняні з межами пакетів QUIC, що зменшує вплив втрат пакетів на декодування вмісту наступних пакетів;
- Відсутність проблем із блокуванням черги TCP;
- Підтримка ідентифікатора з'єднання, що дозволяє скоротити час встановлення повторного з'єднання для мобільних клієнтів;
- Можливість підключення розширених механізмів контролю навантаження з'єднання;
- Використання техніки прогнозування пропускної спроможності в кожному напрямку для забезпечення оптимальної інтенсивності відправлення пакетів, запобігаючи скоченню в стан навантаження, при якому спостерігається втрата пакетів;
- Помітний приріст продуктивності та пропускної спроможності в порівнянні з TCP. Для відеосервісів, таких як YouTube, застосування QUIC показало скорочення операцій повторної буферизації під час перегляду відео на 30%.
Джерело: opennet.ru