XHTTP: 池化的 HTTP/1.1 上传连接仅由 GC 关闭
作者: StateException创建于 2026年7月31日更新于 2026年9月11日
- 廉正要求
- 我阅读了问题模板中的所有评论,并确保这一问题符合要求。
- [x]我确认我读过文件,理解我写的所有配置项目的含义,没有堆积看起来有用的选项或默认值.
- 我提供了完整的配置和日志, 而不是仅仅根据我自己的判断提供短片。
- 我搜索了问题 没有发现任何类似的问题。
- 这个问题可以在最新版本中成功复制
说明
我在调查为什么一个xhttp客户端比我预期的更开放的套接字,最后在HTTP/1.1上传路径中.
PostPacket ()' 将上传连接放入同步' 。 Pool ' 然后把他们带回下一个包:
就我所知,没有什么能关上他们 没有闲置的超时,没有大小限制,也没有可以关闭的所有人,所以集合连接一直开着,直到收藏家放下了池内的内容和基础的"网"的定稿器. 连线运行。
与其它所有文件相去甚远 相同的文件设置, 每个连接缓存都有闲置的束缚 :
http2. 运输 ' -- --时间长度:网.时间长度 ' (diale.go#L313)http.transport' -- --IdleConnTimeout: net.ConidleTimeout ' (diale.go#L324)- 精选 - 精选 MaxidleTimeout = net. CondleTimeout" (diale.go#L178) (中文(简体) ).
常数本身的读取 仿佛它意在覆盖一切:
开始 // 定义闲置的 TCP会话可以在隧道中生存的最大时间, 所以 / 它应当与HTTP版本和其他运输方式保持一致. Const ConnidleTimeout = 300 *时间. 第二届
为了保证它真的是负责收尾的收集者,而不是对等或内核,我用v26.3.27的回回转,"xhttp"+"packet-up"+"alpn: ["http/1.1"],每5秒对客户端出入口的 ESTABLSID套接器进行取样.
GOGC 默认顶点 39 套接字, 在 270 s 后为 0, 步数: 39 - > 31 - > 16 - > 0 GOGC=下峰54个插座,400 s后仍为46个,从未下降
随着收藏家离开 他们只是停留。 与GC周期相匹配的首个运行中的步骤。 Pool`:其受害者缓存在一个周期内活了下来,在第二个周期后死亡。
服务器也没有关闭它们 。 XHTTP的收听器只设置了 " ReadheaderTimeout " (hub.go#L584)和 " ReadTimeout " 未设置 " http " 。 服务器. IDlenTimeout ' 最终为零,因此从服务器方面看,这些只是闲置的保持式连接,没有人急于放弃。
然后,我用 " xmux " 进行了试验,期望退休的客户会带去其游泳池,但不会: " GetXmuxClient() " 将客户从切片上除去而无需关闭任何东西。 在与 " hmax Request Times: 10 " 的竞选中,有6人退休。
. . . . . . .
内容来源: XTLS/Xray-core