XHTTP: Beyond REALITY · XTLS/Xray-core · Discussion #4113 (original) (raw)

中文 | Русский

UPDATED 11.03.2025

XHTTP: За гранью REALITY

Краткое описание разработки: В середине 2024 года, @mmmray @ll11l1lIllIl1lll и другие, основываясь на принципе "раздельная пакетная отправка, потоковая загрузка" и деталях реализации, описанных @RPRX, разработали SplitHTTP, впервые добившись обхода большинства промежуточных устройств, поддерживающих HTTP, без ущерба для эффективности загрузки, и впервые массово реализовали QUIC H3 через CDN, открыв новую эру.

Впоследствии были реализованы: Broswer Dialer, добавление отступов в заголовки для уменьшения сигнатуры (header padding), управление мультиплексированием (XMUX) и разблокировка REALITY. Затем разработку взял на себя @RPRX, реализовав настоящее разделение исходящего и входящего трафика и переименовав проект в XHTTP. Например, исходящий и входящий трафик могут быть IPv6 CDN H3 и IPv4 REALITY H2 соответственно (даже исходные IP-адреса могут различаться), и вот снова началась новая эра. Далее был разработан потоковый режим отправки (stream-up), не жертвующий эффективностью исходящего трафика, схема extra, позволяющая делиться всеми деталями конфигурации, и добавлена маскировка заголовков gRPC по умолчанию для режима stream-up, что позволило реализовать потоковую отправку H2 через CDN, заменив традиционный транспортный уровень gRPC, если бы мы знали, что это возможно, то не стали бы его создавать. Наконец, транспортный уровень HTTP был включен в XHTTP как режим stream-one, получив также header padding, XMUX, маскировку заголовков gRPC и другие функции. Таким образом, мы получили полноценный XHTTP: обход промежуточных устройств различными способами, разделение исходящего и входящего трафика, XMUX и все остальное, что только можно пожелать. Наступила эра всеобщего господства XHTTP.

Эта статья призвана помочь вам полностью понять принцип и дизайн XHTTP, чтобы вы могли лучше его использовать.

Если вы хотите пожертвовать проекту Xray или приобрести NFT, информация находится в конце статьи. Спасибо за поддержку!

Руководство по быстрому старту

Не пугайтесь большого количества параметров XHTTP, значения по умолчанию уже настроены оптимально. Если вы просто хотите использовать XHTTP, выполните следующие шесть шагов:

  1. Будь то TLS или REALITY, как правило, в конфигурации XHTTP достаточно заполнить path, остальные поля можно оставить пустыми.
  2. Если сервер поддерживает QUIC H3, на клиенте в alpn выберите "h3" для использования QUIC.
  3. Для выбора лучшего IP CDN (Cloudflare IP Selection): на клиенте в поле address укажите IP, а в serverName (SNI) — доменное имя.
  4. Если не удается подключиться к CF (Cloudflare), включите поддержку gRPC в панели управления CF.
  5. Если не удается пройти через Nginx, измените proxy_pass в Nginx на grpc_pass.
  6. Если не удается пройти через другие CDN или обратные прокси, рекомендуется выбрать mode "packet-up" — он обладает наилучшей совместимостью.

В XHTTP по умолчанию включено мультиплексирование. Задержка ниже, чем у Vision, но скорость в многопоточном режиме уступает ему, если перед тестом скорости не установить "maxConcurrency": 1. См. раздел XMUX.

CF разрывает соединение, если в течение 100 секунд нет фактической передачи данных по HTTP (downstream). Для долгоживущих соединений прокси требуется поддержание активности (keepalive) на уровне приложения. Например, для SSH необходимо установить ClientAliveInterval в sshd.

Эту статью можно использовать как расширенную документацию. Она охватывает практически всё, что вы хотели бы знать о XHTTP, с объяснением каждого параметра. В конце статьи также приведен пример конфигурации, охватывающий все параметры, с указанием сценариев использования для каждого. Если вам непонятен какой-либо параметр, воспользуйтесь поиском по тексту статьи.

Два базовых принципа

