Работната група за интернет инженерство (IETF), која е одговорна за развојот на интернет протоколи и архитектура, го финализираше RFC за протоколот QUIC и ги објави сродните спецификации под идентификаторите RFC 8999 (својства на протокол независни од верзијата), RFC 9000 (транспорт преку UDP), RFC 9001 (TLS шифрирање на комуникацискиот канал QUIC) и RFC 9002 (контрола на застојот и откривање на загуба на пакети при пренос на податоци).
РФЦ добија статус на „Предлог стандард“, по што ќе почне да се работи за да се добие статус на нацрт стандард на RFC (Нацрт стандард), што всушност значи целосно стабилизирање на протоколот и земајќи ги предвид сите дадени коментари. Протоколот HTTP/3, кој ја дефинира употребата на протоколот QUIC како транспорт за HTTP/2, сè уште е во фаза на нацрт спецификација, но наскоро конечно ќе биде стандардизиран од IETF.
Се очекува стандардизацијата на QUIC да даде поттик за пошироко усвојување на овој протокол, како и развој на екстензии засновани на него, како што е WebTransport (технологија за испраќање и примање податоци помеѓу прелистувач и сервер) и MASQUE (технологија за прокси за поврзување што ги проширува можностите на SOCKS и HTTP CONNECT и користење HTTPS преку QUIC како транспорт).
Да потсетиме дека протоколот QUIC (Quick UDP Internet Connections) е развиен од Google од 2013 година како алтернатива на комбинацијата TCP+TLS за веб, решавајќи ги проблемите со долгото поставување и времето на преговарање на врските во TCP и елиминирајќи ги одложувањата кога пакетите се губат при пренос на податоци. QUIC е продолжување на протоколот UDP што поддржува мултиплексирање на повеќе врски и обезбедува методи за шифрирање еквивалентни на TLS/SSL. За време на развојот на стандардот IETF, беа направени промени во протоколот, што доведе до појава на две паралелни гранки, едната за HTTP/3, а втората поддржана од Google (Chrome ги поддржува двете опции, а Firefox ја поддржува верзијата IETF). .
Главни карактеристики на QUIC:
- Висока безбедност слична на TLS (во суштина QUIC обезбедува можност за користење на TLS преку UDP);
- Контрола на интегритетот на протокот, спречување на загуба на пакети;
- Способност за моментално воспоставување врска (0-RTT, во приближно 75% од случаите податоците може да се пренесат веднаш по испраќањето на пакетот за поставување конекција) и да се обезбедат минимални доцнења помеѓу испраќањето барање и примањето одговор (RTT, време на повратен пат);
- Користење на различен редоследен број при реемитување на пакет, со што се избегнува нејаснотија во идентификувањето на примените пакети и се ослободува од тајмаутите;
- Губењето на пакетот влијае само на испораката на протокот поврзан со него и не ја запира испораката на податоци во паралелни текови што се пренесуваат преку тековната врска;
- Карактеристики за корекција на грешки кои ги минимизираат одложувањата поради реемитување на изгубени пакети. Употреба на специјални шифри за корекција на грешки на ниво на пакет за да се намалат ситуациите кои бараат повторно пренос на изгубени податоци за пакети.
- Границите на криптографските блокови се усогласени со границите на пакетите QUIC, што го намалува влијанието на загубите на пакетите врз декодирањето на содржината на следните пакети;
- Нема проблеми со блокирање на редот на TCP;
- Поддршка за идентификатор за конекција, што го намалува времето потребно за воспоставување повторно поврзување за мобилните клиенти;
- Можност за поврзување напредни механизми за контрола на застојот на приклучокот;
- Користи техники за прогнозирање на пропусната моќ по насока за да се осигура дека пакетите се испраќаат со оптимални стапки, спречувајќи ги да станат преоптоварени и да предизвикаат загуба на пакети;
- Значително зголемување на перформансите и пропусната моќ во споредба со TCP. За видео-услугите како YouTube, QUIC се покажа дека ги намалува операциите за ребаферирање при гледање видеа за 30%.
Извор: opennet.ru