中文 | Русский

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, клиент может использовать QUIC, выбрав alpn равным "h3".
3. Для выбора IP-адреса CDN в клиенте укажите IP-адрес в address и доменное имя в serverName (SNI).
4. Если не удается подключиться к CF, включите поддержку gRPC на панели управления CF.
5. Если не удается пройти через Nginx, измените proxy_pass на grpc_pass в конфигурации Nginx.
6. Если не удается пройти через другие CDN или обратные прокси, рекомендуется выбрать mode равным "packet-up" для максимальной совместимости.

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

CF обрывает HTTP-соединения без передачи данных в течение 100 секунд. Для поддержания активности долговременных соединений через прокси необходимо реализовать keep-alive на уровне приложения. Например, для SSH необходимо установить ClientAliveInterval в sshd.

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

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

Так же, как REALITY может маскироваться под чужой веб-сайт, фундаментальная логика борьбы с цензурой заключается в увеличении «сопутствующего ущерба» для цензоров при блокировке, чтобы они не решались легко блокировать. Я в свое время делал ставку на TLS и запутывание временных и размерных характеристик трафика TLS по той же причине. Многолетний опыт показывает нам, что GFW не будет навсегда блокировать весь IP-адрес крупного CDN, иначе это затронет слишком много обычных веб-сайтов. Таким образом, для XHTTP наша первоначальная цель состояла в том, чтобы скрыть его за множеством различных CDN. Однако CDN, чтобы предотвратить атаки на исходный сервер, обычно кэшируют весь HTTP-запрос, прежде чем отправлять его на исходный сервер, за исключением специально поддерживаемых WS и gRPC. Многие промежуточные HTTP-устройства по умолчанию ведут себя аналогичным образом. Исходя из этого, протокол Meek от Tor упаковывает исходящий и входящий трафик в отдельные HTTP-запросы для обхода этих промежуточных устройств, но скорость ужасно низкая, потому что он не использует «потоковую загрузку» XHTTP. Что такое «потоковая загрузка»? Представьте, что вы загружаете большой файл с веб-сайта, и CDN не находит его в кэше, поэтому обращается к исходному серверу. Но, очевидно, он не будет кэшировать весь файл, как при загрузке, заставляя вас ждать, а будет немедленно передавать вам данные по мере их получения от исходного сервера. Это основа «потоковой загрузки» XHTTP, которая также гарантирует максимальную скорость загрузки. Что касается загрузки, то из соображений совместимости XHTTP сначала реализовал «пакетную загрузку», то есть упаковку исходящего трафика в отдельные POST-запросы. Его эффективность, очевидно, снижается, но, к счастью, для обычных прокси-серверов объем исходящего трафика очень мал. Позже я добавил «потоковую загрузку», и мы обнаружили, что с добавлением маскировки заголовка gRPC можно использовать потоковую загрузку H2 через CF, а после нескольких раундов оптимизации «пакетной загрузки» скорость даже приблизилась к «потоковой загрузке».

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

PACKET-UP

Этот раздел содержит много технических деталей. Обычные пользователи могут прочитать только выделенный текст.

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

1. Клиент отправляет POST /yourpath/sameUUID/seq для передачи данных:

   • UUID генерируется случайным образом и используется при запуске загрузки, чтобы сервер мог связать запросы. Если сервер не может связать запросы в течение 30 секунд, сеанс завершается.
   • seq начинается с 0. Следующий POST-запрос можно отправлять только после отправки тела предыдущего (но не нужно ждать ответа).
   • Несколько POST-запросов могут прийти на сервер в неправильном порядке. Сервер пересобирает их по seq. По умолчанию кэшируется до 30 запросов, превышение лимита приводит к разрыву соединения.
   • Обратите внимание, что UUID и seq находятся в пути, а не в строке запроса, чтобы избежать странных проблем.

