Chrome добавя експериментална поддръжка за HTTP/3 протокол

Към експериментални компилации Chrome Canary добави поддръжка за протокола 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“ и след това при отваряне на тестовия сайт quick.rocks: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, Round Trip Time) ;
• Не използвайте същия пореден номер при повторно предаване на пакет, което ви позволява да избегнете двусмислието при определяне на получените пакети и да се отървете от изчакванията;
• Загубата на пакет засяга само доставката на свързания с нея поток и не спира доставката на данни в потоци, предавани паралелно през текущата връзка;
• Инструменти за коригиране на грешки, които минимизират закъсненията поради повторно предаване на изгубени пакети. Използване на специални кодове за коригиране на грешки на ниво пакет, за да се намалят ситуациите, които изискват повторно предаване на изгубени пакети данни.
• Границите на криптографските блокове са подравнени с границите на QUIC пакетите, което намалява влиянието на загубата на пакети върху декодирането на съдържанието на следващите пакети;
• Няма проблеми с блокирането на TCP опашката;
• Поддръжка на Connection ID за намаляване на времето за повторно свързване за мобилни клиенти;
• Възможност за свързване на усъвършенствани механизми за контрол на претоварването на връзката;
• Използване на техники за предсказване на честотната лента във всяка посока, за да се осигури оптимална интензивност на изпращане на пакети, предотвратяване на преминаване в състояние на задръстване, при което има загуба на пакети;
• Доловимо растеж производителност и пропускателна способност в сравнение с TCP. За видео услуги като YouTube е показано, че QUIC намалява операциите за повторно буфериране на видео с 30%.

Източник: opennet.ru