Подобно тому, как REALITY может маскироваться под чужие веб-сайты, фундаментальная логика борьбы с цензурой заключается в увеличении «сопутствующего ущерба» для цензора при блокировке, заставляя его не действовать опрометчиво. В свое время я возлагал надежды на TLS и обфускацию временных/размерных характеристик трафика внутри TLS по той же причине. Многолетний опыт подсказывает нам, что GFW не будет вечно блокировать все IP крупных CDN, иначе это затронет слишком много обычных сайтов. Поэтому нашей первоначальной целью для XHTTP было спрятать его за множеством разнообразных CDN. Однако CDN, чтобы защитить исходный сайт (Origin) от атак, обычно кэшируют весь HTTP-запрос перед отправкой на источник (за исключением WS и gRPC, имеющих специальную поддержку). Многие устройства HTTP Middlebox по умолчанию ведут себя так же. Исходя из этого, протокол Meek в Tor упаковывал трафик туда-обратно в отдельные HTTP-запросы для прохождения через эти Middlebox, но скорость была ужасной, так как не использовался «потоковый downstream» (stream-down), реализованный в XHTTP.

Что такое «потоковый downstream»? Представьте, что вы скачиваете большой файл с веб-сайта. CDN не нашел его в кэше и обращается к источнику. Очевидно, что CDN не будет кэшировать весь файл целиком, заставляя вас ждать (как это происходит с upstream), а будет пересылать данные вам по мере их поступления от источника. Это и есть основа «потокового downstream» в XHTTP, гарантирующая максимальную скорость загрузки. Что касается upstream (исходящего трафика), то ради совместимости в XHTTP сначала была реализована «пакетная отправка» (packet-up), при которой исходящий трафик упаковывается в отдельные POST-запросы. Эффективность этого метода очевидно ниже, но к счастью, для обычных нужд прокси исходящий трафик минимален. Позже я добавил «потоковый upstream» (stream-up), и мы обнаружили, что с добавлением маскировки заголовка gRPC можно использовать H2 stream-up для прохождения через CF. А после нескольких раундов оптимизации «пакетной отправки», её скорость стала сопоставима с «потоковой».

Кстати, о недавних спорах, является ли использование CDN «злоупотреблением»: очевидно, что CDN, не поддерживающие stream-up, изначально не предназначены для создания прокси-сервисов. Но для противостояния GFW мы вынуждены постоянно искать, разрабатывать и использовать как можно больше новых путей - это разумно и необходимо. Увеличение «сопутствующего ущерба» для цензора требует от нас смешивания с «нормальными» сервисами, и это неизбежно. Простой пример: если однажды введут «белые списки» IP, и IP CDN окажется в нем, вы будете его использовать или нет? В области борьбы с цензурой неприменимы некоторые правила «реального мира», но некоторые люди до сих пор не могут понять эту простую истину. Если вы всё ещё сомневаетесь: такие транспортные протоколы, как WebSocket, сейчас существуют только ради использования CDN. Как разработчик, я мог бы удалить его; как пользователь, вы можете предложить разработчику удалить его, чтобы действиями доказать, что «злоупотребление CDN» - это не просто очередной предлог для нападок на Xray ради удовлетворения чьих-то нездоровых психологических потребностей. При этом тело говорит об обратном. Несложно заметить, что лицемерная сущность некоторых людей уже полностью раскрыта.

PACKET-UP

В этом разделе много технических деталей. Те, кто не являются разработчиками могут читать только текст, выделенный жирным шрифтом.

Для режима с максимальной совместимостью XHTTP «пакетная отправка, потоковая загрузка», то есть packet-up, мы разработали следующий дизайн:

  1. Клиент выполняет POST /yourpath/sameUUID/seq для отправки данных (upstream):
    • UUID генерируется случайно. UUID при запуске downstream (см. ниже) должен совпадать с ним для ассоциации на сервере. Если сервер не сможет связать их в течение 30 секунд, сессия будет прервана.
    • seq начинается с 0. Следующий POST отправляется только после полной передачи тела предыдущего POST (ожидание ответа не требуется).
    • Существует небольшая вероятность, что несколько POST придут на сервер не по порядку. Сервер пересоберёт их согласно seq. По умолчанию кэшируется до 30 пакетов, при превышении соединение разрывается.
    • Обратите внимание, что UUID и seq находятся в path, а не в query string, чтобы избежать странных проблем.
  2. Клиент выполняет GET /yourpath/sameUUID для запуска загрузки (downstream). Заголовки ответа сервера содержат:
    • X-Accel-Buffering: no для уведомления Middlebox об отключении буферизации.
    • Cache-Control: no-store для уведомления Middlebox об отсутствии необходимости кэширования.
    • Content-Type: text/event-stream для маскировки под Server-Sent Events (лучшая совместимость, можно отключить опцией noSSEHeader).
    • Для HTTP/1.1 также требуется Transfer-Encoding: chunked, для H2/H3 это не нужно.
  3. Для предотвращения ограничений CORS при переадресации через браузер (Browser Dialer), заголовки ответа сервера для всех GET и POST запросов содержат:
    • Access-Control-Allow-Origin: *
    • Access-Control-Allow-Methods: GET, POST
  4. Для решения проблемы фиксированной длины HTTP заголовков запроса и ответа:
    • Заголовки запроса (Request header) клиента по умолчанию содержат Referer: ...?x_padding=XXX... (использование Referer предотвращает ненужные запросы OPTIONS от Browser Dialer). Длина по умолчанию 100-1000 байт, рандомизируется при каждом запросе. Сервер по умолчанию проверяет, находится ли длина в допустимом диапазоне.
    • Заголовки ответа (Response header) сервера по умолчанию содержат X-Padding: XXX.... Длина по умолчанию 100-1000 байт, рандомизируется при каждом ответе.
    • Это и есть тот самый header padding, о котором я многократно упоминал. Соответствующая настройка — xPaddingBytes.
    • Идею переноса padding заголовка запроса в Referer предложил @rPDmYQ, как и использование XXX (X в кодировке Хаффмана занимает 8 бит).

