# 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).