2. Клиент запускает загрузку с помощью GET /yourpath/sameUUID. Заголовок ответа сервера содержит:

   • X-Accel-Buffering: no, чтобы сообщить промежуточным устройствам отключить буферизацию.
   • Cache-Control: no-store, чтобы сообщить промежуточным устройствам не кэшировать данные.
   • Content-Type: text/event-stream для маскировки под server-sent events (лучшая совместимость, можно отключить с помощью noSSEHeader).
   • Для HTTP/1.1 также необходимо включить Transfer-Encoding: chunked, для H2/H3 это не требуется.

3. Чтобы избежать ограничений междоменных запросов при перенаправлении браузера Browser Dialer, заголовок ответа сервера для всех GET и POST-запросов содержит:

   • Access-Control-Allow-Origin: *
   • Access-Control-Allow-Methods: GET, POST

4. Для решения проблемы фиксированной длины заголовков HTTP-запросов и ответов:

   • Заголовок запроса клиента по умолчанию содержит Referer: ...?x_padding=XXX... (Referer используется для предотвращения ненужных OPTIONS-запросов от Browser Dialer). Длина по умолчанию составляет 100-1000 символов, генерируется случайным образом для каждого запроса. Сервер по умолчанию проверяет, находится ли длина в допустимом диапазоне.
   • Заголовок ответа сервера по умолчанию содержит X-Padding: XXX.... Длина по умолчанию составляет 100-1000 символов, генерируется случайным образом для каждого ответа.
   • Это то, что я неоднократно называл header padding, соответствующий параметр — xPaddingBytes.
   • Размещение padding в Referer предложил @rPDmYQ, использование XXX также его идея. X в кодировке Хаффмана занимает 8 бит.

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

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

Это упрощенный, необходимый процесс для режима packet-up. Однако остается один вопрос: как конкретно реализовать и ограничить POST-запросы? Для этого есть три специальных параметра:

• scMaxEachPostBytes: максимальный размер данных в каждом POST-запросе клиента. Значение по умолчанию — 1000000 (1 МБ). Это значение должно быть меньше максимального размера, разрешенного CDN и другими промежуточными HTTP-устройствами. Сервер также отклоняет POST-запросы, превышающие этот размер.
• scMinPostsIntervalMs: только для клиента, минимальный интервал между POST-запросами для одного прокси-запроса. Значение по умолчанию — 30 миллисекунд.
• scMaxBufferedPosts: только для сервера, максимальное количество кэшируемых POST-запросов для одного прокси-запроса. Значение по умолчанию — 30. Превышение лимита приводит к разрыву соединения.

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

H1 / H2 / H3

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

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

Это поведение по умолчанию для сервера XHTTP: прослушивание только TCP-порта и обработка трафика H1 и H2. При включении TLS и указании только "h3" в alpn сервер будет использовать quic-go для прослушивания UDP-порта и обработки трафика H3, но в настоящее время это не рекомендуется. Вместо этого следует скрывать XHTTP за реальными Nginx или Caddy, чтобы уменьшить цифровые отпечатки. Это одно из важных преимуществ XHTTP по сравнению с другими QUIC-прокси, другое, конечно, это возможность проходить через CDN. Кроме того, управление перегрузкой 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, используемую клиентом Xray, host, а также режим XHTTP, разделение загрузки и выгрузки и другую информацию, установите уровень ведения журнала "info".

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

XMUX

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

• maxConcurrency: максимальное количество одновременных прокси-запросов в каждом TCP/QUIC-соединении. Когда количество прокси-запросов в соединении достигает этого значения, ядро устанавливает новое соединение, чтобы вместить больше прокси-запросов. Если все параметры XMUX равны 0, значение по умолчанию для этого параметра — "16-32", выбирается случайным образом.

• maxConnections: максимальное количество одновременных соединений. До достижения этого значения каждый новый прокси-запрос открывает новое соединение. После этого ядро начинает повторно использовать существующие соединения. Этот параметр конфликтует с maxConcurrency, можно использовать только один из них. Значение по умолчанию — 0, то есть без ограничений. Поддерживается указание диапазона, значение выбирается случайным образом.