Пакетная отправка и Referer: ...?x_padding=XXX... генерируют много длинных логов. Вы можете настроить свой обратный прокси (reverse proxy) так, чтобы он их не записывал.

Кроме того, как и другие транспортные уровни Xray, сервер принимает заголовок X-Forwarded-For для получения реального IP клиента, а также проверяет host, присланный клиентом, на соответствие host, установленному на сервере (лично я советую не устанавливать host без необходимости, так как трафик уже скрыт за path).

Выше описан минимально необходимый процесс режима packet-up. Но есть нюанс: как конкретно реализовать и ограничить POST-запросы? Для этого есть три специальных параметра:

«Для одного прокси-соединения» означает, что каждый запрос через прокси считается отдельно и не влияет на другие, даже если они идут внутри одного соединения H2 / H3. Это смысл аббревиатуры sc (sub-connection). Для уменьшения "отпечатков" (fingerprint), первые два значения можно задать в виде диапазона, например, строками "500000-1000000", "10-50". В этом случае значение выбирается случайно каждый раз. Эти параметры можно передать клиенту через extra (см. конец статьи). Стоит отметить, что в последней версии Xray оптимизирован режим packet-up, и его скорость приближается к stream-up, что особенно полезно для QUIC H3 через CDN.

H1 / H2 / H3

Поскольку у нас есть режим packet-up, способный пройти почти через любой HTTP Middlebox, давайте обсудим интересную вещь: QUIC H3 через CDN. Это та самая «новая эра» SplitHTTP. Понимание этого раздела особенно важно для гибкого использования XHTTP.

Особенностью многих HTTP Middlebox является конвертация версий HTTP. Например, CDN или Nginx конвертируют входящий трафик H3 в H1 или H2 при обращении к источнику (Origin). Это означает, что наш сервер XHTTP может слушать только H1 и H2, не слушая H3, но клиент XHTTP при этом может использовать H3.

Это поведение сервера XHTTP по умолчанию: слушать только TCP порт и обрабатывать трафик H1 и H2. Если включить TLS и в alpn установить только один элемент "h3", сервер будет использовать quic-go для прослушивания UDP порта и обработки трафика H3. Однако, в настоящее время не рекомендуется так делать. Лучше спрятать XHTTP за настоящим Nginx или Caddy для уменьшения характеристик отпечатка. Это одно из важных преимуществ XHTTP перед другими QUIC-прокси (второе, конечно, возможность работы через CDN). Кроме того, контроль перегрузки (congestion control) в H3 реализован на прикладном уровне. Теоретически, вы можете изменить алгоритмы контроля перегрузки QUIC в этих обратных прокси и скомпилировать их, чтобы реализовать агрессивную отправку пакетов, как некоторые хотят.

Для клиента XHTTP:

  1. При включении TLS/REALITY по умолчанию используется H2, иначе HTTP/1.1.
  2. При включении TLS, если в alpn указано только "http/1.1", используется HTTP/1.1 (но Xray не позволит этому изменить маскировку отпечатка браузера в uTLS).
  3. При включении TLS, если в alpn указано только "h3", используется quic-go H3.
  4. Однако при использовании Browser Dialer конкретная версия HTTP определяется браузером (весь tlsSettings теряет силу).

Если вы хотите проверить фактически используемую версию HTTP, host, режим XHTTP и информацию о разделении upstream/downstream в клиенте Xray, установите уровень логирования на "info".

Проксирование QUIC H3 через CDN было впервые масштабно реализовано именно в XHTTP, открыв новый путь. Ведь в некоторых регионах и у некоторых провайдеров цензура H3 не такая строгая, хотя некоторые блокируют его наглухо. Даже после разработки режима stream-up и обнаружения возможности прохождения CF через H2 с маскировкой под gRPC, этот метод остаётся актуальным, похоже, ценность этой «новой эры» продолжает расти.

