EAimTY

这个最好等待上游 [quinn](https://github.com/quinn-rs/quinn) 的修复。我手头没有 BSD 环境，并且不太了解 FreeBSD 的 libc。之后如果有时间的话我会尽量尝试修复。

我觉得可以直接使用 dual-stack socket + mapping address 解决这个问题。对于不支持 dual-stack socket 的操作系统，我觉得可以直接忽略，因为它们大概会连 quinn、ring 这些依赖都无法支持。

That's a good point, but it is a little tricky to implement. Since `quinn` doesn't expose any API for obtaining a stable and peers-equivalent parameter, it is difficult to bound...

若存在主动探测，连接的流程会以如下方式进行： 1. server 与 client 建立 QUIC 连接（需要证书与 ALPN 匹配） 2. server 端会接受 client 新建的所有 stream、datagram 并解析它们的 header。但在收到正确的 TUIC 鉴权 stream 前，server 端不会回复任何信息。如果恶意的主动探测发送的数据无法按照 TUIC command header 解析，server 会立刻切断整个 QUIC 连接...

最近正在重构，打算按照鉴权失败回落 HTTP/3 的方式处理。从 stream 读取 TUIC header 尝试解析并失败后，交给 HTTP/3 服务的 stream 仍应该包含 header 中的内容，但是目前遇到的问题是上游的 quinn 没有实现 AsyncSeek 相关的 API。我之后打算单独写一个基于 AsyncRead 实现 AsyncSeek 的库，但目前还不确定能否实现。 之后的 TUIC 本身打算以库的形式发布，包含上面所说的解析失败后将 stream 转交的 API。server 与...

目前我所看到的有统计学意义的数据所分析的都是基于 TCP + TLS 的协议，QUIC 是否受到影响还不太清楚。TUIC 受到影响的个例可能只是数据噪声，无法就此得出结论。 我的主观推测是 QUIC 没有收到影响，因为： 1. 在 TCP 上，使用 TLS 的占比很高，而在 UDP 上并非如此 2. QUIC 较为深度地整合了 TLS（指从 handshake、header 上），且目前 QUIC 还未被普遍使用 综上，我认为 QUIC 流量被分析的可能性不大。 尽管如此，吸取经验，我觉得有必要在行为和数据上（如...

关于检测 UDP 端口：TCP 和 UDP 是两个不同的协议栈，端口号互不影响，可以重叠。可以用 python 创建一个 UDP packet echo server / client 来检测，只需要非常少的代码。

请问之前的几个版本（0.8.4/0.8.3/0.8.2/0.8.1）有类似问题吗？Releases 都是直接用 GitHub Actions 编译出的 binary，除非上游工具链被感染，否则不可能被偷偷加料。

客户端的 MAX_UDP_PACKET_SIZE 控制 socks5 收到 UDP 包的最大大小，server 端是从 tuic 连接的 UDP 中转和外部收到的包的最大大小。包的超出部分会被截断。如果需要设置的话，建议设置到小于等于客户端到服务器路径的 MTU。 之后应该会加上自动 MTU 探测。

新版本对这部分做了一些更改。 UDP relay mode `Native` 下中继 UDP 包使用 QUIC 的 datagram，因此数据包大小限制完全取决于 datagram 的最大尺寸。新版本会在这种中继模式下自动检测并匹配 max datagram size. UDP relay mode `Quic` 下中继 UDP 包使用 QUIC 的 stream，因此理论上数据包大小没有任何限制，完全取决于 inbound 侧的接收缓存设置。因此新版本重新添加了选项 `max_udp_relay_packet_size` 来设置这种中继模式下接收缓存的大小。