XHTTP XMUX: Add hMaxRequestTimes and hKeepAlivePeriod

[RPRX]

#4113 (reply in thread) @xqzr 发现 Nginx 默认最多允许每条 TCP/QUIC 连接累计承载 1000 个 HTTP 请求，这个 PR：

1. 为 XMUX 新增 hMaxRequestTimes，XMUX 全为 0 时该项默认值为 "800600-900" 取随机，否则该项默认 0 即不限制。该项基于 HTTP 请求计数，一般来说 stream-one 只产生一个 HTTP 请求，stream-up 是两个，packet-up 则是 N 个。该项计数不严谨，且 Golang 的 GET 请求有自动重试，故不建议顶格填写，那些 CDN 什么的要试出来。其中 packet-up 上行循环 POST 时若超过该值会自动切换到另一个 TCP/QUIC 连接，占它一个 reuseTimes 但不占 concurrency。其实按 XMUX 的三项默认值，stream-* 不会超限，就 packet-up 会超，而它是 H3 的默认 mode，所以又主要是利好了 H3。顺手重构了 XMUX 相关的代码。

2. 任何请求收到 HTTP 响应但非 code 200 时，会将整条 TCP/QUIC 连接标记为 closed，以便 XMUX 不再向它分配新的请求。
   大概没到 HTTP 状态码那一步，但经讨论 err 和 StatusCode 的情况都挺复杂的，还需研究，这个 PR 先不处理、保持原样。
   XHTTP XMUX: Abandon client if client.Do(req) failed #4253
   顺手补了些 response.Body.Close()，据说一定要手动 Close() 不然会有内存泄漏，我不确定。

3. 将 keepAlivePeriod 移入 xmux 并更名为 hKeepAlivePeriod，默认 0，即 Chrome H2 的 45 秒，或 quic-go H3 的 10 秒。
   它是 XMUX 里唯一不允许填范围（该项取随机才是特征）且允许填负数（比如填 -1 关掉 H2/H3 的空闲保活包）的项。

4. XHTTP client: Refactor "packet-up" mode, chasing "stream-up" #4150 忘了改 JSON 为 scMaxBufferedPosts，改了。

5. ETH 涨涨跌跌，这两天没人买 NFT 了？如果加上 gas 费不划算，可以支持一个 Project X NFT，比较划算：

   • ETH/USDT/USDC: 0xDc3Fe44F0f25D13CACb1C4896CD0D321df3146Ee
   • Project X NFT: Announcement of NFTs by Project X #3633
   • REALITY NFT: XHTTP: Beyond REALITY #4113

[RPRX]

@xqzr 貌似是的，你看下 reached maximum number of requests 是 Nginx 发的吗，此时 HTTP 状态码是什么，5xx？

[xqzr]

reached maximum number of requests 是 Nginx 发的吗

是
https://github.com/nginx/nginx/blob/930caed3bfc84e43bf4bd034150c17604dc5dc73/src/http/v3/ngx_http_v3_request.c#L232

[RPRX]

不过 Xray 服务端一切正常时只会发 200，如果不是 200 那应该就是哪里出错了，所以代码逻辑好像没问题，你测测

[xqzr]

此时 HTTP 状态码是什么，5xx？

查找了当时的 Nginx 日志，没有相关行...
我认为“流”没有被创建，所以没有“状态码”

[xqzr]

不过 Xray 服务端一切正常时只会发 200，如果不是 200 那应该就是哪里出错了，所以代码逻辑好像没问题，你测测

stream-up 模式下 Nginx access.log 记录的 POST 具有各种“状态码”（400、499、000），但它可以工作