• cMaxReuseTimes: максимальное количество раз, которое соединение может быть повторно использовано. После достижения этого количества соединение больше не будет использоваться для новых прокси-запросов и будет закрыто после завершения последнего прокси-запроса. Значение по умолчанию — 0, то есть без ограничений. Поддерживается указание диапазона, значение выбирается случайным образом.

• hMaxRequestTimes: @xqzr обнаружил, что Nginx по умолчанию разрешает максимум 1000 HTTP-запросов на каждое TCP/QUIC-соединение. Если все параметры XMUX равны 0, значение по умолчанию для этого параметра — "600-900", выбирается случайным образом. В противном случае значение по умолчанию — 0, то есть без ограничений. Этот параметр основан на подсчете HTTP-запросов. Обычно stream-one генерирует один HTTP-запрос, stream-up — два, а packet-up — N. Подсчет не является точным, и GET-запросы Golang имеют автоматический повтор, поэтому не рекомендуется устанавливать максимальное значение. CDN и другие провайдеры нужно тестировать. Если при циклической отправке POST-запросов в режиме packet-up это значение превышено, происходит автоматическое переключение на другое TCP/QUIC-соединение, которое занимает один reuseTimes, но не занимает concurrency. Фактически, при значениях XMUX по умолчанию stream-* не превышает лимит, только packet-up, который является режимом по умолчанию для H3. Поэтому добавление этого параметра снова в основном выгодно для H3.

• hMaxReusableSecs: @xqzr обнаружил, что Nginx по умолчанию разрешает повторное использование каждого TCP/QUIC-соединения в течение одного часа. Если все параметры XMUX равны 0, значение по умолчанию для этого параметра — "1800-3000", выбирается случайным образом. В противном случае значение по умолчанию — 0, то есть без ограничений. TCP/QUIC-соединение, существующее в течение этого времени, больше не будет использоваться для новых HTTP-запросов и будет закрыто после завершения последнего HTTP-запроса. Если при циклической отправке POST-запросов в режиме packet-up это значение превышено, происходит автоматическое переключение на другое TCP/QUIC-соединение, которое занимает один reuseTimes, но не занимает concurrency.

• hKeepAlivePeriod: интервал в секундах, через который клиент отправляет keep-alive пакет в неактивном H2/H3 соединении. Значение по умолчанию — 0, что соответствует 45 секундам для Chrome H2 или 10 секундам для quic-go H3. Это единственный параметр в XMUX, который не допускает указание диапазона (случайный выбор значения будет являться признаком) и допускает отрицательные значения (например, -1 отключает keep-alive пакеты в неактивном состоянии). Рекомендуется оставить значение 0.

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

Примечание: отсутствие значений эквивалентно нулевым значениям, будут использованы три значения по умолчанию. Но если указан хотя бы один параметр, остальные параметры не имеют значений по умолчанию и должны быть указаны явно, за исключением первых двух параметров. Все остальные параметры можно указывать одновременно.

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

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

• Я специально выбрал два параметра, которые не так заметны вне TLS, а именно maxConcurrency и cMaxReuseTimes (а не maxConnections и cMaxLifetimeMs), и значения по умолчанию для этих параметров являются диапазоном со случайным выбором, что максимально устраняет потенциальные признаки.
• Я выбрал maxConcurrency вместо maxConnections, чтобы предотвратить появление фиксированного шаблона количества соединений. Конечно, если вам нравится второй вариант, вы можете установить его вручную.

• XMUX и Nginx имеют разные объекты подсчета. maxConcurrency и cMaxReuseTimes основаны на подсчете «проксируемых соединений». Только stream-one генерирует один HTTP-запрос, stream-up — два (один для загрузки, один для выгрузки), а packet-up — N.
• Однако я не уверен, что stream-one не будет генерировать дополнительные HTTP-запросы в некоторых случаях. Кроме того, я считаю, что стремление к повторному использованию одного соединения до конца не имеет большого смысла, потому что если бы вы были оператором связи, вы бы также ограничивали скорость и очищали старые соединения, иначе ресурсы были бы постепенно заняты старыми соединениями. Поэтому параметры XMUX по умолчанию ограничивают повторное использование и периодически меняют соединения.

