传输控制协议八卦保持活跃和时间等待

TCP是一种有状态通信协议。所谓有状态是指通信过程中双方保持的连接状态

1，TCP keepalive

首先简要回顾TCP连接建立和断开的整个过程(这里主要考虑的是主要过程，以及有关数据包丢失、拥塞、窗口、失败重试等的详细信息。将在后面讨论。))< br>

首先，客户端向服务器发送一个syn(同步序列号)数据包，告诉服务器我想连接您。syn包主要携带客户端的序列号。服务器返回一个syn+ack，其中syn包与客户端具有相同的原理，除了它携带服务器的序列号，并且ack包确认客户端被允许连接。最后，客户端再次发送确认消息，确认从服务器接收到syn数据包这样，客户端和服务器可以建立连接整个过程被称为“三次握手”

建立连接后，客户端或服务器可以通过建立的套接字连接发送数据，对端收到数据后，可以通过ack确认收到数据在

数据交换完成后，通常客户端可以发送一个FIN数据包，告诉另一端我想断开连接。另一端首先通过确认确认收到FIN数据包，然后发送FIN数据包告诉客户端我也关闭了它。最后，客户端响应ack确认连接的终止整个过程变成了“四波”

TCP的性能经常受到大家的批评。除了TCP+IP的额外报头之外，它需要三次握手来建立连接，并需要四个波来关闭连接。如果只传输少量数据，则传输的有效数据非常少。建立连接后，

可重用吗？这样做是可能的，但这带来了另一个问题。如果连接未被释放，端口被占用，该怎么办？为此，我们引入了今天讨论的第一个主题——TCP保持活动。所谓的TCP保活是指TCP连接在建立后通过保活来保持，在数据传输完成后不会立即中断，而是通过保活机制来检测连接状态。

Linux控件keepalive有三个参数:keepalive time net . IP v4 . TCP _ keepalive _ time、keepalive time interval net . IP v4 . TCP _ keepalive _ intvl、keepalive探测计数net.ipv4.tcp_keepalive_probes，默认值分别为7200秒(2小时)、75秒和9个探测如果使用TCP自己的保活机制，在Linux系统中断开连接至少需要2小时+9*75秒。例如，在SSH登录到服务器后，我们可以看到TCP保持活动的时间是2小时，我们将在2小时后发送一个探测包，以确认对方是否处于连接状态。

讨论了TCP保持活动，因为在服务器上发现了泄漏的TCP连接:

# ll/proc/11516/FD/10
lrwx-1 root 64 Jan 3 19:04/proc/11516/FD/10->套接字:

为什么需要time_wait状态？为什么不直接进入关闭状态？进入关闭状态直接释放资源用于新连接，速度比等待2MSL(默认为Linux)更快

有两个原因:

是为了防止“数据包丢失”如下图所示，如果第三个数据包由于第一个连接中的底层网络故障而延迟在等待建立新的连接之后，这个延迟的数据包将到达，这将导致接收数据的混乱。

的第二个原因更简单。如果最后一个ack丢失，另一方将总是处于最后一个ack状态。如果此时再次发起新的连接，另一方将返回RST分组以拒绝该请求，这将导致建立新连接的失败。< br>

为此目的设计了time_wait状态在高并发的情况下，如果时间等待的传输控制协议可以被多路复用，时间等待多路复用意味着处于时间等待状态的连接可以被重复使用，从时间等待转换为建立，并连续重复使用Linux内核通过net.ipv4.tcp_tw_reuse参数控制是否打开time_wait状态重用。

的读者可能会好奇。你不是说时间等待最初是为了解决上述两个问题吗？如果直接再利用不会导致上述两个问题？本文首先介绍了一个TCP时间戳策略网络。

时间戳开启后，针对第一个数据包丢失的问题，由于迟到数据包的时间戳会被直接过早丢弃，不会造成新连接数据包的混乱；对于第二个问题，在重用打开后，当另一方处于最后确认状态时，发送syn包将返回FIN、ack包，然后客户端发送RST让服务器关闭请求，这样客户端就可以再次发送syn来建立新的连接

最后需要提醒读者，在Linux内核版本4.1之前，除了tcp_tw_reuse之外，还有一个参数tcp_tw_recycle，就是强制回收处于time_wait状态的连接，这将导致NAT环境中的数据包丢失，所以不建议打开它。

作者:陈晓宇

陈晓宇的书“云计算:从IaaS到高级PaaS”