Нощните и бета версиите на Firefox включват поддръжка за HTTP/3 протокола по подразбиране. В стабилния клон включването на HTTP/3 е планирано за пускането на Firefox 88, планирано за 20 април. Chrome започна селективно да активира HTTP/3 през октомври 2020 г.
Поддръжката на HTTP/3 във Firefox е базирана на проекта neqo на Mozilla, който предоставя клиентска имплементация и сървър за протокола QUIC. Кодът за компонентите, поддържащи HTTP/3 и QUIC, е написан на Rust. За да активирате HTTP/3, опцията "network.http.http3.enabled" е налична в about:config. Експериментална поддръжка на HTTP/3 също е добавена към Chrome и curl за клиентски софтуер, и сървъри Предлага се в Nginx, както и като Nginx модул и тестов сървър от Cloudflare. Стартирани са няколко тестови сайта за тестване на функционалността на HTTP/3 клиента.
Протоколът HTTP/3 все още е на етап проект на спецификация и все още не е напълно стандартизиран от IETF. HTTP/3 дефинира използването на протокола QUIC като транспорт за HTTP/2. Протоколът QUIC (Quick UDP Internet Connections) е разработен от Google от 2013 г. като алтернатива на комбинацията TCP+TLS за мрежата, като решава проблеми с дълги времена за настройка и преговори за връзки в TCP и елиминира закъснения при загуба на пакети по време на данни трансфер. QUIC е разширение на UDP протокола, което поддържа мултиплексиране на множество връзки и предоставя методи за криптиране, еквивалентни на TLS/SSL. По време на разработването на стандарта IETF бяха направени промени в протокола, което доведе до появата на два паралелни клона, единият за HTTP/3, а вторият поддържан от Google (Chrome поддържа и двете опции).
Основни характеристики на QUIC:
- Висока сигурност, подобна на TLS (всъщност QUIC предоставя възможност за използване на TLS през UDP);
- Контрол на целостта на потока за предотвратяване на загуба на пакети;
- Възможност за незабавно установяване на връзка (0-RTT, в около 75% от случаите данните могат да бъдат предадени веднага след изпращане на пакет за настройка на връзка) и осигуряване на минимални закъснения между изпращане на заявка и получаване на отговор (RTT, Round Trip Time) ;
- Използване на различен пореден номер при повторно предаване на пакет, което избягва двусмислието при идентифицирането на получените пакети и премахва изчакванията;
- Загубата на пакет засяга само доставката на свързания с нея поток и не спира доставката на данни в потоци, предавани паралелно през текущата връзка;
- Инструменти за коригиране на грешки, които минимизират закъсненията поради повторно предаване на изгубени пакети. Използване на специални кодове за коригиране на грешки на ниво пакет, за да се намалят ситуациите, които изискват повторно предаване на изгубени пакети данни.
- Границите на криптографските блокове са подравнени с границите на QUIC пакетите, което намалява влиянието на загубата на пакети върху декодирането на съдържанието на следващите пакети;
- Няма проблеми с блокирането на TCP опашката;
- Поддръжка на Connection ID за намаляване на времето за повторно свързване за мобилни клиенти;
- Възможност за свързване на усъвършенствани механизми за контрол на претоварването на връзката;
- Използване на техники за предсказване на честотната лента във всяка посока, за да се осигури оптимална интензивност на изпращане на пакети, предотвратяване на преминаване в състояние на задръстване, при което има загуба на пакети;
- Забележимо увеличение на производителността и пропускателната способност в сравнение с TCP. За видео услуги като YouTube е доказано, че QUIC намалява операциите за повторно буфериране при гледане на видеоклипове с 30%.
Източник: opennet.ru