Далее в статье обсуждаются некоторые параметры Nginx.

STREAM-UP/ONE

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

• Клиент: stream-up для TLS H2, stream-one для REALITY (stream-up при наличии downloadSettings), в противном случае packet-up.
• Сервер: по умолчанию принимает все три режима. Если задан конкретный режим, принимается только он. "stream-up" является исключением, он также принимает stream-one.

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

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

• Для stream-up достаточно заменить пакетную загрузку packet-up на потоковую POST /yourpath/sameUUID. Также используется Referer: ...?x_padding=XXX....
• Для stream-one используется POST /yourpath/. Ответ является выгрузкой, двунаправленный поток. Заголовки запроса и ответа имеют header padding.
• Обратите внимание, что если для stream-one указан /yourpath, фактический запрос отправляется на /yourpath/. Если / в конце отсутствует, он добавляется автоматически.
• Загрузка по умолчанию имеет Content-Type: application/grpc для маскировки под gRPC (можно отключить с помощью noGRPCHeader).
• Заголовки ответа сервера для выгрузки идентичны заголовкам packet-up из пункта 1. В stream-one может возникнуть необычная ситуация, когда gRPC отвечает с помощью SSE. Если возникнут проблемы, попробуйте noSSEHeader.

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

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

Тогда те, кто часто использует gRPC, спросят: какие преимущества имеет stream-up по сравнению с транспортным уровнем gRPC?

• Первому не нужны никакие библиотеки gRPC, производительность выше.
• Исходящий трафик первого — это отдельные GET-запросы, не подверженные ограничениям CDN для трафика gRPC.
• Первый также имеет header padding, XMUX, разделение загрузки и выгрузки и другие улучшения, и уже внедрен механизм extra, все параметры можно передавать, более зрелое решение.

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

Разделение загрузки и выгрузки

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

"xhttpSettings": {
    "host": "example.com",
    "path": "/yourpath", // должен быть одинаковым
    "mode": "auto",
    "extra": {
        "headers": {
            // "key": "value"
        },
        "xPaddingBytes": "100-1000",
        "noGRPCHeader": false, // stream-up/one, только клиент
        "noSSEHeader": false, // только сервер
        "scMaxEachPostBytes": 1000000, // только packet-up
        "scMinPostsIntervalMs": 30, // packet-up, только клиент
        "scMaxBufferedPosts": 30, // packet-up, только сервер
        "scStreamUpServerSecs": "20-80", // stream-up, только сервер
        "xmux": { // в основном h2/h3, только клиент
            "maxConcurrency": "16-32",
            "maxConnections": 0,
            "cMaxReuseTimes": 0,
            "hMaxRequestTimes": "600-900",
            "hMaxReusableSecs": "1800-3000",
            "hKeepAlivePeriod": 0
        },
        "downloadSettings": { // только клиент
            "address": "", // другой домен/IP
            "port": 443,
            "network": "xhttp",
            "security": "tls",
            "tlsSettings": {
                ...
            },
            "xhttpSettings": {
                "path": "/yourpath", // должен быть одинаковым
                ...
            },
            "sockopt": {} // будет заменено на "sockopt", если в последнем "penetrate" равно true
        }
    }
}

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

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

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

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

Выше приведен пример конфигурации со всеми параметрами, главным образом для того, чтобы показать, где должен быть каждый параметр, и объяснить параметры, которые не были подробно рассмотрены в тексте:

• extra — это оригинальное решение для передачи всех параметров, кроме host, path и mode, в формате JSON. Когда extra присутствует, действуют только эти четыре параметра. И в ссылке для общего доступа есть только эти четыре параметра, как и в большинстве GUI, потому что параметры в extra используются относительно редко и должны предоставляться клиенту непосредственно поставщиком услуг, а не изменяться клиентом произвольно.
  Дополнение: «предоставляться» означает «предоставляться человеком», то есть поставщик услуг записывает extra и помещает его в ссылку для общего доступа, клиент использует его непосредственно как свой extra.

