写了一个基于 QUIC 协议的新代理工具,目标是将 QUIC 物尽其用

QUIC 协议汲取了大量人们给 TCP 糊墙的经验教训,把连接结构优化到(目前来看)极致。但是现在市面上的代理工具还没有能完全利用 QUIC 特性的存在,所以我自己动手写了一个基于 QUIC 协议的新代理工具:TUIC

https://github.com/EAimTY/tuic

1-RTT TCP 中继0-RTT UDP 中继,且 NAT 类型为 FullCone在用户空间的拥塞控制,也就是说可以在任何系统平台实现双向的 BBR两种 UDP 中继模式: native (原生 UDP 特性,数据仍被 TLS 加密)和 quic (100% 送达率,每个包单独单独作为一个 QUIC “流”,一个包的确认重传不会阻塞其它包)完全多路复用,服务器和客户端之间始终只需要一条 QUIC 连接,所有任务作为这个连接中的“流”进行传输(一个流的暂时阻塞不会影响其它流),所以除连接第一个中继任务外的其它任务都不需要经过 QUIC 握手和 TUIC 的鉴权网络切换时的会话平滑转移,例如在从 Wi-Fi 切换到移动数据时连接不会想 TCP 一样直接断开0-RTT 、与中继任务并行的鉴权支持 QUIC 的 0-RTT 握手(开启之后能达到 真·1-RTT TCP 和 0-RTT UDP ,但是就算不开启,多路复用的特性也能保证在绝大多数情况下 1-RTT 和 0-RTT )

TUIC 具体的设计细节在仓库中 Design 有说明。简单来说,设计核心就是减少握手造成的网络往返时延( rtt ),毕竟对于网络程序这是最大的瓶颈。

对比其它使用 TCP 的代理工具( ss 、v2ray 、trojan ),TCP 握手慢,且不支持自定义拥塞控制,各工具对 UDP 的支持也各有问题。对比 Hysteria ,Hysteria 的 UDP 中继需要 1 rtt 的握手,且只支持一种 UDP 模式。

最后说说安全性。TUIC 现在基于原生 QUIC ,不支持 ofbs ,但 QUIC 连接本身就是 TLS 加密的,每个 QUIC 连接从外面看都是一样的。国内的各大厂也慢慢开始使用 QUIC 了,所以我觉得 QUIC 特征应该不是什么大问题。

2022-07-13 15:54

Click to rate this post!
[Total: 0 Average: 0]

相关文章

发表回复

您的电子邮箱地址不会被公开。