HTTPUpgrade server: Fix certain stuck in Handle()

[Fangliding]

这两天莫名其妙卡死 抓包显示 GET 请求发送后响应一个 ACK 就卡死了 我还以为是被墙了 发现只有发送到 httpupgrade 的路径会卡死 其他回复都是正常 后来在VPS端抓包发现VPS收到GET也是响应一个ACK再无响应 随手重启一下发现就好了 连续遇到了两三次 检查代码的时候发现这个 httpupgrade 升级过程竟然是串行阻塞的 只要有一个占着监听器升级流程的连接它就会一直阻塞整个监听器导致其他连接都不能升级 特征就是收到一个 GET 就没有响应了

[RPRX]

这个完全从 v2fly 搬过来的要不也给他们 pr 一份吧

[RPRX]

HTTPUpgrade 加个简写 HU 吧，network hu，huSettings，结合 ECH 后作为 CDN 上能完全控制流量特征的传输层还是有些价值的

虽然可能也就 CF 支持 WS 和 HU，且这几个国家中也就中国能用 CF，且中国离彻底封锁 cloudflare-ech.com 这个 SNI 可能不远了

[Fangliding]

我稍微研究过一点点好像大多数ws转发都是升级完转到对拷 没几个真解析帧消息的

[RPRX]

还有可能可以魔改一下 Nginx 支持 alpn h2, http/1.1 协商出了 h2 但内部明文也接受 h1，不过有特征，另外 SNI 白名单，呃。。。

我稍微研究过一点点好像大多数ws转发都是升级完转到对拷 没几个真解析帧消息的

这是大概率的，就像对于 gRPC，CF 和 Nginx 都是直接按 h2 处理，这才有了 XHTTP stream-up/one

不过我的意思是 CDN 按数量来看没几个支持 WS，所以也就不支持 HU，这才有了 XHTTP packet-up

[Fangliding]

还有可能可以魔改一下 Nginx 支持 alpn h2, http/1.1 协商出了 h2 但内部明文也接受 h1，不过有特征，另外 SNI 白名单，呃。。。

ECH 可以让ws和hu做到外层 h2 里面 h1 只不过utls没人一直没法做

[RPRX]

ECH 可以让ws和hu做到外层 h2 里面 h1 只不过utls没人一直没法做

所以我说是“结合 ECH”，但是真 ECH 貌似普遍比 GREASE 长吧，还是挺扎眼的

比较好的办法是给 Nginx 也加个“首包分流”，对 TLS 首包尝试按 h1 解析且 path 对就按 h1 处理，否则就按协商出的 h2 处理

[Fangliding]

grease好像有一个挺严谨的padding策略而且最后要对长度padding到32的倍数