RPRX
这个是 common/net/cnc/connection.go 下的 `type connection struct`，但它还没有实现 `net.PacketConn`，我写一下
即使实现了 ReadFrom 和 WriteTo，`type connection struct` 的 local 和 remote 都是 0.0.0.0，最后在 quic-go 这里 panic 了： ```go func (m *connMultiplexer) AddConn(c indexableConn) { m.mutex.Lock() defer m.mutex.Unlock() connIndex := m.index(c.LocalAddr()) p,...
其实这个问题可以以后解决，~~甚至无需解决~~，毕竟 SplitHTTP H3 基本上无需结合 dialerProxy，~~我是原来出站的配置没改好才遇到的~~
我发现 SplitHTTP H3 的延迟是 H2 的两倍，看起来没有复用？https://github.com/XTLS/Xray-core/issues/3560#issuecomment-2240883881 也是出现第二条连接时才 panic，有一点点共通性
> 我发现 SplitHTTP H3 的延迟是 H2 的两倍，看起来没有复用？ @dyhkwong 这个问题，应该不是必须手动 OpenStream() 吧
SplitHTTP H3 也有 globalDialerMap，但比较奇怪的是 quic-go 的 http3 没自动复用连接，每次都 Dial，是哪里没设置好吗
> 可能 quic-go/http3 就没支持吧 自己没实现stream 复用earlyConnection或者UDPConn都会报错( https://github.com/XTLS/Xray-core/pull/3565#issuecomment-2241348793 上行那么多 POST 总不能都是开新连接吧，~~那也太酸爽了~~，感觉还是能复用的，“但不知道为什么代理个新连接它就不复用了”，难道是因为 GET？@mmmray what do u think? > 还是mux吧 否了，MUX over QUIC 会有队头阻塞，H3 的一大优势就没了
> 否了，MUX over QUIC 会有队头阻塞，H3 的一大优势就没了 看了下群，防止误解，这里指的是 Xray 的 MUX over QUIC 的 single stream
> I can take a look next week. ~~你吓我一跳，我看了下日期，原来今天是周日~~ 反正目前“我发现 SplitHTTP H3 的延迟是 H2 的两倍，看起来没有复用？” https://github.com/XTLS/Xray-core/issues/3560#issuecomment-2241001918
> SplitHTTP H3 也有 globalDialerMap，但比较奇怪的是 quic-go 的 http3 没自动复用连接，每次都 Dial，是哪里没设置好吗 调试了一下代码，发现不是 quic-go 的问题，~~多少有点搞笑~~，SplitHTTP 的 dialer.go 里有处： ```go if isH3 { dest.Network = net.Network_UDP ``` 导致最后存了之后： ```go globalDialerMap[dialerConf{dest, streamSettings}] = client...