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