filter-qtype 64,65 优化讨论

[basncy]

起因: 在DNS查询层面禁用了quic查询, 用http2访问服务器, 也会被upgrade到h3, 参考nginx example: https://nginx.org/en/docs/quic.html add_header Alt-Svc 'h3=":8443"; ma=86400';

案例: ipv6透明代理, 防火墙允许udp 443流量(gfw会放行ipv6 udp 443流量), chinadns-ng过滤64,65查询. ipad油管app切到4k, 在网关上执行iftop, 发现仍然有大量udp443流量, 会被运营商限速到卡顿. 已知可以用udp tproxy, 但是 -j MARK会对每个udp包标记, 效率低, 实际还不如http2.

我的临时方案: 将googlevideo.com dns重写到某nginx反代ip, 走http2.

期望的改进: 方案一: 不过滤 filter-qtype 64,65查询, 而是将相关DNS重写为nginx的反代IP. 方案二: log此类(新)查询, 让用户在DNS查询链上某个结点自行决定是否重写DNS. 方案三: 什么也不做, 被限速而已, 低码率视频也能看.

[basncy]

补充两点, googlevideo.com 好像没有https记录, 可能是通过Alt-Svc upgrade到udp443的, 这种情况下chinadns似乎无能为力. TPROXY的机制并不能规避限速.

再想想怎么处理这种client/server 合伙"私下商量"走udp的情况吧.

[cattyhouse]

你这个问题说到底就是 “QUIC流量走tproxy速度低”， 我之前也遇到过（chrome开quic，手机youtube app等情况），经过各种测试发现是代理客户端tproxy的udp实现有问题（比如trojan-go的tproxy）， 现在改用 ipt2socks 对接 代理客户端的socks5，问题解决。

[cattyhouse]

可能你觉得是“udp tproxy, 但是 -j MARK会对每个udp包标记, 效率低” 但其实这个不是问题。 真正的问题在于现在的代理客户的tproxy的udp设计都比较有问题。

[basncy]

@cattyhouse 串一个ipt2socks解决吞吐量问题了. 其它客户端的udp tproxy估计没做丢包处理.

这下可以放开udp443了, 感谢 @zfl9