RPRX
> 我发现 SplitHTTP H3 的延迟是 H2 的两倍，看起来没有复用？ 但我测出来 https://github.com/XTLS/Xray-core/commit/22535d86439952a9764d65119bcc739929492717 H3 的延迟还是比 H2 高 3/4，测试用 URL 是 HTTPS 是 2-RTT，~~准备再次从 WireShark 开始看一下~~
> > 我发现 SplitHTTP H3 的延迟是 H2 的两倍，看起来没有复用？ > > 但我测出来 [22535d8](https://github.com/XTLS/Xray-core/commit/22535d86439952a9764d65119bcc739929492717) H3 的延迟还是比 H2 高 3/4，测试用 URL 是 HTTPS 是 2-RTT，~准备再次从 WireShark 开始看一下~ 好像是发送内层 Client Hello 前有一次往返，总之你们都测下延迟看看 WireShark 吧，~~我先睡觉了~~
> 分析了一下抓包结果 我发现这个http3的请求似乎是阻塞的 splithttp需要GET和POST两个请求才能建立连接 现在的行为是先GET后POST 在使用h2的情况下 这两个请求被同时发出 但是在使用h3的情况下 当服务端返回了200ok后 客户端才会发起POST请求 等于多了一个RTT 造成了额外延迟 又调试了一下代码，过程不表，发现是 SplitHTTP client.go OpenDownload 函数里这一段的问题： ```go trace := &httptrace.ClientTrace{ GotConn: func(connInfo httptrace.GotConnInfo) { remoteAddr = connInfo.Conn.RemoteAddr() localAddr =...
To ⑥：SplitHTTP 当然能用于反向代理，~~只是反过来的话速率会比较感人~~
To ⑥：SplitHTTP 当然支持 acceptProxyProtocol，~~只是你放 CDN 后面时有 X-Forwarded-For，它优先级更高~~ --- UDP 的话：https://github.com/pires/go-proxyproto/issues/88
> By the way, in your fix one can use `if c.isH3` instead of this casting of RoundTripper. ~~准备 force-push~~
还有关于 SplitHTTP 的 dialerProxy 修起来也不难，给 `type connection struct` 实现 ReadFrom 和 WriteTo（Buffer.UDP），~~然后给 local 填个随机值骗一下 quic-go 就行~~，参考 https://github.com/XTLS/Xray-core/issues/3560#issuecomment-2240871481 https://github.com/XTLS/Xray-core/issues/3560#issuecomment-2240883881 https://github.com/XTLS/Xray-core/issues/3556#issuecomment-2241031881 @mmmray
~~Quiet interesting.~~
~~比较好奇未来他们为了封锁 Telegram 而 implement 的具体技术手段~~ *~~I'm curious as to the exact technology they'll implement to block Telegram in the future.~~*
SplitHTTP H3 不支持 dialerProxy 只是我不小心发现的，实际上似乎没有这样的使用场景，有时间可以先实现 https://github.com/XTLS/Xray-core/issues/3560#issuecomment-2241990893