linux源码解读（三十）：quic协议分析（一）

1、网络通信时，为了确保数据不丢包，早在几十年前就发明了tcp协议！然而此一时非彼一时，随着技术进步和业务需求增多，tcp也暴露了部分比较明显的缺陷，比如:

• 　建立连接的3次握手延迟大； TLS需要至少需要2个RTT，延迟也大
• 协议缺陷可能导致syn反射类的DDOS攻击
• tcp协议紧耦合到了操作系统，升级需要操作系统层面改动，无法快速、大面积推广升级补丁包
• 对头阻塞：数据被分成sequence，一旦中间的sequence丢包，后面的sequence也不会处理
• 中转设备僵化：路由器、交换机等设备“认死理”，比如只认80、443等端口，其他端口一律丢弃

　　为了解决这些问题，牛逼plus的google早在10年前，也就是2012年发布了基于UDP的quic协议！为啥不基于tcp了，因为tcp有上述5条缺陷的嘛，所以干脆“另起炉灶”重新开搞！

2、正式介绍前，先看一张图：quci在右边，底层用了udp的协议；自生实现了Multistreaming、tls、拥塞控制，然后支撑了上层的http/2，所以我个人理解quic是一个夹在应用层和传输层之间的协议！

上面“数落”了tcp协议的5点不是，quic又是怎么基于udp解决这些问题的了？quic 是基于 UDP 实现的协议，而 UDP 是不可靠的面向报文的协议，这和 TCP 基于 IP 层的实现并没有什么本质上的不同，都是：

• 底层只负责尽力而为的，以 packet 为单位的传输;
• 上层协议实现更关键的特性，如可靠，有序，安全等。

　 （1）由于quic并未改造udp，而是直接使用udp，所以不需要改动现有的操作系统，也兼容了现有的网络中转设备，这些都不需要做任何改动，所以quic部署的改造成本相对较低！但是quic毕竟是新的协议，在哪部署和使用了？只有应用层了！这个和操作系统是解耦的，全靠3环的app自己想办法实现（和之前介绍的协程是不是类似了？）！google已经开源了算法，下载连接见文章末尾的参考5；PS：微软也实现了QUIC协议，名称叫MsQuic，源码在这：https://github.com/microsoft/msquic；

这里多说几句：应用层app能操作的最底层协议就是传输层了。大家在用libc库编写通信代码时可以对指定的ip地址和端口收发数据，没法改自己的mac地址吧？也没法改自己的ip地址吧？这些都是操作系统内核封装的，app的开发人员是不需要、也是没法改变的，所以站在安全防护的角度，部分大厂基于传输层自研了类似quic的通信协议，逆向时需要人工挨个分析协议字段的含义了，现成的fiddler/charles/burpsuit等https/http的抓包工具是无效的，用wireshark这类工具抓包也无法自动解析这些厂家自研的协议！

（