QUIC 协议的简单分析

看到google 提交了http3 over QUIC 的标准化草案, 才发现2012年我在 UDP可靠传输那些事 https://blog.csdn.net/danscort2000/article/details/8432778 一文中给出的那些痛点,居然给出了解决方法, 最大的局限就是我当时说的, sendto 和recvfrom 函数, 2014年Linux核心添加了 recvmmsg 和 sendmmsg 函数,这样就和tcp send/recv函数一样,一次调用就可以读写多个数据包,解决了用户态和内核态之间频繁切换的问题, (但是, windows 目前还没有支持这两个函数)这样,如果只是单纯的做发包测试或者收报测试,运行在应用层[测试的时候优先级为默认]默认16包下,吞吐提升我估计大概会达到 16 *2 /3 也就是原先的10倍多一点,如果整合到具体的可靠传输协议中进行测试[包含包头的校验等一切算法], 按照当时的经验, 性能提升[也是按16包默认缓冲]估计会在35%左右,而google 的 QUICK 正是基于这两个recvmmsg sendmmsg 实现了高效率的UDP可靠传输.

 

QUIC简化了握手过程,包括TLS的握手过程,这样在处理海量的短连接的时候,性能优势是非常明显的 [请注意,是海量+短连接,要同时满足这两个条件] , 下面是QUIC旧版本的实现部分包头内容分解,说句老实话, 象QUIC这种UDP可靠传输,还是应该使用纯C来写更简洁明了(虽然我大部分时间也是用c++,但是这种协议层的实现确实应该使用纯C, c++ try catch不到位的话,很容易引发崩溃等各种漏洞或者攻击),这种c++写法我个人无法接受,当然google为了照顾go语言等面向对象的需要,可能就优先考虑c++了,但是真的看着挺乱的, 但是这里可能有问题,使用特制版的Linux使用RAW模式,应该比较容易发起性能攻击,这可能比TCP的DDOS更严重,因为UDP模式下,要伪造包太容易了, 攻击发起方需要的电脑数量比TC