WebSocket и WebTransport и для ряда задач это действительно удобная схема, но у WSS есть и обратная сторона: он все-таки работает поверх TCP, что значит head-of-line blocking, ретраи, дополнительные очереди и дрожание RTT при плохой сети. Для прокси и легкого транспорта это терпимо, но для IP-туннеля под реальное время, иногда ограничивает.
MASQUE здесь интересен тем, что он дает тот же «видимый» HTTPS-трафик, но при этом сохраняет свойства QUIC: datagram-передачу без перепосылок, быстрое переподключение, нормальную работу под плавающим jitter и возможность migration без разрыва.
Со стороны, это действительно так выглядит :) но на практике люди нередко оказываются в ситуациях, где UDP либо режется, либо нестабилен, либо просто запрещён корпоративной политикой. И тогда единственный рабочий вариант, именно TCP.
в России ситуация с QUIC местами непростая: где-то работает стабильно, где-то действительно чувствуется ограничение UDP. Поэтому я и делаю эти исследования, хочется понять, как протокол ведёт себя в реальных российских сетях, где он устойчив, а где требует обходных механизмов или fallback. Пока результаты разные, но точно не нулевые, QUIC во многих сетях остаётся рабочим. Если есть свои наблюдения, буду рад услышать/прочитать.
Коллега! Вы безусловно правы. На данный момент ML только скотчем можно примотать в такой сфере применения. Данная статья, это исследование, а не призыв к перевороту сетевой индустрии. Как и любое исследование строиться на гипотезах и экспериментов. Буду рад, если поддержите статью и проект с этой точки зрения.
Спасибо за комментарий! На наших трассах, особенно межрегиональных и RU↔EU, BBRv3 обычно работает лучше, чем CUBIC: он стабильнее держит скорость при плавающих потерях и джиттере и быстрее восстанавливается после деградаций. Поэтому поверх QUIC он даёт заметный выигрыш в качестве канала.
Cloudflare тоже по этой причине уходит от WireGuard в сторону MASQUE/QUIC: такой стек лучше переносит нестабильные каналы, handover и временные разрывы, чем классический UDP-VPN.
Данная статья не рекламная, это приглашение объединить экспертизу. Сети становятся лучше там, где инженеры и университеты работают вместе. Это делает и инфраструктуру, и страну сильнее.
Буду благодарен поддержке. Заранее спасибо за понимание.
из коробки, 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 уже выигрывает по стабильности и адаптивности.
Да, результаты 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 % потерь.
В России под «обходом блокировок» понимается предоставление публичных VPN-сервисов для доступа к запрещенным ресурсам. Речь в статье решает иную задачу - оптимизацию корпоративных сетей и трафика между дата-центрами и филиалами, аналогично тому, как SD-WAN-решения Cisco, Huawei или VMware работают поверх Интернета. При использовании стандартных протоколов (QUIC, MASQUE, BBRv3) строго в рамках корпоративных сценариев, без функции обхода фильтрации. То есть речь идет не о VPN-сервисе, а о сетевом ускорителе и транспортном уровне для легальных бизнес-соединений, которые не попадают под санкции со стороны России и ЕС.
WebSocket и WebTransport и для ряда задач это действительно удобная схема, но у WSS есть и обратная сторона: он все-таки работает поверх TCP, что значит head-of-line blocking, ретраи, дополнительные очереди и дрожание RTT при плохой сети. Для прокси и легкого транспорта это терпимо, но для IP-туннеля под реальное время, иногда ограничивает.
MASQUE здесь интересен тем, что он дает тот же «видимый» HTTPS-трафик, но при этом сохраняет свойства QUIC: datagram-передачу без перепосылок, быстрое переподключение, нормальную работу под плавающим jitter и возможность migration без разрыва.
По разный случай свой рецепт :)
Со стороны, это действительно так выглядит :) но на практике люди нередко оказываются в ситуациях, где UDP либо режется, либо нестабилен, либо просто запрещён корпоративной политикой. И тогда единственный рабочий вариант, именно TCP.
Спасибо за поддержку, очень мотивирует продолжать копать дальше :)
в России ситуация с QUIC местами непростая: где-то работает стабильно, где-то действительно чувствуется ограничение UDP. Поэтому я и делаю эти исследования, хочется понять, как протокол ведёт себя в реальных российских сетях, где он устойчив, а где требует обходных механизмов или fallback. Пока результаты разные, но точно не нулевые, QUIC во многих сетях остаётся рабочим. Если есть свои наблюдения, буду рад услышать/прочитать.
Коллега! Вы безусловно правы. На данный момент ML только скотчем можно примотать в такой сфере применения. Данная статья, это исследование, а не призыв к перевороту сетевой индустрии. Как и любое исследование строиться на гипотезах и экспериментов. Буду рад, если поддержите статью и проект с этой точки зрения.
Интересный проект, только мало информации на сайте, вместо лейдинга рекомендую сделать полноценный сайт: новости, партнеры, документация и тд.
Спасибо, познавательная статья
Спасибо за комментарий! На наших трассах, особенно межрегиональных и RU↔EU, BBRv3 обычно работает лучше, чем CUBIC: он стабильнее держит скорость при плавающих потерях и джиттере и быстрее восстанавливается после деградаций. Поэтому поверх QUIC он даёт заметный выигрыш в качестве канала.
Cloudflare тоже по этой причине уходит от WireGuard в сторону MASQUE/QUIC: такой стек лучше переносит нестабильные каналы, handover и временные разрывы, чем классический UDP-VPN.
Данная статья не рекламная, это приглашение объединить экспертизу. Сети становятся лучше там, где инженеры и университеты работают вместе. Это делает и инфраструктуру, и страну сильнее.
Буду благодарен поддержке. Заранее спасибо за понимание.
Спасибо за беседу. Приятно иметь дело с единомышленниками
из коробки, 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 уже выигрывает по стабильности и адаптивности.
Да, результаты 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 % потерь.
На Хабре обычно аудитория сама отличает “VPN для обхода” от “SD-WAN уровня транспорта”. Не вижу смысла продолжать беседу.
В России под «обходом блокировок» понимается предоставление публичных VPN-сервисов для доступа к запрещенным ресурсам. Речь в статье решает иную задачу - оптимизацию корпоративных сетей и трафика между дата-центрами и филиалами, аналогично тому, как SD-WAN-решения Cisco, Huawei или VMware работают поверх Интернета.
При использовании стандартных протоколов (QUIC, MASQUE, BBRv3) строго в рамках корпоративных сценариев, без функции обхода фильтрации. То есть речь идет не о VPN-сервисе, а о сетевом ускорителе и транспортном уровне для легальных бизнес-соединений, которые не попадают под санкции со стороны России и ЕС.
yandex.ru/legal/cloud_termsofuse/?lang=ru#index__section_hq4_3cp_1fb