Comments 20
Я проводил тесты и на реальном 2g/3g соединении у меня http2 показывал себя лучше, чем http3. На 4g уже выигрывал http3. Но это было давно, возможно, уже всё изменилось. Это не то, что хотелось - добивать тех, у кого и так всё плохо.
Кто-нибудь проводил тесты недавно?
Протестируйте ваш браузер: https://quic.nginx.org/quic.html
Фаерфокс смог, хромиум не смог. В хромиуме нужно руками включать через командную строку: --enable-quic. Микрософтовский edge смог сразу.
A интересно, роскомпозор quic умеет?
Честно говоря, мне непонятно одно. Протокол требует, чтоб UDP-пакеты ходили по всей сети, в сегментах с серыми адресами и адреса правильно транслировались. И если в TCP эта задача решена, в частности, тем что роутер видит FIN и выкидывает после этого трансляцию, то с UDP получаются за некоторое время таблицы NAT забьются давно разорванными соединениями и порты кончатся. Или роутер должен анализировать протокол (он же шифрованный?) и понимать, когда там какой-то аналог FIN случился?
Насколько я себе это представляю, то роутеры только по таймауту могут сессию UDP удалить. И часто они делают это очень быстро, даже слишком.
Например, у меня на роутере настроена трансляция адресов таким образом, что все левые пакеты извне летят на специальную виртуалку. И часто происходит так, что ответы от ДНС-серверов улетают на эту виртуалку, хотя запросы были с другого устройства в сети.
A интересно, роскомпозор quic умеет?Нет, они его блокируют, вероятно, потому что фильтрация сопряжена со значительными затратами ресурсов или невозможна для них.
Google Chrome у меня смог, а Firefox нет. Но у меня нехорошее предчувствие. Ростелеком так заботится о моей безопасности, что полностью перекрыл входящие соединения по IPv6. Тестирование идёт с сервером по IPv4. А если будет IPv6, то, скорее всего, я не получу никаких ответов, потому что UDP не пройдёт. Проходит в мою сторону только обратный поток для TCP.
Основной недостаток QUIC - это то, что в РФ он сплошь и рядом заблочен.
Несколько лет назад, году в 2018-2019, был подключен последней милей через радиоканал, всё работало стабильно, тот же speedtest почти выдавал положенные 100мбит/c, плюс адекватные пинги, без просадок, но в какой-то момент начались большие проблемы с видео на youtube. Видео могло начать загружаться после N-ного количества обновлений страницы, постоянно останавливалось на буферизации, по несколько раз в минуту, ад был в общем. И хроме и в ФФ, без разницы. Хотя в это же время с RDP через UDP до рабочих серверов вообще никаких проблем не было,
В итоге выключил в ФФ поддержку quic, и всё сразу нормализовалось.
FIVO все таки FIFO ?
"...но поскольку он построен на UDP, который не ориентирован на связь.."
"Поскольку QUIC подключается клиент и сервер одним соединением..."
"...быстрее обрабатывать восполнение хвостовых задержек..."
И такого
"В TCP также используется TLS,..."
В TCP нигде не используется TLS , TCP о нём ничего не знает.
"Это мой первый пост, рад любой критике."
Покритикую. Прежде, чем публиковать статью, сначала её надо несколько раз перечитать самому, чтобы привести в порядок орфографию, грамматику ( желательно и стилистику тоже), перепроверить смысл написанного в каждом абзаце. Затем отложить хотя бы на день и на свежую голову перечитать заново. Если ничего больше не режет глаз, то тогда уже публиковать. А из-за множества ляпов ценность статьи падает.
И в дополнение к упомянутым недостаткам можно упомянуть:
Повышенную утилизацию cpu из-за обязательности шифрования
реализация только в userspace. В ядре Линукса - неизвестно, когда (насколько понимаю)
таймауты для UDP на промежуточных устройствах ( FW, к примеру) обычно гораздо более агрессивные, чем для TCP, это может негативно влиять на сессии quic-а
Quic от Google