From 7960918e4d2eb80bb8e29356e63e90a716cc1241 Mon Sep 17 00:00:00 2001 From: Nikita Korotaev Date: Sun, 14 Jul 2024 18:52:45 +0500 Subject: [PATCH] translate /config/transports/splithttp.md --- docs/ru/config/transports/splithttp.md | 81 ++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 docs/ru/config/transports/splithttp.md diff --git a/docs/ru/config/transports/splithttp.md b/docs/ru/config/transports/splithttp.md new file mode 100644 index 0000000..ed9c995 --- /dev/null +++ b/docs/ru/config/transports/splithttp.md @@ -0,0 +1,81 @@ +# SplitHTTP + + + +Используется для загрузки с помощью 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 /`. Сервер немедленно отвечает `200 OK` и `Transfer Encoding:chunked` и немедленно отправляет двухбайтовую полезную нагрузку, чтобы принудительно обновить заголовки HTTP-прокси. + +2. Отправка данных начинается с `POST //`. `seq` действует как порядковый номер TCP, начиная с 0, пакеты данных могут отправляться одновременно, сервер должен пересобрать данные по порядковому номеру. Порядковый номер не следует сбрасывать. + + Клиент может свободно выбирать порядок открытия исходящих и нисходящих запросов, любой из них может инициировать сеанс, но соединение `GET` должно быть открыто в течение 30 секунд, иначе сеанс будет разорван. + +4. Запрос `GET` будет оставаться открытым до тех пор, пока соединение не будет разорвано, и сервер, и клиент могут закрыть соединение. Конкретное поведение зависит от версии HTTP. + +Рекомендации: + +* Не ожидайте, что CDN будет правильно передавать все заголовки, цель этого протокола — обойти CDN, не поддерживающие WS, а поведение этих CDN обычно не очень дружелюбное. + +* Следует предполагать, что все HTTP-соединения не поддерживают потоковые запросы, поэтому размер каждого пакета, отправляемого исходящим соединением, должен определяться с учетом задержки, пропускной способности и ограничений самого промежуточного сервера (аналогично MTU TCP и алгоритму Нейгла). + +* Что касается версии HTTP, ядро в настоящее время не поддерживает h2c, поэтому Xray будет отправлять только запросы http/1.1 при использовании без HTTPS. Чтобы избежать дополнительных сложностей, связанных с согласованием ALPN, клиент Xray использует h2 при использовании HTTPS (если только alpn не указан вручную как http/1.1 в tlsSettings), а сервер Xray совместим с различными типами входящих подключений (h3 пока нет), поскольку входящие соединения могут быть различных типов из-за промежуточных серверов.