[07/Dec/2024:00:01:00 +0800] "GET https://s3.*.net:443/*/cceb8072-74fc-46a3-bb9a-3725cc12ae7d HTTP/3.0 TLSv1.3 TLS_AES_128_GCM_SHA256 s3.*.net" 200 9716 "-" "quic-go HTTP/3"
[07/Dec/2024:00:01:01 +0800] "POST https://s3.*.net:443/*/cceb8072-74fc-46a3-bb9a-3725cc12ae7d HTTP/3.0 TLSv1.3 TLS_AES_128_GCM_SHA256 s3.*.net" 400 0 "-" "quic-go HTTP/3"
[07/Dec/2024:00:02:13 +0800] "POST https://s3.*.net:443/*/c1bea9f1-dd98-4555-ad34-1ff3906f7d18 HTTP/3.0 TLSv1.3 TLS_AES_128_GCM_SHA256 s3.*.net" 400 0 "-" "quic-go HTTP/3"
[07/Dec/2024:00:02:13 +0800] "GET https://s3.*.net:443/*/c1bea9f1-dd98-4555-ad34-1ff3906f7d18 HTTP/3.0 TLSv1.3 TLS_AES_128_GCM_SHA256 s3.*.net" 200 4457 "-" "quic-go HTTP/3"
[07/Dec/2024:00:02:13 +0800] "POST https://s3.*.net:443/*/f351cbbf-9f96-4f78-a50d-f63ff171e17f HTTP/3.0 TLSv1.3 TLS_AES_128_GCM_SHA256 s3.*.net" 499 0 "-" "quic-go HTTP/3"
[07/Dec/2024:00:02:14 +0800] "GET https://s3.*.net:443/*/f351cbbf-9f96-4f78-a50d-f63ff171e17f HTTP/3.0 TLSv1.3 TLS_AES_128_GCM_SHA256 s3.*.net" 200 4953 "-" "quic-go HTTP/3"
[07/Dec/2024:00:03:14 +0800] "GET https://s3.*.net:443/*/0d536ee0-7e60-49b4-8a31-15ac245141a0 HTTP/3.0 TLSv1.3 TLS_AES_128_GCM_SHA256 s3.*.net" 200 7230 "-" "quic-go HTTP/3"
[07/Dec/2024:00:03:14 +0800] "GET https://s3.*.net:443/*/8274d9f3-45fd-482b-900e-51968619e653 HTTP/3.0 TLSv1.3 TLS_AES_128_GCM_SHA256 s3.*.net" 200 2760 "-" "quic-go HTTP/3"
[07/Dec/2024:00:03:14 +0800] "POST https://s3.*.net:443/*/8274d9f3-45fd-482b-900e-51968619e653 HTTP/3.0 TLSv1.3 TLS_AES_128_GCM_SHA256 s3.*.net" 499 0 "-" "quic-go HTTP/3"
[07/Dec/2024:00:03:14 +0800] "POST https://s3.*.net:443/*/0d536ee0-7e60-49b4-8a31-15ac245141a0 HTTP/3.0 TLSv1.3 TLS_AES_128_GCM_SHA256 s3.*.net" 499 0 "-" "quic-go HTTP/3"

[xqzr]

000

[07/Dec/2024:03:50:21 +0800] "POST https://s3.*.net:443/*/7d586989-0dbc-4e0c-96b1-f82074d4bdf8 HTTP/3.0 TLSv1.3 TLS_AES_128_GCM_SHA256 s3.*.net" 000 0 "-" "quic-go HTTP/3"
[07/Dec/2024:03:50:21 +0800] "GET https://s3.*.net:443/*/7d586989-0dbc-4e0c-96b1-f82074d4bdf8 HTTP/3.0 TLSv1.3 TLS_AES_128_GCM_SHA256 s3.*.net" 200 4528 "-" "quic-go HTTP/3"

[RPRX]

不过 Xray 服务端一切正常时只会发 200，如果不是 200 那应该就是哪里出错了，所以代码逻辑好像没问题，你测测

stream-up 模式下 Nginx access.log 记录的 POST 具有各种“状态码”（400、499、000），但它可以工作

那判断 non-200 的逻辑还是删了吧

[RPRX]

此时 HTTP 状态码是什么，5xx？

查找了当时的 Nginx 日志，没有相关行... 我认为“流”没有被创建，所以没有“状态码”

那就是属于 err，判断 err 我只有一个顾虑就是这个 err 可能是客户端的原因，不过以前修 H2 断流是这样：51769fd

[xqzr]

不过以前修 H2 断流是这样：51769fd

没用过 H2，但用过 gRPC。
我觉得 gRPC 库，帮我们处理了“这些杂项”
#4113 (reply in thread)

[RPRX]

@xqzr gRPC 和 XMUX 的目标不一样，XMUX 要精确控制复用所以要更谨慎，你试下这个场景 H2 和 HTTP/1.1 会产生什么 err

[RPRX]

我看了下 H3 的错误码 103 叫 ErrCodeStreamCreationError，所以就很难评，别的 HTTP 中间盒可能和 Nginx 不一样

[RPRX]

HTTP/1.1 没有流的概念，只能”一个接一个“这样复用 TCP，如果有一个出错了那应该后面的也废了吧

[RPRX]

我先睡了早上再看，要不就先不加 Abandon，有了 hMaxRequestTimes 暂时够用了，CDN 其实测一下就确定了，你测测 CF

[RPRX]

@xqzr 我想了下先不加 Abandon，看看 hMaxRequestTimes 的效果。流式上行 POST 服务端没即时返回，并且不像以前写 ok 的话可能 HTTP 中间盒会缓存 header，时间一长最后返回的就不是 200 了。也是怕这个时间一长返回 err 了，需要更多测试。

[RPRX]

但我想到流式上行 POST 服务端响应的 header 在缓冲区没 flush，最后返回的非 200 不知道是谁发的，可能没带上 header padding，本来想给它随便写点数据以便即时返回给客户端，但这可能会损坏 HTTP/1.1，还有待研究，这里就先不动它了。

[RPRX]

@xqzr 我觉得可能不是 Nginx 发的错误码 100，因为 100 挺”正常“的，可能 quic-go 本应包装成 103，此时又不知道新版改没改