1
0
mirror of https://github.com/XTLS/Xray-docs-next.git synced 2025-08-22 19:38:36 +00:00

Update xhttp.md

This commit is contained in:
Semyon Saprykin 2025-05-09 12:23:31 +00:00 committed by GitHub
parent 5b939c1474
commit f5623ac7e3
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -1,3 +1,420 @@
# XHTTP: Beyond REALITY
# XHTTP
See [XHTTP: Beyond REALITY](https://github.com/XTLS/Xray-core/discussions/4113#discussioncomment-11468947)
## Введение
XHTTP представляет собой транспортный уровень, разработанный для Xray-core. Его разработка началась в середине 2024 года командой, включающей @mmmray и @ll11l1lIllIl1lll, на основе принципа "раздельная пакетная отправка, потоковая загрузка" (SplitHTTP), предложенного @RPRX. Первоначальная реализация позволила обходить большинство промежуточных HTTP-устройств без ущерба для эффективности загрузки и впервые массово реализовала QUIC H3 через CDN.
Впоследствии @RPRX продолжил разработку, реализовав разделение исходящего и входящего трафика и переименовав проект в XHTTP. Были добавлены такие функции, как Browser Dialer, header padding, управление мультиплексированием (XMUX), режим потоковой отправки (stream-up) с маскировкой заголовков gRPC, и интеграция стандартного HTTP-транспорта как режима stream-one. XHTTP нацелен на обеспечение гибкого обхода промежуточных устройств, разделение трафика и мультиплексирование.
Данный документ описывает принципы работы и параметры конфигурации XHTTP.
## Руководство по быстрому старту
Несмотря на большое количество параметров XHTTP, большинство из них имеют значения по умолчанию. Для базовой настройки XHTTP обычно достаточно выполнить следующие шаги:
1. Независимо от использования TLS или REALITY, для настройки XHTTP, как правило, достаточно указать только `path`. Остальные параметры можно оставить без изменений.
2. Если серверная сторона поддерживает QUIC H3, клиент может использовать QUIC, указав в `alpn` значение `"h3"`.
3. Для выбора IP-адреса CDN на стороне клиента, укажите IP-адрес в поле `address` и доменное имя в `serverName` (SNI).
4. При возникновении проблем с подключением через Cloudflare (CF), убедитесь, что поддержка gRPC включена на панели управления CF.
5. При использовании Nginx в качестве обратного прокси и возникновении проблем, попробуйте изменить `proxy_pass` на `grpc_pass` в конфигурации Nginx.
6. Для максимальной совместимости при прохождении через различные CDN или обратные прокси, рекомендуется установить `mode` в значение `"packet-up"`.
XHTTP по умолчанию использует мультиплексирование, что может обеспечивать меньшую задержку по сравнению с некоторыми другими механизмами. Для тестов скорости, ориентированных на максимальную пропускную способность одного потока, может потребоваться установка `"maxConcurrency": 1` (см. раздел [XMUXObject](#xmuxobject)).
Cloudflare разрывает HTTP-соединения, по которым не передаются данные, в течение 100 секунд. Для поддержания долговременных соединений (например, SSH) через прокси, необходимо реализовать механизм keep-alive на уровне приложения (например, `ClientAliveInterval` в `sshd_config`).
## Основные концепции
Фундаментальная логика XHTTP, как и у REALITY, заключается в маскировке трафика таким образом, чтобы его блокировка создавала значительный "сопутствующий ущерб" для цензоров, делая её нецелесообразной. Опыт показывает, что IP-адреса крупных CDN редко подвергаются полной перманентной блокировке из-за влияния на множество легитимных веб-сайтов.
XHTTP стремится работать через различные CDN. Однако CDN и многие промежуточные HTTP-устройства часто буферизуют HTTP-запросы перед отправкой на исходный сервер (за исключением специально поддерживаемых протоколов, таких как WebSocket и gRPC). Для обхода этого XHTTP использует следующие подходы:
1. **"Потоковая выгрузка" (Stream Download/Downstream):** При загрузке данных с сервера (например, при скачивании файла), если CDN не находит данные в кэше, он запрашивает их у исходного сервера. CDN не кэширует весь файл перед отправкой клиенту, а передает данные по мере их поступления от исходного сервера. Это обеспечивает максимальную скорость загрузки.
2. **"Пакетная загрузка" (Packet Upload/Upstream):** Изначально для исходящего трафика (upload) XHTTP реализовывал упаковку данных в отдельные POST-запросы. Это снижает эффективность по сравнению с потоковой передачей, но обеспечивает высокую совместимость. Объем исходящего трафика для типичных прокси-сценариев обычно невелик.
3. **"Потоковая загрузка" (Stream Upload/Upstream):** Позже был добавлен режим потоковой загрузки, который, в сочетании с маскировкой заголовков gRPC, позволяет использовать потоковую передачу H2 через CDN (например, Cloudflare). Оптимизации режима "пакетной загрузки" также приблизили его производительность к "потоковой загрузке".
Использование CDN для проксирования трафика является вынужденной мерой в условиях цензуры, направленной на смешивание с "нормальными" сервисами для увеличения "сопутствующего ущерба" при блокировках.
## Режим PACKET-UP
Режим `packet-up` ("пакетная загрузка, потоковая выгрузка") обеспечивает максимальную совместимость. Его работа основана на следующей схеме:
* **Передача данных клиентом:**
* Клиент отправляет данные методом POST на путь вида `/yourpath/sameUUID/seq`.
* `sameUUID`: Случайно генерируемый UUID, используемый для идентификации сессии на сервере. Если сервер не может связать запросы в течение 30 секунд, сеанс завершается.
* `seq`: Порядковый номер пакета, начиная с 0. Следующий POST-запрос отправляется после передачи тела предыдущего (ожидание ответа не требуется).
* Сервер пересобирает пакеты по `seq`, так как они могут приходить не по порядку. По умолчанию кэшируется до 30 запросов; превышение лимита ведет к разрыву соединения.
* UUID и `seq` передаются в пути URL, а не в строке запроса.
* **Запуск загрузки клиентом (получение данных от сервера):**
* Клиент отправляет 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 не требуется).
* **Заголовки для Browser Dialer (CORS):**
* Для всех GET и POST-ответов сервер добавляет:
* `Access-Control-Allow-Origin: *`
* `Access-Control-Allow-Methods: GET, POST`
* **Header Padding (Заполнение заголовков):**
* Запрос клиента: По умолчанию содержит заголовок `Referer: ...?x_padding=XXX...`. Длина заполнения 100-1000 символов (случайно для каждого запроса). Сервер проверяет длину.
* Ответ сервера: По умолчанию содержит заголовок `X-Padding: XXX...`. Длина заполнения 100-1000 символов (случайно для каждого ответа).
* Соответствующий параметр конфигурации: `xPaddingBytes`.
Сервер также может использовать заголовок `X-Forwarded-For` для определения реального IP-адреса клиента и проверять заголовок `Host` на основе серверной конфигурации `host`.
Для управления POST-запросами в режиме `packet-up` используются следующие параметры в объекте `extra` (см. [ExtraObject](#extraobject)):
* `scMaxEachPostBytes`: Максимальный размер данных в каждом POST-запросе.
* `scMinPostsIntervalMs`: Минимальный интервал между POST-запросами (только клиент).
* `scMaxBufferedPosts`: Максимальное количество кэшируемых POST-запросов (только сервер).
Эти параметры могут принимать диапазонные значения (например, `"500000-1000000"`) для случайного выбора, что уменьшает предсказуемость.
## Версии HTTP: H1 / H2 / H3
XHTTP гибко работает с различными версиями HTTP, учитывая особенности промежуточных устройств, таких как CDN и Nginx, которые могут преобразовывать версии HTTP (например, H3 от клиента в H1/H2 к исходному серверу).
* **Сервер XHTTP:**
* По умолчанию прослушивает TCP-порт и обрабатывает трафик H1 и H2.
* При включении TLS и указании только `"h3"` в `alpn`, сервер будет использовать `quic-go` для прослушивания UDP-порта и обработки H3. Однако рекомендуется скрывать XHTTP за полноценными веб-серверами (Nginx, Caddy) для уменьшения цифровых отпечатков, вместо прямого прослушивания H3.
* **Клиент XHTTP:**
* При включении TLS/REALITY: по умолчанию используется H2.
* Без TLS/REALITY: по умолчанию используется HTTP/1.1.
* При включении TLS и `alpn` содержит только `"http/1.1"`: используется HTTP/1.1.
* При включении TLS и `alpn` содержит только `"h3"`: используется `quic-go` H3.
* При использовании Browser Dialer: версия HTTP определяется браузером, `tlsSettings` игнорируются.
Для отслеживания фактической версии HTTP, используемой клиентом, а также другой информации, установите уровень логирования Xray в `"info"`.
Проксирование QUIC H3 через CDN является одной из ключевых возможностей XHTTP.
## Мультиплексирование (XMUX)
HTTP/2 и HTTP/3 поддерживают мультиплексирование (передачу нескольких логических потоков данных через одно физическое соединение) и 0-RTT. H3 дополнительно решает проблему блокировки начала очереди (Head-of-Line blocking) на уровне TCP и поддерживает миграцию соединения. XHTTP предоставляет интерфейс XMUX для управления мультиплексированием на стороне клиента (см. [XMUXObject](#xmuxobject) для параметров конфигурации).
Параметры XMUX можно комбинировать. Если ни один параметр XMUX не указан, используются значения по умолчанию для `maxConcurrency`, `hMaxRequestTimes` и `hMaxReusableSecs`, что приводит к периодической смене основного H2/H3 соединения. Если указан хотя бы один параметр XMUX, остальные неуказанные параметры (кроме `hKeepAlivePeriod`) по умолчанию принимают значение `0` (или специфичное для параметра значение, означающее "без ограничений").
**Примечание:** При использовании XHTTP не следует включать `mux.cool` в конфигурации Xray.
Значения по умолчанию для XMUX выбраны таким образом, чтобы уменьшить предсказуемость и избежать проблем с длительным использованием одного соединения, которые могут возникнуть с некоторыми промежуточными устройствами (например, Nginx, который имеет свои лимиты на количество запросов и время жизни соединения).
## Режимы STREAM-UP / STREAM-ONE
Эти режимы реализуют "потоковую загрузку, потоковую выгрузку".
* **`stream-up`**: Использует два HTTP-запроса: один POST для исходящего потока (upload) и один GET для входящего потока (download).
* **`stream-one`**: Использует один HTTP POST-запрос для двунаправленной потоковой передачи.
Поведение по умолчанию для параметра `mode: "auto"`:
* **Клиент:**
* `stream-up` для TLS H2.
* `stream-one` для REALITY (или `stream-up`, если настроен `downloadSettings`).
* В остальных случаях `packet-up`.
* **Сервер:**
* По умолчанию принимает все три режима (`packet-up`, `stream-up`, `stream-one`).
* Если `mode` на сервере указан как `stream-up`, он также будет принимать `stream-one`.
**Особенности реализации:**
* **`stream-up`**: Исходящий поток (upload) использует потоковый POST на `/yourpath/sameUUID`. Используется `Referer: ...?x_padding=XXX...`. Входящий поток (download) аналогичен `packet-up`.
* **`stream-one`**: Используется POST на `/yourpath/` (слеш в конце важен и добавляется автоматически, если отсутствует). Тело запроса - исходящий поток, тело ответа - входящий. Заголовки запроса и ответа имеют header padding.
* **Маскировка gRPC:** По умолчанию для исходящего потока в `stream-up` и `stream-one` используется `Content-Type: application/grpc` (можно отключить с `noGRPCHeader`). Это позволяет проходить через Cloudflare (с включенной поддержкой gRPC) и Nginx (рекомендуется `grpc_pass`).
* **Маскировка SSE:** Заголовки ответа сервера для входящего потока аналогичны `packet-up` (включая `Content-Type: text/event-stream`). В `stream-one` это может привести к ситуации, когда gRPC-подобный запрос получает SSE-подобный ответ. При проблемах можно использовать `noSSEHeader`.
* **Поддержание активности `stream-up`:** Cloudflare разрывает HTTP-соединения без передачи данных в течение 100 секунд. Для `stream-up` сервер по умолчанию периодически (каждые `scStreamUpServerSecs` секунд, по умолчанию `"20-80"`) отправляет пакеты заполнения (`xPaddingBytes`) для поддержания активности соединения загрузки (download). Можно отключить, установив `scStreamUpServerSecs: -1`.
**Преимущества `stream-up``stream-one`) по сравнению с нативным gRPC-транспортом Xray:**
* Не требуют библиотек gRPC, потенциально выше производительность.
* Входящий трафик (download) в `stream-up` идет через отдельные GET-запросы, что может быть менее подвержено ограничениям CDN для gRPC-трафика.
* Поддерживают header padding, XMUX, разделение загрузки/выгрузки и передачу параметров через `extra`.
## Разделение загрузки и выгрузки
XHTTP позволяет разделить потоки загрузки (upload, исходящий от клиента) и выгрузки (download, входящий к клиенту) на разные соединения. Это может усложнить обнаружение трафика, так как характеристики соединений могут различаться (например, upload по IPv4 TCP, download по IPv6 UDP). Сервер XHTTP связывает потоки по UUID в пути запроса. Режимы `packet-up` и `stream-up` изначально поддерживают такое разделение.
Для настройки разделения на клиенте используется объект `downloadSettings` внутри `extra` (см. [DownloadSettingsObject](#downloadsettingsobject)). Этот объект, по сути, определяет новый `streamSettings` для входящего потока.
**Примеры использования:**
* Использование разных IP-адресов или доменов для upload и download через CDN.
* Использование разных версий IP (IPv4/IPv6) или протоколов (TCP/UDP для QUIC) для разных потоков.
* Использование разных `serverName` (SNI) для upload и download при работе с CDN, поддерживающими префиксы одного домена, при общем `host`.
* Комбинация с REALITY: два VPS с REALITY, настроенные так, чтобы трафик с одинаковым путем попадал на один и тот же входящий XHTTP.
Конфигурация потока выгрузки (download) полностью независима от потока загрузки (upload), за исключением особого случая с `sockopt.penetrate`. Параметры, такие как XMUX, также настраиваются и выбираются случайно (если задан диапазон) независимо для каждого потока.
## Конфигурация XHTTP
Объект `XHTTPSettingsObject` определяет конфигурацию транспортного протокола XHTTP. Он указывается в поле `xhttpSettings` объекта `TransportObject` или `StreamSettingsObject`.
```json
{
"host": "example.com",
"path": "/yourpath",
"mode": "auto",
"extra": {
"headers": {
// "key": "value"
},
"xPaddingBytes": "100-1000",
"noGRPCHeader": false,
"noSSEHeader": false,
"scMaxEachPostBytes": 1000000,
"scMinPostsIntervalMs": 30,
"scMaxBufferedPosts": 30,
"scStreamUpServerSecs": "20-80",
"xmux": {
"maxConcurrency": "16-32",
"maxConnections": 0,
"cMaxReuseTimes": 0,
"hMaxRequestTimes": "600-900",
"hMaxReusableSecs": "1800-3000",
"hKeepAlivePeriod": 0
},
"downloadSettings": {
"address": "",
"port": 443,
"network": "xhttp",
"security": "tls",
"tlsSettings": {
// ...
},
"xhttpSettings": {
"path": "/yourpath"
// ... другие параметры XHTTPSettingsObject для скачивания
},
"sockopt": {}
}
}
}
```
> `host`: string
>
> Имя хоста, которое будет отправлено в HTTP-заголовке `Host`.
> Приоритет выбора значения `Host` клиентом: значение из этого поля `host` > `serverName` из `tlsSettings` > `address` из `streamSettings`.
> Если на сервере указан `host`, он будет проверять совпадение со значением, отправленным клиентом. Если на сервере `host` не указан, проверка не производится. Рекомендуется не устанавливать без необходимости.
> Нельзя указывать `Host` в `extra.headers`.
> Значение по умолчанию: `""` (пустая строка).
> `path`: string
>
> Путь HTTP-запроса. Должен быть одинаковым для клиента и сервера. При использовании разделения загрузки/выгрузки (`downloadSettings`), `path` должен быть одинаковым для основного потока и потока `downloadSettings`.
> Пример: `"/yourpath"`.
> Значение по умолчанию: `""` (пустая строка, но обычно требуется указать).
> `mode`: "auto" | "packet-up" | "stream-up" | "stream-one"
>
> Режим работы XHTTP.
> * `"auto"`: Режим выбирается автоматически (см. раздел [Режимы STREAM-UP / STREAM-ONE](#режимы-stream-up--stream-one) для деталей).
> * `"packet-up"`: Режим "пакетная загрузка, потоковая выгрузка". Максимальная совместимость.
> * `"stream-up"`: Режим "потоковая загрузка, потоковая выгрузка" (два HTTP-запроса). Сервер, настроенный на `stream-up`, также принимает `stream-one`.
> * `"stream-one"`: Режим "потоковая загрузка, потоковая выгрузка" (один HTTP-запрос).
> Значение по умолчанию: `"auto"`.
> `extra`: [ExtraObject](#extraobject)
>
> Объект с дополнительными параметрами конфигурации. Если `extra` присутствует, то на верхнем уровне `xhttpSettings` действуют только `host`, `path`, `mode` и сам `extra`. Параметры внутри `extra` обычно предоставляются клиенту поставщиком услуг.
> Значение по умолчанию: отсутствует (эквивалентно пустому объекту `{}`).
### ExtraObject
`ExtraObject` соответствует полю `extra` в `XHTTPSettingsObject`.
```json
{
"headers": {
// "key": "value"
},
"xPaddingBytes": "100-1000",
"noGRPCHeader": false,
"noSSEHeader": false,
"scMaxEachPostBytes": 1000000,
"scMinPostsIntervalMs": 30,
"scMaxBufferedPosts": 30,
"scStreamUpServerSecs": "20-80",
"xmux": {
// ... см. XMUXObject
},
"downloadSettings": {
// ... см. DownloadSettingsObject
}
}
```
> `headers`: map{string, string}
>
> Пользовательские HTTP-заголовки, добавляемые к каждому запросу.
> Ключ — имя заголовка, значение — значение заголовка.
> Пример: `{ "User-Agent": "MyCustomClient" }`.
> Заголовок `Host` здесь указывать нельзя; используйте поле `host` в `XHTTPSettingsObject`.
> Значение по умолчанию: `{}` (пустой объект).
> `xPaddingBytes`: string
>
> Размер случайного заполнения (padding) в байтах, добавляемого в HTTP-заголовки (`Referer` для запросов, `X-Padding` для ответов).
> Может быть указано как одно число (например, `"200"`) или диапазон (например, `"100-1000"`), из которого будет выбрано случайное значение.
> Значение по умолчанию: `"100-1000"`.
> `noGRPCHeader`: true | false
>
> Только для клиента, в режимах `stream-up` и `stream-one`.
> Если `true`, отключает добавление заголовка `Content-Type: application/grpc`.
> Значение по умолчанию: `false`.
> `noSSEHeader`: true | false
>
> Только для сервера.
> Если `true`, отключает добавление заголовка `Content-Type: text/event-stream` в ответах сервера.
> Значение по умолчанию: `false`.
> `scMaxEachPostBytes`: integer | string
>
> Только для режима `packet-up`. Максимальный размер данных (в байтах) в каждом POST-запросе клиента.
> Может быть указано как целое число или строка-диапазон (например, `"500000-1000000"`).
> Значение по умолчанию: `1000000` (1 МБ).
> `scMinPostsIntervalMs`: integer | string
>
> Только для режима `packet-up` и только для клиента. Минимальный интервал (в миллисекундах) между отправкой POST-запросов для одного прокси-соединения.
> Может быть указано как целое число или строка-диапазон (например, `"10-50"`).
> Значение по умолчанию: `30`.
> `scMaxBufferedPosts`: integer
>
> Только для режима `packet-up` и только для сервера. Максимальное количество POST-запросов от клиента, которые сервер может буферизовать для одного прокси-соединения.
> Значение по умолчанию: `30`.
> `scStreamUpServerSecs`: string | integer
>
> Только для режима `stream-up` и только для сервера. Интервал (в секундах), через который сервер отправляет пакеты заполнения для поддержания активности соединения загрузки (download).
> Может быть указано как строка-диапазон (например, `"20-80"`) или целое число.
> Значение `-1` отключает этот механизм.
> Значение по умолчанию: `"20-80"`.
> `xmux`: [XMUXObject](#xmuxobject)
>
> Настройки мультиплексирования соединений (в основном для H2/H3). Только для клиента.
> Значение по умолчанию: `{}` (применяются специфические значения по умолчанию для полей `XMUXObject`, если ни одно из них не указано).
> `downloadSettings`: [DownloadSettingsObject](#downloadsettingsobject)
>
> Только для клиента. Конфигурация для разделения потока загрузки (download) на отдельное соединение.
> Значение по умолчанию: отсутствует.
#### XMUXObject
`XMUXObject` соответствует полю `xmux` в `ExtraObject`. Применяется на стороне клиента, в основном для HTTP/2 и HTTP/3.
```json
{
"maxConcurrency": "16-32",
"maxConnections": 0,
"cMaxReuseTimes": 0,
"hMaxRequestTimes": "600-900",
"hMaxReusableSecs": "1800-3000",
"hKeepAlivePeriod": 0
}
```
::: tip
Если ни один из параметров `XMUXObject` не указан, то для `maxConcurrency`, `hMaxRequestTimes` и `hMaxReusableSecs` будут использованы значения по умолчанию, указанные ниже. Если хотя бы один параметр `XMUXObject` указан, то для остальных неуказанных параметров значения по умолчанию будут `0` (или специфичные для параметра, если `0` не является стандартным отсутствием ограничения). `maxConcurrency` и `maxConnections` конфликтуют; можно использовать только один из них.
:::
> `maxConcurrency`: string | integer
>
> Максимальное количество одновременных прокси-запросов на одном TCP/QUIC-соединении.
> Может быть указано как целое число или строка-диапазон (например, `"16-32"`).
> Значение по умолчанию: `"16-32"`, если все параметры XMUX не заданы. Иначе, если `maxConnections` не задан, то `0` (без ограничений, но обычно не рекомендуется).
> `maxConnections`: integer | string
>
> Максимальное количество одновременных TCP/QUIC-соединений.
> Может быть указано как целое число или строка-диапазон.
> Значение по умолчанию: `0` (без ограничений).
> `cMaxReuseTimes`: integer | string
>
> Максимальное количество раз, которое одно TCP/QUIC-соединение может быть повторно использовано для новых прокси-запросов.
> Может быть указано как целое число или строка-диапазон.
> Значение по умолчанию: `0` (без ограничений).
> `hMaxRequestTimes`: string | integer
>
> Максимальное количество HTTP-запросов на каждом TCP/QUIC-соединении.
> Может быть указано как целое число или строка-диапазон (например, `"600-900"`).
> Значение по умолчанию: `"600-900"`, если все параметры XMUX не заданы. Иначе `0` (без ограничений).
> `hMaxReusableSecs`: string | integer
>
> Максимальное время (в секундах), в течение которого TCP/QUIC-соединение может быть повторно использовано для новых HTTP-запросов.
> Может быть указано как целое число или строка-диапазон (например, `"1800-3000"`).
> Значение по умолчанию: `"1800-3000"`, если все параметры XMUX не заданы. Иначе `0` (без ограничений).
> `hKeepAlivePeriod`: integer
>
> Интервал (в секундах) отправки keep-alive пакетов (HTTP PING frame) в неактивном H2/H3 соединении.
> `0` соответствует поведению по умолчанию (45с для Chrome H2, 10с для quic-go H3).
> Отрицательное значение (например, `-1`) отключает keep-alive.
> Не допускает указание диапазона.
> Значение по умолчанию: `0`.
#### DownloadSettingsObject
`DownloadSettingsObject` соответствует полю `downloadSettings` в `ExtraObject`. Используется для настройки отдельного потока для скачивания (входящего трафика к клиенту).
```json
{
"address": "",
"port": 443,
"network": "xhttp",
"security": "tls",
"tlsSettings": {
// ... стандартные tlsSettings
},
"xhttpSettings": {
"path": "/yourpath", // должен быть таким же, как и в основной конфигурации
// ... другие параметры XHTTPSettingsObject, специфичные для скачивания
},
"sockopt": {
// ... стандартные sockopt
}
}
```
> `address`: string
>
> Адрес сервера для потока скачивания.
> Значение по умолчанию: `""`.
> `port`: integer
>
> Порт сервера для потока скачивания.
> Значение по умолчанию: `443`.
> `network`: string
>
> Тип сети. Для разделения потоков XHTTP **должен** быть `"xhttp"`.
> Значение по умолчанию: отсутствует (должен быть указан как `"xhttp"`).
> `security`: string
>
> Тип безопасности соединения (`"tls"` или `"reality"`).
> Значение по умолчанию: отсутствует (должен быть указан).
> `tlsSettings`: object
>
> Настройки TLS (стандартный объект `tlsSettings` Xray), если `security` установлено в `"tls"`.
> Значение по умолчанию: `{}`.
> `xhttpSettings`: [XHTTPSettingsObject](#конфигурация-xhttp)
>
> Специфичные настройки XHTTP для потока скачивания. `path` должен совпадать с основным. Другие параметры (например, `mode`, `extra` без вложенного `downloadSettings`) могут быть настроены независимо.
> Значение по умолчанию: `{}`.
> `sockopt`: object
>
> Настройки сокета (стандартный объект `sockopt` Xray). Если `penetrate: true`, `sockopt` потока скачивания переопределит `sockopt` потока загрузки.
> Значение по умолчанию: `{}`.
## Заключение
XHTTP представляет собой многофункциональный транспортный уровень, разработанный с акцентом на гибкость, производительность и возможности обхода ограничений. Он может использоваться совместно с REALITY и другими технологиями Xray. Его архитектура позволяет применять различные методы маскировки трафика, разделять потоки данных и эффективно работать через CDN, поддерживая современные веб-протоколы, такие как HTTP/2 и QUIC H3.