HTTP/3.0 доби предложен стандарден статус

IETF (Internet Engineering Task Force), која е одговорна за развојот на интернет протоколи и архитектура, го заврши формирањето на RFC за протоколот HTTP/3.0 и објави сродни спецификации под идентификаторите RFC 9114 (протокол) и RFC 9204 ( QPACK технологија за компресија на заглавието за HTTP/3) . Спецификацијата HTTP/3.0 доби статус на „Предлог стандард“, по што ќе започне работата за да се даде статус на нацрт стандард на RFC (Draft Standard), што всушност значи целосна стабилизација на протоколот и земајќи ги предвид сите дадените коментари. Во исто време, беа објавени ажурирани верзии на спецификациите за протоколите HTTP/1.1 (RFC 9112) и HTTP/2.0 (RFC 9113), како и документи што ја дефинираат семантиката на HTTP барањата (RFC 9110) и заглавијата за контрола на кеширање HTTP (RFC 9111).

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

HTTP/3.0 доби предложен стандарден статус

Во моментов, поддршката за QUIC и HTTP/3.0 е веќе имплементирана во сите популарни веб-прелистувачи (во Chrome, Firefox и Edge, поддршката за HTTP/3 е стандардно овозможена, а во Safari бара поставката „Advanced > Experimental Features > HTTP/3“ да се овозможи). На страната на серверот, имплементациите на HTTP/3 се достапни за nginx (во посебна гранка и во форма на посебен модул), Caddy, IIS и LiteSpeed. Поддршката за HTTP/3 ја обезбедува и мрежата за испорака на содржина во Cloudflare.

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

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

Меѓу промените во спецификацијата HTTP/1.1, може да се забележи забраната за изолирана употреба на знакот за враќање на превозот (CR) надвор од телото со содржина, т.е. Во елементите на протоколот, знакот CR може да се користи само заедно со знакот за довод на линија (CRLF). Алгоритмот за распоред на поделени барања е подобрен за да се поедностави одвојувањето на приложените полиња и делови со заглавија. Додадени се препораки за ракување со двосмислена содржина за блокирање на нападите „Шверц на барање HTTP“, кои ни овозможуваат да се заглавиме во содржината на барањата на другите корисници во протокот помеѓу предниот дел и задниот дел.

Ажурирањето на спецификациите HTTP/2.0 експлицитно ја дефинира поддршката за TLS 1.3. Застарена шемата за одредување приоритети и поврзаните полиња за заглавие. Неискористениот механизам за ажурирање на врската со HTTP/1.1 е прогласен за застарен. Намалени барања за проверка на имињата и вредностите на полињата. Некои претходно резервирани типови и параметри на рамки се предложени за употреба. Попрецизно се дефинирани забранетите полиња за заглавие поврзани со врската.

Извор: opennet.ru

Додадете коментар