• Поведение host аналогично другим транспортным уровням Xray, основанным на HTTP. Приоритет отправки host клиентом: host > serverName > address. Если на сервере установлен host, он проверяет, совпадает ли значение, отправленное клиентом. В противном случае проверка не выполняется. Рекомендуется не устанавливать его без необходимости. host нельзя указывать в headers.

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

Beyond REALITY

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

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

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

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

• Всего тысяча штук, первые сто продаются по цене 0.01 ETH, последующие будут дороже, получить первые — это просто удача.
• Статья с описанием REALITY будет опубликована в ближайшие дни превратилась в статью с описанием XHTTP.
• Владельцы REALITY NFT получат ранний доступ к бета-тестированию нового клиента Xray, а также аирдроп следующего NFT, например,
• 1 января 2025 года владельцы Project X NFT получат два REALITY NFT.

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

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

• ETH/USDT/USDC: 0xDc3Fe44F0f25D13CACb1C4896CD0D321df3146Ee
• Project X NFT: Объявление о NFT от Project X #3633
• REALITY NFT: https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
• Иногда комиссия за газ в сети ETH непомерно высока, вы можете сначала добавить в избранное и купить, когда комиссия за газ будет относительно нормальной.

It's rumored that some CDNs are acting against using their services for proxy (not at a large scale yet)
maybe they had some agreements with governments

As someone who don't want to get banned by CDNs, i prefer WebSocket or gRPC w/o '/Tun', but not XHTTP with static URL Pattern and xPaddingBytes query string with many 0 data
And i had hope you add Xmux to gRPC, but instead you flagged it as deprecated

希望“无限”复用，可以将 maxConnections 设为 1。

尝试过 maxConnections: -1 其他 xmux 不配置，Nginx 1000 次复用（也可能是因为默认 cMaxReuseTimes: 64-128），用完并且旧连接还有子连接，新连接就“卡住”（开不了）
未配置任何 xmux，可见以下“错误”

2024/12/05 04:40:11 [Info] [3934265271] transport/internet/splithttp: failed to open https://s3.*.net:443/*/ > Post "https://s3.*.net:443/*/": H3_NO_ERROR: reached maximum number of requests

配置 xmux maxConnections: -1 时，也许也有，但没发现😇

https://t.me/projectXray/4100166?thread=4100095

建议文中优化下"extra"的说明：
一个月没追更新，完全不知道extra是干什么的，读完全篇还在考虑“服务器怎么下发extra部分的配置给客户端？”
然后又去找前面的release说明，读了一遍extra相关的文档 #4000 ，才搞明白extra是分享链接相关的配置。
可以把extra文档的链接放进正文，便于读者理解。

对于mode配置，也建议文中增加链接：#3994 #4071
同时在 #3994 文中中增加 stream-one。
修改：根据RPRX回复修改

如果正文没修改，读者对extra或mode有疑问，可以读这个回复里的链接

    "mux": {                                                          
                "enabled": true,                                   
                "concurrency": -1,                                 
                "xudpConcurrency": 1,                              
                "xudpProxyUDP443": "reject"                        
               }    

这种配置算“关闭了mux.cool(我理解是tcp的mux)纯xudp”吗？如果不是最佳实践 应该是怎样
还是说现有版本中,只要xmux工作正常 xudp这些都不再需要再手工设置

可否考虑在跑H3时，配置启用了cMaxLifetimeMs连接过期时间参数后，能把过期的主连接中的子连接迁移到新连接中，这样规避对UDP的Qos。

尝试理解下我们XTLS旗下一系列协议的关注点和逻辑，如果错了请 @RPRX 指正。

XTLS初代splice/direct/origin等----解决性能：
传统的 TLS over TLS 会有两层加密开销，而 XTLS 则将内层 TLS 数据直接无损嵌入/拼接到外层的 TLS 流中，使得表面上仍是单层 TLS，但实际上隐藏了代理流量。减少重复的加解密过程。在不牺牲安全性的前提下显著降低了 CPU 负载和加解密成本，从而提升性能。

