Компактный обзор хода развития проекта — последних новостей о тестах и представленных имплементациях протокола. Интересующихся темой приглашаем под кат.
![/ Unsplash / Volodymyr Hryshchenko / Unsplash / Volodymyr Hryshchenko](https://habrastorage.org/getpro/habr/upload_files/f1c/2df/dd7/f1c2dfdd7e763ad99831874ec11b4273.jpeg)
Развитие проекта
QUIC разрабатывают с 2013 года, а с марта 2016-го — к процессу подключились и в IETF (Internet Engineering Task Force). На тот момент в протоколе, рассматриваемом в качестве замены TCP, обнаружили ряд недостатков: уязвимость перед DDoS-атаками, несовместимость с NAT, Anycast, ECMP; плюс — потенциальные сложности для работы сетевых администраторов и мониторинга.
Для укрепления слабых мест QUIC начали активнее внедрять и тестировать. Тогда этим занялись крупные телекомы и ИТ-компании, предложившие собственные имплементации протокола, а за последний год доля его «пользователей» от общего числа веб-сайтов практически удвоилась.
Кто тестирует
В конце прошлого года реализацию модуля для поддержки HTTP/3 в NGINX предложили в Cloudflare. Компания подготовила ее на основе своей библиотеки quiche, учитывающей IETF-спецификацию QUIC’а, и отметила, что действовала без участия инженеров и официальной поддержки от NGINX.
Практически ровно через полгода NGINX объявили о запуске собственной экспериментальной версии QUIC+HTTP/3 и подчеркнули, что этот проект не связан с тем, что был представлен ранее Cloudflare. Сейчас NGINX поддерживают специальный wiki-портал по этой теме, где есть гайды по настройке и ссылка на результаты тестирования различных клиентских и серверных имплементаций.
В одно время с Cloudflare тестовую сборку выпустила и Mozilla. Для Firefox она была подготовлена на основе neqo. С момента релиза прошло достаточно времени, но пока все еще можно увидеть критику ее быстродействия по сравнению с кастомной реализацией поддержки QUIC для Chrome.
За год были выпущены и другие версии — например, имплементация от Microsoft на основе msquic.
Что сейчас
На днях в Chromium Blog’е объявили о том, что компания распространит автоматическую поддержку с Google-QUIC еще и на IETF-QUIC. Эта редакция позволила добиться улучшения показателей основных сервисов компании — снизить задержку для поиска и время ребуферизации видео на 2% и 9% соотвественно, плюс — увеличить пропускную способность для мобильных и настольных платформ.
![/ Unsplash / Taylor Vick / Unsplash / Taylor Vick](https://habrastorage.org/getpro/habr/upload_files/765/882/ff5/765882ff58b5f07faf55362697e8207d.jpeg)
Релиз вызвал неоднозначную реакцию в IT-сообществе. Одни высказывались против чрезмерной централизации процесса разработки протокола, другие — не были впечатлены «незначительным» приростом производительности, третьи — выразили озабоченность общей сложностью QUIC.
Опасения, что «замена TCP дорого обойдется» с точки зрения распределения нагрузки, звучали и ранее. Но в ходе обсуждения проекта на HN резиденты даже вспомнили проект тридцатилетней давности под названием CORBA (Common Object Request Broker Architecture), указав на то, что от его чрезмерной сложности было гораздо больше «выхлопа» по сравнению с текущими новинками и их недостатками — например, неразрешенной неустойчивостью протокола к атакам с амплификацией.
Нельзя сказать, что обошлось без мнений в защиту. Но профильные издания все-таки отметили весомый факт — технически в Safari поддержка появилась еще раньше, с вводом 14-й версии.
Ближайший майлстоун
Рабочая группа по QUIC завершает сбор обратной связи, обсуждение различных аспектов работы протокола и готовится к принятию соответствующего стандарта. С какой интенсивностью и эффективностью пойдет его дальнейшее внедрение — покажут ближайшие несколько месяцев.
P.S. Дополнительное чтение в нашем хабраблоге:
Работа провайдеров и развитие систем связи (подборка)