XMUX

Раз уж мы заговорили о H2 и H3, нельзя не упомянуть их мультиплексирование: оба поддерживают 0-RTT. Разница в том, что у H3 нет проблемы блокировки начала очереди (Head-of-Line Blocking), свойственной TCP в H2, и он поддерживает миграцию соединений (клиент не отключается при смене сети). Друзья, часто читающие RFC, спросят: как конкретно управлять их мультиплексированием? Мы разработали лаконичный и мощный интерфейс — XMUX:

Эти параметры XMUX позволяют создавать различные комбинации. Например, для многопоточного теста скорости нужно установить "maxConcurrency": 1, а для «бесконечного» переиспользования — "maxConnections": 1. Даже если вам лень разбираться, когда все значения равны 0, применяются три описанных выше значения по умолчанию. Это эквивалентно периодической смене основного соединения H2/H3, что работает очень плавно и исключает проблему «обрыва потока», характерную для постоянного использования одного соединения в gRPC или HTTP транспортах. Эти параметры также можно передать клиенту через extra.

Примечание: Если ничего не заполнять, это равносильно всем нулям (применяются значения по умолчанию). Но если заполнен хотя бы один параметр, значения по умолчанию для остальных отключаются, и всё нужно заполнять самостоятельно (кроме первых двух, которые взаимоисключающие).

Кроме того, при использовании XHTTP не включайте mux.cool. В новой версии Xray Server добавлена проверка, принимается только чистый XUDP.

Некоторые заметки о значениях по умолчанию в XMUX:

В конце статьи также обсуждаются некоторые параметры Nginx.

STREAM-UP/ONE

Наконец, мы подошли к еще одному важному режиму XHTTP: stream-up («потоковая отправка, потоковая загрузка»). Как следует из названия, в этом режиме отправка (upstream) также является потоковой, что не снижает её эффективность. Изначально он разрабатывался для REALITY, пока мы не обнаружили, что с добавлением маскировки gRPC header можно использовать H2 для прохождения через CF (требуется включить поддержку gRPC в панели CF). Поддержка в Nginx и других обратных прокси также хороша (в Nginx рекомендуется grpc_pass, это просто и удобно). Поведение mode со значением "auto" следующее:

stream-up имеет лучшую совместимость, чем stream-one. Участники сообщества сообщали, что для использования stream-up в CFT достаточно включить потоковую отправку, но для stream-one требуется включить еще одну опцию (возможно, из-за маскировки SSE?). Также был замечен один CDN (забыл название), который сильно резал скорость на stream-one, но не на stream-up.

Способы реализации (не разработчики могут пропустить):

В обсуждении здесь было обнаружено, что CF обрывает соединение, если в течение 100 секунд нет фактических данных в downstream, что приводило к обрыву upstream в режиме stream-up. Поэтому этот PR добавил на сервер scStreamUpServerSecs со значением по умолчанию "20-80" (случайно). Сервер отправляет xPaddingBytes байт каждые N секунд для поддержания активности.

Можно установить "scStreamUpServerSecs": -1 для отключения этого механизма. В этом случае сервер даже не будет сразу отправлять заголовки ответа, что соответствует поведению предыдущих версий.

Пользователи gRPC могут спросить: в чем преимущество stream-up перед транспортом gRPC?

Конечно, преимущества XHTTP перед WebSocket и HTTPUpgrade, помимо «отсутствия явного признака ALPN http/1.1», очевидны, если вы дочитали до этого места. Я не буду перечислять их все, главным образом потому, что их слишком много.

Разделение входящего и исходящего трафика (Upstream/Downstream Separation)

Гвоздь программы — еще одна новая эра: разделение upstream и downstream. Мы знаем, что обнаружение GFW трафика TLS in TLS и других признаков основано на одном соединении. Если мы разделим входящий и исходящий трафик по разным системам цензуры (например, upstream через IPv4 TCP, а downstream через IPv6 UDP), GFW не сможет сразу среагировать. Поскольку сервер XHTTP связывает upstream и downstream только на основе случайного UUID в пути (path), режимы packet-up и stream-up от природы обладают возможностью истинного разделения. А благодаря тому, что XHTTP может проходить через различные CDN и комбинироваться с REALITY, количество вариантов бесконечно. Для клиента необходимо настроить downloadSettings:

