TCP Keepalive 和HTTP Keep-Alive是一个东西吗？

对于这个问题，我们要先知道这两个KeepAlive分别代表什么？

• TCP的Keepalive是由TCP层（内核层）实现的，称为TCP保活机制；如果两端TCP连接一直没有数据交互，就会触发该机制，内核里的TCP协议栈会发送探测报文。

  • 如果对端程序正常工作，TCP保活时间会被重置。
  • 如果对端主机宕机，TCP会报告TCP连接已经死亡。

• HTTP的Keep-Alive是由应用层（用户层）实现的，称为HTTP长连接；

  先来了解什么是短链接

  • HTTP采用的是请求—应答模式，并且是基于TCP传输协议实现的。客户端与服务端进行HTTP通信前，要建立HTTP连接，然后客户端发送HTTP请求，服务端收到后就返回响应，至此，请求—响应的模式就完成了，然后就会释放TCP连接。这个过程就是HTTP短连接。

  使用HTTP的Keep-Alive就可以实现在完成HTTP请求后不断开TCP连接，让后序的HTTP请求继续使用该TCP连接。这就避免了连接的重复建立和释放的开销。

  如果要开启Keep-Alive，就要在请求头中添加：Connection: Keep-Alive

  但服务器收到请求后，它也在响应头中添加：Connection:Keep-Alive

  从HTTP1.1开始，就默认开启了Keep-alive，如果要关闭Keep-Alive，需要在HTTP请求包头中添加：Conntection:close

  HTTP长连接为HTTP流水线提供了可能，所谓的 HTTP 流水线，是客户端可以先一次性发送多个请求，而在发送过程中不需先等待服务器的回应，可以减少整体的响应时间。但服务器是按照顺序响应的。

  一般的，防止长连接占用资源，webweb 服务软件一般都会提供 keepalive_timeout 参数，用来指定 HTTP 长连接的超时时间。比如设置了 HTTP 长连接的超时时间是 60 秒，web 服务软件就会启动一个定时器，如果客户端在完后一个 HTTP 请求后，在 60 秒内都没有再发起新的请求，定时器的时间一到，就会触发回调函数来释放该连接。

TCP协议有什么缺陷

主要有以下几个方面，UDP协议的可靠传输使用的QUIC协议就解决了TCP的痛点，并且现在已经应用到HTTP/3了。

• 升级 TCP 的工作很困难；

  TCP 协议是在内核中实现的，应用程序只能使用不能修改，如果要想升级 TCP 协议，那么只能升级内核。但是升级内核很麻烦。

• TCP 建立连接的延迟；

  基于TCP实现的应用协议，都要首先建立三次握手才能进行数据传输。比如HTTPS协议，在经过TCP三次握手之后，还需要经过TLS四次握手，才能进行HTTP数据的传输，这就增加了数据传输的延迟。

  TCP Fast Open 减少了第二次TCP建立连接时的时延。但是提出的较晚，很难被普及。

• TCP还可能不安全；

  因为TLS是在应用层实现的握手，TCP是在内核实现的握手，这两个握手过程无法结合在一起，总是得先完成TCP握手，才能进行TLS握手，所以TLS无法对TCP头部进行加密，这意味着TCP的序列号都是明文传输的，存在安全问题

  一个典型的例子就是攻击者伪造一个的 RST 报文强制关闭一条 TCP 连接，而攻击成功的关键则是 TCP 字段里的序列号位于接收方的滑动窗口内，该报文就是合法的。

  为此 TCP 也不得不进行三次握手来同步各自的序列号，而且初始化序列号时是采用随机的方式（不完全随机，而是随着时间流逝而线性增长，到了 2^32 尽头再回滚）来提升攻击者猜测序列号的难度，以增加安全性。

  但是这种方式只能避免攻击者预测出合法的 RST 报文，而无法避免攻击者截获客户端的报文，然后中途伪造出合法 RST 报文的攻击的方式。

• TCP 存在队头阻塞问题；

  因为TCP是字节流的协议，TCP层必须要保证收到的字节数据是完整并且有序的，当序列号较低的TCP段在网络中丢失，即使序列号较高的TCP段已经被接受了，但是应用层也**无法从内核读取这段数据。**这就是TCP队头阻塞的问题。

  HTTP/2多个请求是跑在一个TCP连接中的，当TCP连接丢包，整个TCP就要等待重传，那么就会阻塞该TCP连接中的所有请求，所以HTTP/2队头阻塞问题就是因为TCP协议导致的。

• 网络迁移需要重新建立 TCP 连接；

  基于 TCP 传输协议的 HTTP 协议，由于是通过四元组（源 IP、源端口、目的 IP、目的端口）确定一条 TCP 连接。

  那么当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立 TCP 连接。

  而建立连接的过程包含 TCP 三次握手和 TLS 四次握手的时延，以及 TCP 慢启动的减速过程，给用户的感觉就是网络突然卡顿了一下，因此连接的迁移成本是很高的。