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:
parent
5b939c1474
commit
f5623ac7e3
@ -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.
|
||||
|
Loading…
Reference in New Issue
Block a user