Как видите, downloadSettings — это, по сути, новый набор streamSettings, но с добавлением address и port (аналогично VLESS outbound) для указания другой точки входа. Очевидно, что network должен быть "xhttp" (нельзя опускать), security может быть "tls" или "reality". Параметр sockopt также можно шарить, но получатель может в sockopt для upstream установить penetrate в true, чтобы переопределить настройки downstream. Это подходит для проставления mark. За исключением этого особого случая, конфигурация downstream полностью независима и не наследует никаких настроек от upstream. Кроме того, даже если XMUX не заполнен (и используются значения по умолчанию), конкретные случайные значения в диапазонах для upstream и downstream независимы и не связаны друг с другом. Таким образом, с течением времени переиспользование соединений становится полностью асимметричным, и моменты переключения основных соединений различаются, что улучшает защиту от анализа. Поскольку для атаки GFW на разделенный трафик «совпадение времени начала основного соединения» является важнейшей точкой входа, в будущем XHTTP позволит начинать соединения upstream и downstream в разные моменты времени с самого начала.

На самом деле, если вы используете CDN, вам даже не нужно изменять конфигурацию сервера, чтобы использовать разделение трафика. Например, вы можете выбрать лучший IPv4 для TLS H2 и лучший IPv6 для QUIC H3. Кроме того, CDN в основном поддерживают «Domain Fronting в пределах одного домена» (Domain Fronting). Например, serverName для upstream — "a.example.com", для downstream — "b.example.com", а host для обоих — "c.example.com". Это позволяет внешнему SNI выглядеть по-разному. Если у вас два домена — еще лучше. Если доменов нет вообще, можно запустить два VPS и два REALITY для разделения: будь то CDN + обратный прокси или REALITY + fallback, главное, чтобы трафик в итоге приходил на один и тот же XHTTP inbound на одном и том же VPS с одним и тем же path. Поскольку XHTTP работает везде, комбинации безграничны, единственный вопрос — хватит ли фантазии.

После появления разделения трафика многие стали использовать маршруты с лучшим прямым каналом для upstream и лучшим обратным каналом для downstream. Это очень практично.

Например, можно установить "maxConnections": 1 для upstream и "maxConcurrency": 1 для downstream. Это позволит малому объему данных upstream идти через одно базовое соединение, а большому объему данных downstream распределяться по разным базовым соединениям, обеспечивая одновременно устойчивость к цензуре, низкую задержку и высокую скорость. Это похоже на Switch, эффект еще лучше в сочетании с Vision Seed.

Выше приведен пример конфигурации, охватывающий все параметры. Главная цель — показать, где должен находиться каждый параметр. Поясню параметры, которые мало объяснялись ранее:

Если вы хотите проверить фактически используемую версию HTTP, host, режим XHTTP и информацию о разделении upstream/downstream в клиенте Xray, установите уровень логирования на "info".

Beyond REALITY

В начале прошлого года я вернулся и написал REALITY, который уничтожил всё живое, решив одним махом множество проблем. Потом я тусил по клубам и особо не занимался этим, даже статью до сих пор не закончил, жаль XUDP UoT Migration, статья была почти готова в прошлом году, но так и не вышла. Незаметно REALITY стал основным средством для прямого подключения. Часто можно видеть комментарии с рекомендацией сменить протокол на REALITY, когда кого-то блокируют. Репутация очевидна, здесь даже стало тише из-за его чрезмерной стабильности. Хотя Xray сделал множество оптимизаций для других транспортов, XHTTP — это первый «родной» транспортный уровень Xray, и сразу такой масштабный. Дочитав эту статью, вы поймете, что XHTTP можно использовать вместе с REALITY:

Фраза "Beyond REALITY" не означает замену REALITY, а означает, что по популярности он превзойдет REALITY. Без преувеличения, в стиле Xray, появление XHTTP затмевает все остальные HTTP-транспорты. Это эра XHTTP, подходящего для любых сценариев. Он станет популярнее, чем прошлый успешный протокол REALITY, потому что характеристики XHTTP определяют его более широкий охват.

Надеюсь, появление XHTTP немного потрясет вас, как это не раз бывало в истории Xray: Перемены и инновации всегда были верой Xray.

Если эта статья была вам полезна, поддержите REALITY NFT:

Благодаря вашей поддержке цена Project X NFT выросла в 5-6 раз. Для тех, кто наблюдал за запуском Project X NFT со стороны, это отличный шанс наверстать упущенное.

Конечно, если у вас есть возможность, буду благодарен за поддержку Project X NFT:

Если что-то осталось непонятным, оставляйте комментарии. Я буду обновлять статью. Рекомендую не выпускать перевод слишком рано.