|
|
# SplitHTTP
|
|
|
|
|
|
<Badge text="v1.8.16+" type="warning"/>
|
|
|
|
|
|
Используется для загрузки с помощью HTTP-фрагментированной передачи, загрузка осуществляется с помощью нескольких HTTP POST-запросов.
|
|
|
|
|
|
Может использоваться через CDN, не поддерживающие WebSocket, но есть несколько требований:
|
|
|
|
|
|
- CDN должен поддерживать HTTP-фрагментированную передачу и потоковые ответы без буферизации. Ядро будет отправлять `X-Accel-Buffering: no` и `Content-Type: text/event-stream`, чтобы сообщить CDN об этом, но CDN должен соблюдать этот заголовок. Если промежуточный сервер не поддерживает потоковые ответы и зависает, передача, скорее всего, не будет работать.
|
|
|
|
|
|
Цель та же, что и у V2fly Meek, но благодаря использованию фрагментированной загрузки скорость загрузки выше, а скорость отдачи оптимизирована, но все еще очень ограничена, поэтому к HTTP-прокси предъявляются более высокие требования (см. выше).
|
|
|
|
|
|
`SplitHTTP` также принимает заголовок `X-Forwarded-For`.
|
|
|
|
|
|
## SplitHttpObject
|
|
|
|
|
|
`SplitHttpObject` соответствует элементу `splithttpSettings` в конфигурации транспорта.
|
|
|
|
|
|
```json
|
|
|
{
|
|
|
"path": "/",
|
|
|
"host": "xray.com",
|
|
|
"headers": {
|
|
|
"key": "value"
|
|
|
},
|
|
|
"maxUploadSize": 1000000,
|
|
|
"maxConcurrentUploads": 10
|
|
|
}
|
|
|
```
|
|
|
|
|
|
> `path`: string
|
|
|
|
|
|
Путь HTTP-протокола, используемый SplitHTTP, значение по умолчанию — `"/"`.
|
|
|
|
|
|
> `host`: string
|
|
|
|
|
|
Хост, отправляемый в HTTP-запросе SplitHTTP, по умолчанию пуст. Если значение на стороне сервера пустое, значение хоста, отправленное клиентом, не проверяется.
|
|
|
|
|
|
Если это значение указано на стороне сервера или `host` указан в `headers`, то проверяется соответствие хоста запроса клиента.
|
|
|
|
|
|
Приоритет выбора хоста для отправки клиентом: `host` > `headers` > `address`.
|
|
|
|
|
|
> `headers`: map \{string: string\}
|
|
|
|
|
|
Пользовательские HTTP-заголовки, пары ключ-значение, где каждый ключ представляет имя HTTP-заголовка, а соответствующее значение является строкой.
|
|
|
|
|
|
> `maxUploadSize`: int
|
|
|
|
|
|
Максимальный размер фрагмента загрузки в байтах, по умолчанию 1 МБ.
|
|
|
|
|
|
Это значение должно быть меньше максимального размера тела запроса, разрешенного CDN или другим обратным HTTP-прокси, иначе будет выдаваться ошибка HTTP 413.
|
|
|
|
|
|
Увеличение этого значения может увеличить скорость загрузки.
|
|
|
|
|
|
> `maxConcurrentUploads`: int
|
|
|
|
|
|
Максимальное количество одновременных загрузок, по умолчанию 10, соединения будут использоваться повторно, насколько это возможно.
|
|
|
|
|
|
Если соединение нестабильно или потребление памяти на сервере слишком велико, попробуйте уменьшить это значение.
|
|
|
|
|
|
Значение, установленное клиентом, должно быть меньше, чем на сервере, иначе это может привести к проблемам с подключением.
|
|
|
|
|
|
## Детали протокола
|
|
|
|
|
|
Подробное обсуждение см. [#3412](https://github.com/XTLS/Xray-core/pull/3412) и [#3462](https://github.com/XTLS/Xray-core/pull/3462). Ниже приведено краткое описание и требования к совместимой реализации:
|
|
|
|
|
|
1. Загрузка начинается с `GET /<UUID>`. Сервер немедленно отвечает `200 OK` и `Transfer Encoding:chunked` и немедленно отправляет двухбайтовую полезную нагрузку, чтобы принудительно обновить заголовки HTTP-прокси.
|
|
|
|
|
|
2. Отправка данных начинается с `POST /<UUID>/<seq>`. `seq` действует как порядковый номер TCP, начиная с 0, пакеты данных могут отправляться одновременно, сервер должен пересобрать данные по порядковому номеру. Порядковый номер не следует сбрасывать.
|
|
|
|
|
|
Клиент может свободно выбирать порядок открытия исходящих и нисходящих запросов, любой из них может инициировать сеанс, но соединение `GET` должно быть открыто в течение 30 секунд, иначе сеанс будет разорван.
|
|
|
|
|
|
4. Запрос `GET` будет оставаться открытым до тех пор, пока соединение не будет разорвано, и сервер, и клиент могут закрыть соединение. Конкретное поведение зависит от версии HTTP.
|
|
|
|
|
|
Рекомендации:
|
|
|
|
|
|
* Не ожидайте, что CDN будет правильно передавать все заголовки, цель этого протокола — обойти CDN, не поддерживающие WS, а поведение этих CDN обычно не очень дружелюбное.
|
|
|
|
|
|
* Следует предполагать, что все HTTP-соединения не поддерживают потоковые запросы, поэтому размер каждого пакета, отправляемого исходящим соединением, должен определяться с учетом задержки, пропускной способности и ограничений самого промежуточного сервера (аналогично MTU TCP и алгоритму Нейгла).
|
|
|
|
|
|
* Что касается версий HTTP, ядро временно не поддерживает h2c, поэтому при отсутствии HTTPS Xray отправляет только запросы http/1.1.
|
|
|
|
|
|
Во избежание дополнительных сложностей, связанных с согласованием ALPN, клиент Xray использует h2 при использовании HTTPS. Вы также можете вручную указать alpn как http/1.1 или h3 в настройках TLS клиента, чтобы использовать соответствующую версию HTTP для отправки запросов. Сервер Xray, с другой стороны, совместим со всеми типами входящих соединений, включая h2c (h3 пока не поддерживается), поскольку входящие соединения могут использовать различные типы запросов из-за перенаправления через промежуточные узлы.
|
|
|
|
|
|
## BrowserDialer
|
|
|
|
|
|
При использовании HTTPS этот транспорт также поддерживает [BrowserDialer](../features/browser_dialer.md).
|