VISION----解决TLS in TLS特征：
在多层 TLS 叠加（TLS in TLS）时，内层 TLS 握手与外层 TLS 存在两次交互，这个时序存在明显特征，可被GFW精准识别。VISION 的意义在于通过模拟时延与消息交换顺序，抹平这种不自然的时序特征，让多层 TLS 握手过程在外观上更接近真实的互联网流量，降低被识别的风险。

REALITY----解决SNI封锁问题：
大陆的SNI无法加密，因此GFW可以通过SNI进行识别和封锁。
REALITY 在 TLS 握手和证书传递等环节进行伪装，通过在双方握手中返回看似真实网站的证书和初始数据，让整个 TLS 连接和访问“大厂”HTTPS 网站的连接真假难辨。GFW若想封锁，需要冒着误伤真实网站的风险。

XHTTP----解决翻墙协议普遍存在的“单一隧道”特征：
传统协议（如 Shadowsocks、Vmess、Trojan等）通常只是把数据加密后通过特定端口连续传输，从外观上可以呈现出“稳定长时间加密流”的特征；审查者可以通过统计分析、长连接特征、数据传输模式来怀疑它是代理流量。
因此XHTTP 此次聚焦在应用层，对已加密的传输进一步包装成真实 HTTP 请求和响应。通过将上行数据拆分为多个看似正常的 POST 请求和参数随机化的 URL，下行数据伪装为大文件流式下载或 SSE（Server-Sent Events）的持续输出，它使流量行为与普通用户浏览、下载的模式非常接近。与传统的“加密隧道”相比，XHTTP 不再是一个稳定持续的数据管道，而是表面上由多个独立、零散且自然的 HTTP 交互组成，更像再常见不过的WEB访问动作。

Do I need add this option: "scStreamUpServerSecs": "20-80" to my server config.json or not?

因为找了一个略微丢包（2%左右）的vps，于是尝试xhttp+h3看看走udp的话能不能让连接状况好一些，不过发现了难受的地方，不知是nginx的问题还是xray的问题（或是vps的？）
配置用的XTLS/Xray-examples中的VLESS-XHTTP3-Nginx，基本没动。
测试时发现，短时间内发起代理请求，走h3和h2的响应都没有问题。但空闲的时间一长（超过5m），h3就会报错，马上重试又能连上。出错的错误是这样的：
2025/03/03 20:18:18.590864 [Info] [3717366876] transport/internet/splithttp: failed to GET https://******/06f8100c-a00f-4267-8ae9-4fd4169dd8ae?x_padding=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > Get "https://******/06f8100c-a00f-4267-8ae9-4fd4169dd8ae?x_padding=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX": Application error 0x100 (remote): keepalive timeout
找了一圈发现nginx中的配置keepalive_timeout 5m;正好与这个错误有直接关系，改成几分钟，空闲的时间过长会出错的时间就变成几分钟。
于是抓包看了一下，xray很兢兢业业的按照10s的间隔发包keepalive，nginx也都有回包。直到keepalive_timeout设置的时长之后，nginx主动发了一个包给xray，xray于是停止发送keepalive包，client和server间通信停止。
此时再发起代理请求的话，xray的client和server间没有任何通信，而client直接甩出上面的错误。此时整个流程结束，之后发起代理请求client又重新恢复和server的通信。
感觉似乎nginx和xray有点沟通问题，xray的keepalive nginx不认，依旧按照自己的配置时间中止空闲连接。而xray接到nginx中止连接的包以后，直到下次代理请求才重置连接的状态，而且也没能自动重新发起连接。
说实话，这vps和我的网络也可能有点问题，ssh连接空闲超过5m也必然断开。

暂时没有更多的时间来测试，等忙完周末再看看

我正在用谷歌翻译用中文写文章。如果我的文字不正确，请原谅。