SplitHTTP h3 h2 multiplex controller

[mmmray]

Originally this was reported as a panic under #3556, and the changes in there had some effect on this. But slowly the issue became about some unrelated v2rayNG bug. That bug is fixed now, but the dialerProxy issue remains.

configs:

config-sh-h3.json
config-sh-h3-server.json

./xray -c config-sh-h3-server.json
./xray -c config-sh-h3.json

command to reproduce:

$ curl -x socks5h://127.0.0.1:2080 ifconfig.me
curl: (52) Empty reply from server

error in the logs when using d8994b7:

transport/internet/splithttp: failed to send download http request > Get "https://127.0.0.1:6001/6e67de80-f752-4df0-a828-3bcc3d1aaaf6": transport/internet/splithttp: unsupported connection type: %T&{reader:0xc0004658f0 writer:0xc000002250 done:0xc0002c84e0 onClose:[0xc000002250 0xc000002278] local:0xc000465890 remote:0xc0004658c0}

when reverting d8994b7, the client crashes instead:

panic: interface conversion: net.Conn is *cnc.connection, not *internet.PacketConnWrapper

goroutine 67 [running]:
github.com/xtls/xray-core/transport/internet/splithttp.getHTTPClient.func2({0x15735c8, 0xc000311ae0}, {0x0?, 0xc00004f700?}, 0xc00031e4e0, 0xc0001e14d0)
        github.com/xtls/xray-core/transport/internet/splithttp/dialer.go:108 +0x145
github.com/quic-go/quic-go/http3.(*RoundTripper).dial(0xc0002f7ce0, {0x15735c8, 0xc000311ae0}, {0xc00034ea30, 0xe})
        github.com/quic-go/quic-go@v0.45.1/http3/roundtrip.go:312 +0x27a
github.com/quic-go/quic-go/http3.(*RoundTripper).getClient.func1()
        github.com/quic-go/quic-go@v0.45.1/http3/roundtrip.go:249 +0x77
created by github.com/quic-go/quic-go/http3.(*RoundTripper).getClient in goroutine 66
        github.com/quic-go/quic-go@v0.45.1/http3/roundtrip.go:246 +0x289

[mmmray]

QUIC transport probably has identical issue:

Xray-core/transport/internet/quic/dialer.go

Lines 151 to 161 in a0040f1

	var udpConn *net.UDPConn
	switch conn := rawConn.(type) {
	case *net.UDPConn:
	udpConn = conn
	case *internet.PacketConnWrapper:
	udpConn = conn.Conn.(*net.UDPConn)
	default:
	// TODO: Support sockopt for QUIC
	rawConn.Close()
	return nil, errors.New("QUIC with sockopt is unsupported").AtWarning()
	}

[RPRX]

这个是 common/net/cnc/connection.go 下的 type connection struct，但它还没有实现 net.PacketConn，我写一下

[RPRX]

即使实现了 ReadFrom 和 WriteTo，type connection struct 的 local 和 remote 都是 0.0.0.0，最后在 quic-go 这里 panic 了：

func (m *connMultiplexer) AddConn(c indexableConn) {
	m.mutex.Lock()
	defer m.mutex.Unlock()

	connIndex := m.index(c.LocalAddr())
	p, ok := m.conns[connIndex]
	if ok {
		// Panics if we're already listening on this connection.
		// This is a safeguard because we're introducing a breaking API change, see
		// https://github.com/quic-go/quic-go/issues/3727 for details.
		// We'll remove this at a later time, when most users of the library have made the switch.
		panic("connection already exists") // TODO: write a nice message
	}
	m.conns[connIndex] = p
}

或许给 local 随便填个值骗一下它？此外我不确定 cnc 的另一端是否知道这是 UDP 而不是 TCP，从 WG 能工作来看可能是知道

[RPRX]

其实这个问题可以以后解决，甚至无需解决，毕竟 SplitHTTP H3 基本上无需结合 dialerProxy，我是原来出站的配置没改好才遇到的

[RPRX]

我发现 SplitHTTP H3 的延迟是 H2 的两倍，看起来没有复用？#3560 (comment) 也是出现第二条连接时才 panic，有一点点共通性

[RPRX]

我发现 SplitHTTP H3 的延迟是 H2 的两倍，看起来没有复用？

@dyhkwong 这个问题，应该不是必须手动 OpenStream() 吧

[RPRX]

SplitHTTP H3 也有 globalDialerMap，但比较奇怪的是 quic-go 的 http3 没自动复用连接，每次都 Dial，是哪里没设置好吗

[Fangliding]

可能 quic-go/http3 就没支持吧 自己没实现stream 复用earlyConnection或者UDPConn都会报错(
还是mux吧

[Mfire2001]

Maybe quic-go/http3 doesn't support it. I didn't implement stream myself. Reusing earlyConnection or UDPConn will result in an error ( or mux).

According to rfc 9114 section 4.1 only one request can be sent on each stream

A client sends an HTTP request on a request stream, which is a client-initiated bidirectional QUIC stream; see Section 6.1. A client MUST send only a single request on a given stream. A server sends zero or more interim HTTP responses on the same stream as the request, followed by a single final HTTP response

[RPRX]

可能 quic-go/http3 就没支持吧 自己没实现stream 复用earlyConnection或者UDPConn都会报错(

#3565 (comment) 上行那么多 POST 总不能都是开新连接吧，那也太酸爽了，感觉还是能复用的，“但不知道为什么代理个新连接它就不复用了”，难道是因为 GET？@mmmray what do u think?

还是mux吧

否了，MUX over QUIC 会有队头阻塞，H3 的一大优势就没了

[RPRX]

否了，MUX over QUIC 会有队头阻塞，H3 的一大优势就没了

看了下群，防止误解，这里指的是 Xray 的 MUX over QUIC 的 single stream

[mmmray]

I have only seen this lack of connection reuse with HTTP/1.1. There, it is inherently because of the protocol: A chunked-transfer cannot be aborted by the client without tearing down the TCP connection. Upload was still correctly reused.

In h2 it works normally already. I still have to catch up with how QUIC is behaving here, but I think there is no inherent reason related to the protocol.

You can try to create a separate RoundTripper for upload and download, to see if GET interferes with the connection reuse of POST. This is how I debugged things in h1. If nobody does it I can take a look next week.

[RPRX]

I can take a look next week.

你吓我一跳，我看了下日期，原来今天是周日

反正目前“我发现 SplitHTTP H3 的延迟是 H2 的两倍，看起来没有复用？” #3560 (comment)