Persistent QUIC connection for DoQ

[almostthere831]

I noticed increased latency and overhead when trying to use DoQ instead of DoH3. It appears that the DoQ implementation uses individual connections that terminate immediately after each request, which added a noticeable delay on DNS requests. Also see github.com//issues/309.

The changes proposed here modify the DoQ implementation to use a single persistent connection similar to the http3.Transport implementation for DoH3.

I tested this on an arm7/linux platform using OpenWRT. The connection persists as expected, and the latency/overhead appears to be at least as good as DoH3 for my use case.

Open to any thoughts or concerns about this approach.

(All code written by Claude.)

doq-persistent-conn.patch

[almostthere831]

doq.go.txt

doq_test.go.txt

[cuonglm]

What version do you use?

There's recent change in v1.5.3 to share single quic conn for multiple DoQ requests.

[almostthere831]

I used 1.5.4 for testing and as the baseline for the changes. It looks like there are multiple TLS connections with the 1.5.4 design that repeatedly terminate and reestablish.

Here is the summary of the logic difference:

The role of the atomic.Pointer change relative to #309

The shared transport (the #309 fix) was already in 1.5.4 before this patch. It eliminated the per-dial socket allocation. This change is orthogonal but complementary:

	1.5.4 original	After this patch
UDP sockets per pool	1 (shared transport)	1 (same)
QUIC connections per pool	up to 16 (channel pool, one checked out per request)	1 (shared, atomic.Pointer)
TLS handshakes on reconnect	new connection, new handshake	new connection, new handshake (same)
TLS handshakes for concurrent requests	1 per concurrent request	0 (streams on existing connection)

The transport fix capped the FD cost at 1. This fix caps the QUIC session cost at 1. They address different layers of the same resource management problem — sockets at the OS level, sessions at the QUIC level.

The fix: persistent shared connection

The redesign mirrors exactly how http3.Transport works:

	Old (channel pool)	New (shared persistent)
Storage	chan *doqConn (size 16)	atomic.Pointer[quic.Conn]
getConn	Removes conn from channel	Loads shared pointer (O(1), lockless)
putConn(good)	Puts conn back in channel	No-op — conn already in p.conn
putConn(bad)	Closes conn	CAS eviction: only winner closes
Concurrent 20 requests	20 dials, 20 connections	1 dial, 1 connection, 20 streams
Reconnect	Works, but creates new pool entry	Works, dialMu prevents thundering herd