UDP и QUIC через прокси
Прокси может успешно пройти проверку веб-запросом и при этом не передавать трафик, который нужен вашей программе. Например, игра входит в аккаунт через прокси, но не может обмениваться данными во время матча. Сайт открывается как обычно, однако браузер использует HTTP/2 вместо HTTP/3. Для этих операций нужны разные сетевые возможности.
Общий выбор протокола разобран в статье «SOCKS- и HTTP-прокси». Здесь рассмотрим, как UDP проходит через прокси к адресату, что требуется для работы QUIC и как проверить, что программа использует нужный транспорт и выходной IP.
За что отвечают UDP, QUIC и HTTP/3
TCP доставляет упорядоченный поток байтов. Если часть данных потерялась, он организует повторную передачу и не отдаёт приложению следующие байты, пока пропуск не заполнен. UDP отправляет отдельные сообщения — датаграммы. Сам UDP не гарантирует доставку, порядок и защиту от дубликатов; программа, которая его использует, определяет, как поступать в таких ситуациях.
Это позволяет приложениям выбирать подходящее поведение. Программа голосовой связи может отбросить звуковой пакет, который пришёл слишком поздно для воспроизведения. Игре может быть полезнее свежее положение игрока, чем прежнее. DNS-обмен может состоять из короткого вопроса и ответа. Конкретный транспорт зависит от программы: эти примеры не означают, что каждый звонок, игра или DNS-запрос использует UDP.
QUIC — транспортный протокол, работающий поверх UDP. Он добавляет установление соединения, восстановление потерянных данных, управление перегрузкой и надёжные потоки. Файл, переданный по надёжному потоку QUIC, может прийти полностью и в правильном порядке. То, что пакеты находятся внутри UDP-датаграмм, не отменяет надёжность, которую обеспечивает QUIC.
Кроме того, QUIC позволяет нескольким потокам использовать одно соединение. Если данные одного потока потерялись, другие потоки, чьи данные уже пришли, могут продолжать работу. Это может сократить ожидание по сравнению с передачей всех потоков через одно упорядоченное TCP-соединение. Результат всё равно зависит от маршрута, потерь, сервера и клиента: сам выбор QUIC не гарантирует ускорения программы.
HTTP/3 передаёт HTTP поверх QUIC. HTTP/1.1 и HTTP/2 обычно используют TCP. Все три версии могут обслуживать HTTPS-сайт, поэтому префикс https:// в адресе не определяет версию HTTP и не подтверждает использование UDP.
Шифрование — отдельное свойство. UDP не шифрует данные. QUIC использует TLS 1.3 для установления защиты трафика приложения. Другая программа, работающая через UDP, может применять иной механизм защиты или передавать содержимое без шифрования; пересылка через прокси сама по себе эту защиту не добавляет.
Как SOCKS5 передаёт UDP
SOCKS5 предусматривает UDP-ретранслятор — службу, которая принимает датаграммы клиента, отправляет их содержимое адресату и возвращает ответы. Сначала клиент договаривается о такой пересылке по TCP. Затем управляющее соединение и путь датаграмм работают параллельно.
- Клиент подключается к SOCKS5-серверу по TCP и проходит согласованную процедуру аутентификации.
- Он отправляет запрос
UDP ASSOCIATE. Если прокси разрешает пересылку, в ответе приходят адрес и UDP-порт ретранслятора. - Клиент отправляет ретранслятору датаграммы с SOCKS-заголовком, в котором указан адресат. Перед пересылкой содержимого ретранслятор снимает этот заголовок. К ответной датаграмме он добавляет SOCKS-заголовок и отправляет её клиенту.
- Клиент сохраняет управляющее TCP-соединение открытым, пока пользуется ретранслятором. При его закрытии настроенная через него пересылка UDP прекращается. Такая связь управляющего соединения с UDP-пересылкой называется UDP-ассоциацией.
Адрес или порт ретранслятора может отличаться от TCP-адреса подключения, введённого в настройках прокси. Простая отправка UDP на этот знакомый адрес не выполняет обмен SOCKS5. Клиент, в котором реализована только команда CONNECT, умеет использовать SOCKS5 для TCP, но не выполняет нужную здесь процедуру. В SOCKS4 такого механизма передачи UDP нет.
Отсюда возможен частичный успех: межсетевой экран разрешает TCP-подключение и аутентификацию, но блокирует датаграммы к согласованному ретранслятору. Пароль подходит, а UDP-ответов программа не получает. Для работы нужны обе части маршрута.
Может ли HTTP-прокси передавать UDP
Обычный HTTP-запрос CONNECT просит прокси открыть TCP-соединение с адресатом и передавать поток байтов. Передачу UDP он не устанавливает. TLS на соединении с HTTPS-прокси защищает это соединение, но не меняет тип запрошенного туннеля.
Для HTTP существует дополнительный механизм UDP-туннелирования, обычно называемый CONNECT-UDP и разработанный в рамках MASQUE. При совместимых клиенте и сервере программа запрашивает туннель к UDP-адресату. Прокси отправляет датаграммы этому адресату и возвращает ответы. Такая возможность должна быть явно поддержана с обеих сторон.
На соединении от клиента до прокси HTTP-датаграммы могут передаваться в кадрах QUIC DATAGRAM, если поддерживаются HTTP/3 и нужные расширения. Другой способ — капсулы: сообщения с собственными границами внутри надёжного HTTP-потока, в том числе HTTP/2 поверх TCP. Во втором случае прокси всё равно отправляет UDP целевому серверу, хотя первый участок маршрута использует TCP.
Этот выбор влияет на задержки. При потере данных в TCP-соединении следующие байты могут ждать восстановления, задерживая находящиеся внутри датаграммы. Туннель будет работоспособным, но может не подойти конкретной задаче реального времени. Простое указание адреса прокси с http:// не включает эти дополнительные механизмы UDP.
На каком участке работает QUIC
Фраза «QUIC-прокси» требует пояснения. Она может описывать транспорт для подключения к прокси или соединение приложения с адресатом. Это разные части обмена.
| Где используется QUIC | Что делает прокси | Что это подтверждает |
|---|---|---|
| Между клиентом и прокси | Принимает соединение по QUIC. Например, обычный CONNECT поверх HTTP/3 по-прежнему просит открыть TCP к адресату. | Соединение с прокси использует QUIC. Соединение с сайтом нужно проверить отдельно. |
| Между приложением и адресатом через UDP-ретранслятор | Пересылает датаграммы с QUIC-пакетами приложения через UDP-механизм SOCKS5 или подходящий HTTP UDP-туннель. | Приложение может установить QUIC с адресатом, если работает весь путь. HTTP/3 также должен поддерживаться и быть выбран участниками соединения. |
При обычной ретрансляции UDP прокси не требуется завершать на себе QUIC-соединение приложения. Он пересылает пакеты, а конечными участниками зашифрованного обмена остаются приложение и адресат. При этом прокси знает, куда пересылает трафик, и может наблюдать его объём и время передачи.
Почему важна поддержка в программе
Программа должна реализовывать тот способ пересылки, который предлагает сервис. Пункт SOCKS5 в настройках ещё не говорит о поддержке UDP ASSOCIATE. Аналогично программа может поддерживать HTTP/3 при прямом подключении, но предлагать только TCP-соединения через прокси.
Конкретный пример — Chrome: его встроенная поддержка SOCKS5 обслуживает TCP-запросы к URL и не ретранслирует UDP через SOCKS5. Загрузка страницы с такой настройкой не проверяет UDP-ретранслятор сервиса. Ограничение относится именно к этому режиму клиента; у других клиентов и внешних программ маршрутизации возможности могут отличаться.
Важна и область действия настройки. Вход в аккаунт, скачивание файлов, голос и игровой обмен могут использовать разные сетевые компоненты одной программы. Прокси для веб-запросов может охватывать только часть из них. Системная настройка прокси тоже зависит от того, учитывает ли её конкретное приложение.
Программа, перенаправляющая трафик другого приложения, может отправить его UDP через прокси, если поддерживает UDP и предлагаемый сервисом способ пересылки. Одного перенаправления TCP недостаточно. Если используется виртуальный сетевой интерфейс, правила маршрутизации определяют, какой трафик попадёт в него. Проверяйте всю связку: приложение, программу маршрутизации и выбранное подключение к прокси.
Запасной транспорт, ошибка и прямое подключение
Когда нужный путь недоступен, результат зависит от возможностей и правил программы. Если смотреть только на то, открылось ли что-нибудь, легко смешать три разных исхода:
| Результат | Как его понимать |
|---|---|
| Операция завершается ошибкой | Нужный обмен не завершился. Следует найти место отказа: клиент, создание туннеля, сетевой путь или адресат. |
| Сайт открывается по HTTP/2 или HTTP/1.1 | Обмен с сайтом использует версию HTTP поверх TCP. Веб-доступ работает, но HTTP/3 до этого сайта не подтверждён. Отдельное соединение с прокси может использовать другой транспорт. |
| UDP-обмен проходит напрямую | Трафик прошёл вне намеченного маршрута через прокси. Его выходной адрес нужно проверять отдельно. |
Переход к HTTP-версии на основе TCP называют fallback — переключением на запасной транспорт. Он помогает сохранить обычный веб-доступ при недоступности QUIC. Клиент открывает другое соединение; сам QUIC не превращается в TCP. Поэтому отключение QUIC может помочь веб-приложению использовать доступный TCP-путь, но не добавляет UDP функции, которой он необходим.
Прямое подключение определяется правилами маршрутизации. Неподдерживаемый UDP не всегда уходит напрямую: программа может остановиться, попробовать другой транспорт или выполнить настроенное исключение из проксирования. Если весь трафик задачи должен идти через прокси, программа должна останавливать передачу при отказе этого маршрута. Поведение программы стоит проверить при недоступном прокси.
Почему UDP может перестать работать после подключения
Правила портов и обратный путь
TCP-порт 443 и UDP-порт 443 относятся к разным транспортам. Разрешение одного не открывает другой. Для SOCKS5 клиенту нужен доступ к полученному адресу и UDP-порту ретранслятора, а ретранслятору — к UDP-порту адресата. HTTP/3 может работать и на портах, отличных от 443, поэтому проверять нужно фактический адрес подключения программы.
Ответ должен вернуться через ретранслятор, межсетевой экран и NAT, если он есть. NAT заменяет адреса и часто порты при передаче между сетями. Отправка датаграммы ещё не подтверждает работу обратного пути. При смене сети могут измениться публичный IP клиента или соответствие портов. Ретранслятор SOCKS5 обязан отбрасывать датаграммы с IP, отличного от записанного для этой UDP-ассоциации, поэтому после смены адреса может потребоваться новое подключение.
Паузы и истечение времени ожидания
Ретрансляторы и устройства NAT временно хранят записи, необходимые для UDP-обмена. После паузы такие записи могут удаляться. Звонок или сессия сначала работают, затем передача UDP прекращается, пока клиент не настроит её заново. Сохранение того же выходного IP само по себе этого не предотвращает: записи для передачи UDP и закрепление IP сервисом — разные вещи.
Размер датаграмм и MTU
MTU — максимальный размер IP-пакета, который сетевой канал передаёт без фрагментации. На всём маршруте действует самое маленькое из этих ограничений — MTU пути. Внутри пакета занимают место заголовки IP, UDP и дополнительные заголовки туннеля. Маленькое сообщение может проходить, а крупные датаграммы — отбрасываться, поэтому программе нужно учитывать весь путь и добавленные заголовки.
Маршрут QUIC должен передавать не менее 1 200 байт полезной нагрузки UDP, не считая заголовков IP и UDP. UDP-датаграммы клиента с начальными пакетами QUIC дополняются как минимум до этого размера полезной нагрузки. Заголовкам прокси на участке до ретранслятора требуется дополнительное место. Это не рекомендация выставить MTU интерфейса равным 1 200: небольшой DNS-запрос с ответом может проходить там, где более крупный начальный обмен QUIC не проходит.
Задержки, потери и нагрузка
Для звонка или игры время доставки может быть не менее важным, чем сама доставка. Нестабильная задержка, потери пакетов и ограничения на число пакетов в секунду могут мешать работе исправного UDP-ретранслятора. Одной пропускной способности недостаточно для оценки этих условий. Прокси добавляет участок к маршруту и может изменить производительность в любую сторону — в зависимости от сетей и нагрузки.
Как проверить UDP и HTTP/3 через прокси
Проверяйте приложение, которым собираетесь пользоваться, или клиент с тем же способом пересылки. Полезная проверка подтверждает получение ответа и определяет транспорт и выходной адрес одного и того же обмена.
- Выберите адресата, который отвечает на нужный трафик. Подойдёт сервер самого приложения или контролируемый UDP-сервис для проверки. Для HTTP/3 нужен адресат с известной поддержкой этой версии. Молчание произвольного UDP-порта не показывает, где возник отказ.
- Убедитесь, что ретрансляция или туннель разрешены. Для SOCKS5 проверьте результат
UDP ASSOCIATEи полученные адрес и порт ретранслятора. Для HTTP UDP-туннеля — принятие запроса на этот туннель. Одной успешной аутентификации для этого недостаточно. - Завершите обмен запросом и ответом. Контролируемый сервис может вернуть идентификатор запроса и записать IP отправителя, который он увидел. Так проверяется выход именно этого UDP-обмена. Отдельная веб-проверка IP относится только к собственному запросу.
- Для HTTP/3 подтвердите протокол в обмене с адресатом. Найдите HTTP/3 или
h3в журнале соединений клиента либо сервера и сопоставьте это с подтверждением маршрута через прокси. Если тестовый клиент имеет режим только HTTP/3, он поможет обнаружить отказ, который скрыло бы автоматическое переключение на TCP. - Повторите проверку в нужных условиях: с характерными размерами датаграмм, длительным обменом и паузой перед возобновлением работы. Если прямой трафик для задачи недопустим, проверьте также поведение при недоступном прокси. Сохраните с результатом версию клиента и параметры подключения.
Запись сетевых пакетов помогает определить маршрут. При стандартной передаче UDP через SOCKS5 датаграммы идут к согласованному ретранслятору. HTTP UDP-туннель может использовать внешнее TCP-соединение, поэтому отсутствие UDP на первом участке само по себе не подтверждает отказ.
Удалённый DNS и ping проверяют другое. Прокси может получить IP по имени для TCP-соединения, не передавая UDP-трафик приложения. Обычный ping использует ICMP. Эти проверки не заменяют UDP-запрос и ответ по нужному маршруту через прокси.
Когда стоит выбирать поддержку UDP
Начните с трафика, который нужен вашей задаче. Для сайтов и API, работающих по HTTP/1.1 или HTTP/2, может полностью подойти прокси только с TCP. Проверка HTTP/3, передача медиаданных по UDP и другие функции, зависящие от UDP, требуют подходящего ретранслятора или туннеля и клиента, который умеет им пользоваться.
Уточните у сервиса поддерживаемый способ передачи UDP и конфигурацию клиента. Затем проверьте разрешённые адреса и порты, ограничения размера датаграмм, поведение после простоя и значимые для нагрузки лимиты трафика или числа пакетов. Если TCP и UDP должны использовать один выходной IP или одну локацию, проверьте это в самой программе. Общий аккаунт и успешный веб-запрос не подтверждают одинаковое поведение выхода.