Comments 12
В России под «обходом блокировок» понимается предоставление публичных VPN-сервисов для доступа к запрещенным ресурсам. Речь в статье решает иную задачу - оптимизацию корпоративных сетей и трафика между дата-центрами и филиалами, аналогично тому, как SD-WAN-решения Cisco, Huawei или VMware работают поверх Интернета.
При использовании стандартных протоколов (QUIC, MASQUE, BBRv3) строго в рамках корпоративных сценариев, без функции обхода фильтрации. То есть речь идет не о VPN-сервисе, а о сетевом ускорителе и транспортном уровне для легальных бизнес-соединений, которые не попадают под санкции со стороны России и ЕС.
Толковый материал, есть что почерпнуть - спасибо !
Тестировал haproxy 3.2 с quic (сборка из исходника) и получил результат хуже tcp грузил через iperf, тестировал с quic-cc-algo bbr и без в самом ha, разница есть и большая но tcp оказался быстрее.. нагрузка на сервер существенная.
Да, результаты HAProxy 3.2 с QUIC могут быть ниже TCP, это ожидаемо: реализация QUIC в HAProxy пока не оптимизирована по zero-copy и pacing. Мы в CloudBridge видели похожее: CPU-нагрузка выше на 20–30 %, особенно без GRO/GSO и при использовании стандартного BBR (без v3-патчей). После внедрения BBRv3 + FEC + оптимизированного pacing goodput стабилизировался и обошёл TCP примерно на 10 % при 3–5 % потерь.
По этому в какой то степени считаю рано ещё внедрять QUIC в обиход если ты не отдаёшь контент как VK YouTube и тд. Пока websocket/grpc справляется не вижу смысла в рядовых случаях использовать QUIC.
Провел тестирование с разной мощностью железа от 1 ядра 1озу как на самой простой vps до 16ядер, результаты все равно остались неудовлетворительными. Тестов с bbrv3 не проводил, был интересен тест именно как говориться из коробки, сначала ubuntu24 была сборка openssl3.5+quic и haproxy 3.2 потом debian13 с openssl3.5 из коробки, ещё протестировал docker haproxy3.2 его тоже нужно собрать с quic образ Trixie:slim, и результаты ожидаемо несколько хуже.
из коробки, QUIC пока часто проигрывает TCP: реализация в HAProxy 3.2 и OpenSSL QUIC ещё не оптимизирована, нет zero-copy, pacing в user-space создаёт высокий CPU overhead. Я наблюдал то же самое, пока не включил BBRv3 + FEC + корректный pacing: тогда jitter стабилизировался < 1 мс, а goodput вырос примерно на 10 % при 5 % потерь (RU↔EU трассы).
Так что для классического веб-трафика ты прав, WebSocket/grpc хватает, но для межрегиональных каналов и SD-WAN-сценариев QUIC уже выигрывает по стабильности и адаптивности.
Межрегиональных каналов у меня нет, есть сервисы с данными в реальном времени там websocket в основном, хотел обновить стек, добавить quic, а на выходе оверхэд, времени разбираться нет, а тут попалась статья от вас толковая есть над чем подумать. Основной целью было бесшовное переключение между сетями без разрыва соединения и потом уже ускорение работы, первый пункт то удался, но с оверхедом. + карма
BBRv3, FEC и QUIC: как мы удержали jitter <1 мс и стабилизировали RU<->EU