写在最后

到这里 hawkey 的主要组件全部介绍完了，代码量不大（大几百行，应该不到一千行）。功能上面基本满足了我的个人需求，现在也已经部署到网站上了，替换掉了之前部署的 nginx。hawkey 中还有很多不完善、不健壮、不安全的地方，会在后续使用过程中逐步完善和改进。

关于 HTTP/2.0

HTTP/2.0 旨在改进传输性能，在很多方面做了协议上的改进，也确实带来了不错的性能提升。如今现网中，知名网站以及很大比例网站已经升级到了 HTTP/2.0。但是 2.0 协议也有自己的限制，就是 TCP 连接。在 2.0 协议前，通过浏览器访问一个域的网页时，通常会建立很多连接，每个连接只发送一个请求然后接收响应，然后关闭连接。

再后来实现 keep-alive 的连接上可以发送多个请求，但是请求必须是串行的，发送一个请求收到响应，然后才能发送下一个请求再接收响应。一旦有一个请求没有即时响应，后续的所有请求都被阻塞了，网站的响应性很差，这就是请求队列的“队首阻塞”。

基于 HTTP/1.1 已经很难解决这个问题的事实，Google 公司开发了 SPDY 技术，基于一个连接发送所有请求，并且请求与响应可以相互交织发送，极大的提升了传输性能。而且不改变 HTTP 协议本身的语义。SPDY 技术推动了后面 HTTP/2.0 协议的发布，2.0 协议也是主要基于 SPDY 起草规范化的。

HTTP/2.0 看起来很好，但是也有自己的局限。现实中 HTTP/2.0 协议通常只会部署到浏览器与服务器接入层，很难得到端到端的部署。而且看似 HTTP/2.0 协议解决了请求队列的“队首阻塞”问题，实际上只是把这个问题下移到了 TCP 传输层。TCP 为了保证可靠顺序传输，一旦发送出去的数据没有收到对方的 ack，那么已发送的数据需要全部重发，即使只是在队首的某个请求发生了一次丢包，之后的所有请求都会收到影响。而丢包在网络情况较差时或者网络较差的地区是很常见的。

基于 TCP 连接固有的限制几乎没有太好的办法解决，而且 TCP 协议的极大成功使得现有网络设备都是基于 TCP 协议高度优化的，可以说是深度绑定，使得 TCP 协议升级几乎是不可能的事情。Google 公司又一次提出了 Quic 协议，一个基于 UDP 的可靠传输协议。功能上面和 TCP 非常像，只是 Quic 是基于 UDP 实现的，运行在用户态下的应用层协议，很方面进行升级和调试。另一方面也从根本上解决了“队首阻塞”问题，Quic 允许请求之间无影响的发送。

面对 Quic 的快速发展，Google 等很多大公司和组织正在积极推动其标准化，也就是 HTTP/3.0，距离发布的时间应该不远了。UDP 最主要的问题是长期以来不受重视，软硬件的优化方面和 TCP 差得太多了，可以预见要追赶上来，预计也是需要很长的时间。