From 7da7b1acbc1ecd5ce8defd02ce5bdd660bed5a78 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E9=A3=8E=E6=89=87=E6=BB=91=E7=BF=94=E7=BF=BC?= Date: Tue, 18 Jun 2024 22:00:51 +0800 Subject: [PATCH] Refine splithttp docs --- docs/config/transports/splithttp.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/docs/config/transports/splithttp.md b/docs/config/transports/splithttp.md index c0778eeee..083c43b39 100644 --- a/docs/config/transports/splithttp.md +++ b/docs/config/transports/splithttp.md @@ -5,11 +5,11 @@ 可以通过不支持WebSocket的CDN上，但仍有一些要求： -- CDN必须支持HTTP分块传输，而且不会缓冲响应，核心将会发送 `X-Accel-Buffering: no` 以告知CDN，但是需要CDN遵守此标头。 +- CDN必须支持HTTP分块传输，且支持流式传输不会缓冲响应，核心将会发送 `X-Accel-Buffering: no` 以告知CDN，但是需要CDN遵守此标头。 - 如果连接被挂起，该传输很可能无法工作 + 如果连接被挂起，该传输很可能无法工作。 -- CDN必须禁用缓存, 或者缓存查询字符串包含查询字符串。 +- CDN必须禁用缓存, 或者缓存不忽略查询字符串。 上行效率可能非常有限 @@ -26,6 +26,8 @@ The `SplitHttpObject` 对应传输配置的 `splithttpSettings` 项。 "headers": { "key": "value" } + "maxUploadSize": 1000000, + "maxConcurrentUploads": 10 } ``` @@ -47,7 +49,7 @@ WebSocket 的HTTP请求中所发送的host，默认值为空。若服务端值 > `maxUploadSize`: int -上传分块的最大大小，默认为 1 MB. +上传分块的最大大小，单位为字节，默认为 1 MB. 这个值应该小于CDN或其他HTTP反向代理所允许的最大请求体，否则将抛出 HTTP 413 错误。 @@ -63,20 +65,20 @@ WebSocket 的HTTP请求中所发送的host，默认值为空。若服务端值 ## 已知问题 -* ALPN 协商仍未正确实现，HTTPS连接将总是使用H2. +* ALPN 协商仍未正确实现，HTTPS连接将默认使用H2。 ## 协议细节 讨论与建议详见 [PR](https://github.com/XTLS/Xray-core/pull/3412)，这里是实现简述。 -1. 使用 `GET /?session=UUID` 打开一个新的“虚拟”流连接。服务器立即回复 `200 OK` 和 `Transfer Encoding:chunked`, 并立即发送一个两字节的有效负载，以强制HTTP中间盒刷新标头。 +1. 使用 `GET /?session=UUID` 打开一个新的“虚拟”流连接。服务器立即回复 `200 OK` 和 `Transfer Encoding:chunked` , 并立即发送一个两字节的有效负载，以强制HTTP中间盒刷新标头。 -2. 一旦客户端完成协商，它可以使用 `POST /?session=UUID?seq=0` 开始发送上行数据. `seq` 作用类似于 TCP 序列号, 数据包可以被同时发送，服务端必须按序列号将数据重组。序列号不会重置 +2. 一旦客户端完成协商，它可以使用 `POST /?session=UUID?seq=0` 开始发送上行数据. `seq` 作用类似于 TCP 序列号, 数据包可以被同时发送，服务端必须按序列号将数据重组。序列号不会重置。 -3. `GET` 请求将一直保持在打开状态直到连接被终止，服务端和客户端都可以关闭连接。具体行为取决于HTTP版本 +3. `GET` 请求将一直保持在打开状态直到连接被终止，服务端和客户端都可以关闭连接。具体行为取决于HTTP版本。 建议: * 不要假设CDN会正确传输所有标头，这个协议是为了穿透不支持WS的CDN设计的，这些CDN的架构通常不怎么友好。 -* 应该假设所有HTTP连接都没有流式传输，所以每个包的大小应该基于延迟、吞吐量以及中间盒本身的限制考虑(类似TCP的MTU与纳格算法)。 +* 应该假设所有HTTP连接都没有流式请求，所以每个包的大小应该基于延迟、吞吐量以及中间盒本身的限制考虑(类似TCP的MTU与纳格算法)。