http连接复用进化论

HTTP协议是应用层协议，它定义万维网客户端如何与服务器进行通信。它在传输层的TCP协议的基础上进行数据传输

HTTP 1.0

在HTTP 1.0时代，默认一个http请求对应一个TCP连接，没有任何复用。也就是每发起一个http请求，就会创建一个TCP连接，请求完成后，TCP连接便会断开。也可以通过Connection和Keep-Alive两个头部字段配置使用持久连接。

HTTP 1.1

到了http1.1，底层的TCP默认是持久连接，前后串行的请求可以复用一个TCP连接。对后面的http请求来说，节约了等待TCP建立的时间。

使用持久连接时，如果上一个请求还没完成，此时发起的http请求，还是要建立新的TCP，所以TCP整体的利用率比较低，因此HTTP1.1也定义了一种管道化Pipelining机制，它允许先后发起多个请求，然后再依次接收这些请求的响应，不必等前一个请求结束后就可以发送下一个，但是因为它会导致队头阻塞，高优先级的请求很可能会被前面的阻塞，而且实现比较复杂，且只支持get和head请求，所以实现的浏览器很少，应用并不广泛。

不论是持久连接还是管道化，对连接的复用都不够完美，复用率比较低，所以当时前端会通过资源合并的方式减少请求数，以提升网页加载性能，比如雪碧图，css和JS打包、内联等等

HTTP 2.0

后来有了http2.0协议，定义了二进制分帧和多路复用，支持在一个TCP连接中同时双向传输多个请求和响应，多个http请求数据同时复用一个TCP连接。

HTTP 3.0

http3.0是基于UDP的，通信初始化的成本本身就很低，而且还实现了流复用，所以效率和复用率更高。

关于持久连接的保活验活机制

网络状况是多变的，双方不可能一直维持着某个TCP连接，而是有一套完整而且可以配置的保活验活机制，具体是当链路空间时间到达7200秒时，就会发送探测包，探测连接和对端是否正常，如果正常，就继续等待重复这个流程；如果没有正常收到回包，就会以默认75s的间隔重复发送探测包，直至发送次数到达9次，如果还没有收到，就会认为这个连接已失效，不再维持。上面提到的两个间隔和一个次数上限，都是可配的。

这就是持久连接的保活验活机制。通过这个机制服务器可以定时清理失效连接，释放资源。