让reality支持quic？

[simplerick-simplefun]

有没有必要让reality支持quic来模拟http3？
还是说现在已经支持了？

[RPRX]

这个我想过，可以，但不合适。

因为 QUIC 支持连接迁移：GFW 已知你服务器 A 的 UDP/443 端口转发至另一个服务器 B 的 UDP/443 端口，任何一个你发到 A 的 QUIC 包突然被重定向至 B 应该没有问题才对。但如果你这条 QUIC 是代理，其中某个包突然被重定向至 B，B 不认识它，就会露馅。

[simplerick-simplefun]

谢谢大佬回复！

udp目前国内环境不太好，很多运营商qos。不过基于udp/quic的过墙相比tcp容易一些（不知为何gfw似乎对udp不严），未来h3也会慢慢变成主流。我想未来几年基于quic/h3的翻墙方案会越来越多。

[RPRX]

不知为何gfw似乎对udp不严

UDP 类没有什么魔法，只是因为现在用的人少（GFW 重心还在 TCP，尤其是 TLS 和全随机数），用的人多了一样严。

[Mars160]

所以大佬就是说偷自己的情况就合适？服务器B是指偷clienthello的服务器吗？

[iopq]

当然如果目标服务端就在你的服务器上，则没有问题，那就有 REALITY 相对于直接处理 TLS 的优势：消除指纹特征+防证书链攻击。 或者如果 GFW 找不到真正的目标服务端（这就是“目标 IP 冷门”的意思），也没有问题，不过这个前置条件并不容易实现。

目前 REALITY (TCP TLS) 够用，REALITY (QUIC) 就先咕着。

What I'd like to know if the game server I'm connecting to is using UDP, then would REALITY (QUIC) have a lower latency for gaming than REALITY (TCP TLS)?

[iopq]

I've thought about this, it's possible, but it's not appropriate.

Because QUIC supports connection migration: GFW knows that the UDP/443 port of your server A is forwarded to the UDP/443 port of another server B, so any QUIC packet you send to A should be redirected to B without any problem. But if your QUIC is a proxy, and a packet is suddenly redirected to B, B will not recognize it and it will be exposed.

I've tested it and for UDP applications I have to use QUIC. Gaming in particular, XUDP has a large penalty for packet loss. I go around packet loss by using udpspeeder and udp2raw, but I need this at the UDP layer.

But that means I can't fake a QUIC connection to another website with Reality

I read your post and I still don't understand the issue.