Chrome додава експериментална поддршка за протоколот HTTP/3

До експериментални градби Хром Канари додадена поддршка за протоколот HTTP/3, кој имплементира додаток за да овозможи HTTP да работи преку протоколот QUIC. Самиот протокол QUIC беше додаден на прелистувачот пред пет години и оттогаш се користи за оптимизирање на работата со услугите на Google. Во исто време, верзијата QUIC од Google што се користи во Chrome се разликуваше во некои детали од верзијата од спецификации IETF, но сега имплементациите се синхронизирани.

HTTP/3 ја стандардизира употребата на QUIC како транспорт за HTTP/2. За да се овозможи HTTP/3 и QUIC опција од 23 нацрти Спецификациите на IETF бараат Chrome да се стартува со опциите „-enable-quic -quic-version=h3-23“, а потоа при отворање на тест-страницата брзо.карпи:4433 Во режимот за проверка на мрежата во алатките за програмери, активноста на HTTP/3 ќе се прикаже како „http/2+quic/99“.

Потсетиме дека протоколот QUIC (Quick UDP Internet Connections) е развиен од Google од 2013 година како алтернатива на комбинацијата TCP+TLS за веб, решавајќи проблеми со долгото поставување и преговарање за конекции во TCP и елиминирање на одложувањата кога пакетите се губат при пренос на податоци. QUIC е продолжување на протоколот UDP што поддржува мултиплексирање на повеќе врски и обезбедува методи за шифрирање еквивалентни на TLS/SSL. Протоколот за кој станува збор е веќе интегриран во серверската инфраструктура на Google и е дел од Chrome. планирано за вклучување во Firefox и активно се користи за опслужување на барањата на клиентите на серверите на Google.

Главните Карактеристики QUIC:

• Висока безбедност слична на TLS (во суштина QUIC обезбедува можност за користење на TLS преку UDP);
• Контрола на интегритетот на протокот, спречување на загуба на пакети;
• Способност за моментално воспоставување врска (0-RTT, приближно во 75% од случаите податоците може да се пренесат веднаш по испраќањето на пакетот за поставување конекција) и да се обезбедат минимални доцнења помеѓу испраќањето барање и примањето одговор (RTT, време на повратен пат);
• Некористење на истиот секвенциски број при реемитување пакет, со што се избегнува двосмисленост во идентификувањето на примените пакети и се ослободува од тајмаутите;
• Губењето на пакетот влијае само на испораката на протокот поврзан со него и не ја запира испораката на податоци во паралелни текови што се пренесуваат преку тековната врска;
• Карактеристики за корекција на грешки кои ги минимизираат одложувањата поради реемитување на изгубени пакети. Употреба на специјални шифри за корекција на грешки на ниво на пакет за да се намалат ситуациите кои бараат повторно пренос на изгубени податоци за пакети.
• Границите на криптографските блокови се усогласени со границите на пакетите QUIC, што го намалува влијанието на загубите на пакетите врз декодирањето на содржината на следните пакети;
• Нема проблеми со блокирање на редот на TCP;
• Поддршка за идентификатор за конекција, што го намалува времето потребно за воспоставување повторно поврзување за мобилните клиенти;
• Можност за поврзување напредни механизми за контрола на застојот на приклучокот;
• Користи техники за прогнозирање на пропусната моќ по насока за да се осигура дека пакетите се испраќаат со оптимални стапки, спречувајќи ги да станат преоптоварени и да предизвикаат загуба на пакети;
• Воочливо раст перформанси и пропусната моќ во споредба со TCP. За видео-услугите како YouTube, QUIC се покажа дека ги намалува операциите за ребаферирање при гледање видеа за 30%.

Извор: opennet.ru