QUIC协议

275 阅读2分钟

Q(Quick)U(UserDatagramProtocol)I(Internet)C(Connection)协议

这是一个很特别的协议,它是基于UDP构建的传输协议,尽管暂时我无法很好解释为什么,但QUIC协议在我看来,这相对于大众协议是一个相对安全的协议。

QUIC协议的特点:安全(especially for script rat)、高效。

相较于TCP协议的三次握手,QUIC协议只进行一次握手(感觉不太安全?毕竟三次握手都不是绝对安全的)。

根据看到的数据,在5%丢包率场景下,200ms内传输完成的测试样本,QUIC占95%,TCP占78%,QUIC比TCP提升了17%左右,在15%丢包率场景下,200ms内传输完成的测试样本,QUIC占90%,TCP占50%,QUIC比TCP提升了90%左右,在30%丢包率场景下,200ms内传输完成的测试样本,QUIC占62%,TCP占22%,QUIC比TCP提升了300%左右,确实是高效,而且随着场景混乱程度地升高优势变得越来越大。

QUIC socket采用UDP收发数据,一个连接用一个ConnectionID唯一标识,无论用户在蜂窝网络与WLAN之间如何切换,只要数据包中的ConnectionID不变,服务端可以将不同的四元组关联到同一个连接上下文,从而避免出现断网重连。但是实现无缝的连接迁移困难并不小,为了实现高并发,服务端一般都会采用多线程,多进程的架构,负载均衡根据四元组将连接ConnectionID关联到特定的运行环境(线程或进程),连接迁移大概率会导致缓存的连接上下文失效。以下图多线程的设计举例,设想CID1连接迁移发生时,用户源IP和端口由A变成C,socket绑定的线程由1迁移到2,因线程2查找不到CID1连接的上下文,导致连接迁移失败。

根据自身测试的数据,现在采用QUIC协议的主流软件寥寥无几,而某视频软件就是采用QUIC协议进行传输的,相较于其他软件,使用QUIC协议的软件进行抓包和流量分析难度直接都上了一个档次,毕竟习惯了那些大众协议,而且现有的海量工具基本都用不了,尽管可以采用wireshark进行直接流量获取然后分析,但过程是极其痛苦的,大批量的话还是推荐写个插件,或者直接降协议,或者...但这些工作对于一些新手和只会用现成工具的人来说还是相对困难的,所以这个协议现在还是相对安全的。

总而言之,最近接触了这块内容,感觉QUIC协议确实挺有趣的,和大伙儿分享一下。