详解TCP-第二篇，有时候真的不想学了

上次说到tcp的3次握手以及与udp的区别，今天主要记录学习到的tcp四次挥手

为什么握手3次，挥手却需要4次，如果把挥手也改成3次可以吗？

上次说到tcp具有拥塞控制，流量控制和重传机制，你是否好奇？

上次提到tcp的报文格式有窗口大小和选项，但是并没有多做解释，难道是不值得讨论？

1.四次挥手

比起三次握手，四次挥手的复杂程度也是不容小觑的，我们先通过图片来简单认识一下这个复杂的过程：

• 首先，双方都是established状态，客户端向服务端发送fin的请求标识，随后进入fin_wait_1的状态。
• 收到fin请求的服务端会向客户端回复一个ack，并进入closed_wait状态，等待一段时间后，才会给客户端发送fin标识，随后进入last_ack状态。为什么要等待一段时间呢，是因为服务端需要确认数据有没有发送完毕，这也是为什么4次挥手不能变成3次的理由。
• 收到服务端的fin标识后，客户端会回复一个ack随后进入time_wait状态（需要注意，只有主动关闭连接的一方才会进入time_wait状态）
• 收到客户端的ack标识之后，服务器会进入close关闭状态，停止连接。
• 而客户端会在time_wait状态之后，等待2msl之后，才会进入close状态。

从上述解释可以看出，其实客户端在发送fin标识之后，还是可以接收数据的，而服务端发送ack确认收到标识，很大程度上是在告诉客户端我将要进入最后的处理，你可以进入fin_wait_2状态。最后服务端发送fin标识表示同意关闭连接，数据也发送完毕。最后的数据处理也正是为什么挥手需要4次的原因。

 而这个time_wait和2msl是什么？

1.1 什么是time_wait?

time_wait是一个等待时间，它会持续2msl（一个msl是30秒，2个就是60秒），其实最主要的原因是防止发送端最后给服务端发送的ack确认标识在网络中丢失，lunix系统认为，发送方在发送数据和对方接收到数据并作出响应，一来一去最大不会超过30秒的时间，如果超出，则认为数据包在网络中丢失。

而如果服务端没有收到客户端最后的一次挥手（ack),会在一定时间内重传fin标识给客户端，而60秒的等待时间正好给了第四次挥手一个丢包的机会，至于为什么不给两次，是因为在大部分情况下，网络中丢包两次的概率实在太小，所以权衡之下选择了效率。

另一个原因就是防止历史连接的问题，大家都知道，tcp是可以通过序列号和应答序列号来确认自己收到的数据包是否是自己想要的，但是序列号并不是无限增长的，而是会回绕，也就是重置。

当然，了解四元组的同学，也清楚地知道，四元组可以唯一确定一个链接，当然也会出现相同的四元组（不了解的看第二篇博客）

如果没有time_wait或者time_wait时间过短，那么会发生什么？

我们都知道tcp是一位可靠的大哥，它是不会允许自己出现这种情况的，所以，time_wait的时间必须足够长，而且接收方的close状态必须比发送方晚得多才行。

1.2 服务器为什么会出现大量的time_wait?如何解决？

 看到这里，有的小伙伴不要迷糊，为什么服务器也会出现time_wait，之前的分析都在客户端啊？

首先要理清楚什么是客户端和服务端。

其次，time_wait是哪一方主动关闭连接，哪一方就会出现time_wait状态，所以服务器和客户级都有的哦。

至于为什么会出现大量的time_wait这可能是与http的长链接有关

首先要知道 TIME_WAIT 状态是主动关闭连接方才会出现的状态，所以如果服务器出现大量的 TIME_WAIT 状态的 TCP 连接，就是说明服务器主动断开了很多 TCP 连接。

问题来了，什么场景下服务端会主动断开连接呢？

• 第一个场景：HTTP 没有使用长连接
• 第二个场景：HTTP 长连接超时
• 第三个场景：HTTP 长连接的请求数量达到上限

a.http没有使用长链接，导致一次握手只处理一次请求

从 HTTP/1.1 开始， 就默认是开启了 Keep-Alive，现在大多数浏览器都默认是使用 HTTP/1.1，所以 Keep-Alive 都是默认打开的。一旦客户端和服务端达成协议，那么长连接就建立好了。

如果要关闭 HTTP Keep-Alive，需要在 HTTP 请求或者响应的 header 里添加 Connection:close 信息，也就是说，只要客户端和服务端任意一方的 HTTP header 中有 Connection:close 信息，那么就无法使用 HTTP 长连接的机制。

因此，当服务端出现大量的 TIME_WAIT 状态连接的时候，可以排查下是否客户端和服务端都开启了 HTTP Keep-Alive，因为任意一方没有开启 HTTP Keep-Alive，都会导致服务端在处理完一个 HTTP 请求后，就主动关闭连接，此时服务端上就会出现大量的 TIME_WAIT 状态的连接。

针对这个场景下，解决的方式也很简单，让客户端和服务端都开启 HTTP Keep-Alive 机制。

b.http长链接超时

假设设置了 HTTP 长连接的超时时间是 60 秒，nginx 就会启动一个「定时器」，如果客户端在完后一个 HTTP 请求后，在 60 秒内都没有再发起新的请求，定时器的时间一到，nginx 就会触发回调函数来关闭该连接，那么此时服务端上就会出现 TIME_WAIT 状态的连接。

当服务端出现大量 TIME_WAIT 状态的连接时，如果现象是有大量的客户端建立完 TCP 连接后，很长一段时间没有发送数据，那么大概率就是因为 HTTP 长连接超时，导致服务端主动关闭连接，产生大量处于 TIME_WAIT 状态的连接。

可以往网络问题的方向排查，比如是否是因为网络问题，导致客户端发送的数据一直没有被服务端接收到，以至于 HTTP 长连接超时。

c.http长链接的请求数量达到上限

Web 服务端通常会有个参数，来定义一条 HTTP 长连接上最大能处理的请求数量，当超过最大限制时，就会主动关闭连接。

比如 nginx 的 keepalive_requests 这个参数，这个参数是指一个 HTTP 长连接建立之后，nginx 就会为这个连接设置一个计数器，记录这个 HTTP 长连接上已经接收并处理的客户端请求的数量。如果达到这个参数设置的最大值时，则 nginx 会主动关闭这个长连接，那么此时服务端上就会出现 TIME_WAIT 状态的连接。

keepalive_requests 参数的默认值是 100 ，意味着每个 HTTP 长连接最多只能跑 100 次请求，这个参数往往被大多数人忽略，因为当 QPS (每秒请求数) 不是很高时，默认值 100 凑合够用。

但是，对于一些 QPS 比较高的场景，比如超过 10000 QPS，甚至达到 30000 , 50000 甚至更高，如果 keepalive_requests 参数值是 100，这时候就 nginx 就会很频繁地关闭连接，那么此时服务端上就会出大量的 TIME_WAIT 状态。

针对这个场景下，解决的方式也很简单，调大 nginx 的 keepalive_requests 参数就行。

2.重传机制

我们都知道，tcp协议为了保证可靠，有序地传输，依赖序号和确认序号两个字段来保证数据包有序，完整，并且可靠地传输，通过序号可以保证数据包是对方应该接受的，并且没有丢包。但是，网络环境是很复杂，出现丢包的概率是非常大的，那么出现丢包了之后怎么办？

接下来说说常见的重传机制：

• 超时重传
• 快速重传
• SACK
• D-SACK

2.1超时重传 

超时重传是最简单的，重传机制的其中一个方式，就是在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据，也就是我们常说的超时重传。

TCP 会在以下两种情况发生超时重传：

• 数据包丢失
• 确认应答丢失

 那么超时时间应该是多少呢？

RTT

RTT指的是一个数据包一来一回的时间，但是并不是一个固定的值，因为它会随着网络环境的变化而变化。

 而超时时长，是建立在RTT之上的RTO,其实就是，RTO的时间要比RTT长一些，为什么？

假设在重传的情况下，超时时间 RTO 「较长或较短」时，会发生什么事情呢？

上图中有两种超时时间不同的情况：

• 当超时时间 RTO 较大时，重发就慢，丢了老半天才重发，没有效率，性能差；
• 当超时时间 RTO 较小时，会导致可能并没有丢就重发，于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。

精确的测量超时时间 RTO 的值是非常重要的，这可让我们的重传机制更高效。

根据上述的两种情况，我们可以得知，超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。

但是RTT的值是根据网络情况动态变化的，所以RTO的值也是变化的，具体由算法实现，这里不多追究。所以当数据包第一次丢失的时候，tcp会根据RTO时间重传，但是RTO也会随着重传次数的增加而增加。

这里，以tcp三次握手来说明：

假如，在tcp三次握手时第一次握手丢失，tcp就会触发重传机制：

当客户端想和服务端建立 TCP 连接的时候，首先第一个发的就是 SYN 报文，然后进入到 SYN_SENT 状态。

在这之后，如果客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发「超时重传」机制，重传 SYN 报文，而且重传的 SYN 报文的序列号都是一样的。

不同版本的操作系统可能超时时间不同，有的 1 秒的，也有 3 秒的，这个超时时间是写死在内核里的，如果想要更改则需要重新编译内核，比较麻烦。

当客户端在 1 秒后没收到服务端的 SYN-ACK 报文后，客户端就会重发 SYN 报文，那到底重发几次呢？

在 Linux 里，客户端的 SYN 报文最大重传次数由 tcp_syn_retries内核参数控制，这个参数是可以自定义的，默认值一般是 5。

通常，第一次超时重传是在 1 秒后，第二次超时重传是在 2 秒，第三次超时重传是在 4 秒后，第四次超时重传是在 8 秒后，第五次是在超时重传 16 秒后。没错，每次超时的时间是上一次的 2 倍。

当第五次超时重传后，会继续等待 32 秒，如果服务端仍然没有回应 ACK，客户端就不再发送 SYN 包，然后断开 TCP 连接。

所以，总耗时是 1+2+4+8+16+32=63 秒，大约 1 分钟左右。

 

 2.1 快速重传

但是，超时重传的机制只适用于握手和挥手的时候，平时我们在传输数据的时候，用这个重传机制是否过于慢了？

所以，快速重传就出现了：

快速重传机制最大的特点就是，它不以时间驱动，而是以数据驱动。

听起来真的很搞笑，其实就是它一次性多发几个数据包，通过序列号来确定哪个数据包需要重传而已，不多说，直接上图：

• 第一份 Seq1 先送到了，于是就 Ack 回 2；
• 结果 Seq2 因为某些原因没收到，Seq3 到达了，于是还是 Ack 回 2；
• 后面的 Seq4 和 Seq5 都到了，但还是 Ack 回 2，因为 Seq2 还是没有收到；
• 发送端收到了三个 Ack = 2 的确认，知道了 Seq2 还没有收到，就会在定时器过期之前，重传丢失的 Seq2。
• 最后，收到了 Seq2，此时因为 Seq3，Seq4，Seq5 都收到了，于是 Ack 回 6 。

快速重传机制只解决了一个问题，就是超时时间的问题，但是它依然面临着另外一个问题。就是重传的时候，是重传一个，还是重传所有的问题。

举个例子，假设发送方发了 6 个数据，编号的顺序是 Seq1 ~ Seq6 ，但是 Seq2、Seq3 都丢失了，那么接收方在收到 Seq4、Seq5、Seq6 时，都是回复 ACK2 给发送方，但是发送方并不清楚这连续的 ACK2 是接收方收到哪个报文而回复的， 那是选择重传 Seq2 一个报文，还是重传 Seq2 之后已发送的所有报文呢（Seq2、Seq3、 Seq4、Seq5、 Seq6） 呢？

• 如果只选择重传 Seq2 一个报文，那么重传的效率很低。因为对于丢失的 Seq3 报文，还得在后续收到三个重复的 ACK3 才能触发重传。

• 如果选择重传 Seq2 之后已发送的所有报文，虽然能同时重传已丢失的 Seq2 和 Seq3 报文，但是 Seq4、Seq5、Seq6 的报文是已经被接收过了，对于重传 Seq4 ～Seq6 折部分数据相当于做了一次无用功，浪费资源。

可以看到，不管是重传一个报文，还是重传已发送的报文，都存在问题。

为了解决不知道该重传哪些 TCP 报文，于是就有 SACK 方法。

sack方法：

还有一种实现重传机制的方式叫：SACK（ Selective Acknowledgment）， 选择性确认。

这种方式需要在 TCP 头部「选项」字段里加一个 SACK 的东西，它可以将已收到的数据的信息发送给「发送方」，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。

如下图，发送方收到了三次同样的 ACK 确认报文，于是就会触发快速重发机制，通过 SACK 信息发现只有 200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进行重复。

 

 duplicate sack：

Duplicate SACK 又称 D-SACK，其主要使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。

第一种情况：ack丢包

第二种情况：网络延迟

 

可见，D-SACK 有这么几个好处：

1. 可以让「发送方」知道，是发出去的包丢了，还是接收方回应的 ACK 包丢了;
2. 可以知道是不是「发送方」的数据包被网络延迟了;
3. 可以知道网络中是不是把「发送方」的数据包给复制了;

 

3 .滑动窗口 

相信从上面几个图都发现，快速重传是连续发多个数据包，根据序号和sack值来确认丢包，但是这个连续多发几个数据包，到底是发几个呢？

除了重传机制外，我们平时向服务器发送数据，也并不是一次只发一个数据，然后傻傻地等待回应，再发下一个数据，这样是不是效率太低了？

于是聪明的你就会发现，在tcp报文格式中，还有窗口大小的字段。

那么有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。

窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。

假设窗口大小为 3 个 TCP 段，那么发送方就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过「下一个确认应答进行确认」。如下图：

 图中的 ACK 600 确认应答报文丢失，也没关系，因为可以通过下一个确认应答进行确认，只要发送方收到了 ACK 700 确认应答，就意味着 700 之前的所有数据「接收方」都收到了。这个模式就叫累计确认或者累计应答。

TCP 头里有一个字段叫 Window，也就是窗口大小。

这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

所以，通常窗口的大小是由接收方的窗口大小来决定的。

发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。

而且发送方和接收方的窗口大小是约等于，但不是完全等于的 ，比如，当接收方的应用进程读取数据的速度非常快的话，这样的话接收窗口可以很快的就空缺出来。那么新的接收窗口大小，是通过 TCP 报文中的 Windows 字段来告诉发送方。那么这个传输过程是存在时延的，所以接收窗口和发送窗口是约等于的关系。

4.流量控制

窗口的作用并不止控制一次传输的数据量，而且还能起到流量控制的作用。

发送方不能无脑的发数据给接收方，要考虑接收方处理能力。

如果一直无脑的发数据给对方，但对方处理不过来，那么就会导致触发重发机制，从而导致网络流量的无端的浪费。

为了解决这种现象发生，TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。

下面举个栗子，为了简单起见，假设以下场景：

• 客户端是接收方，服务端是发送方
• 假设接收窗口和发送窗口相同，都为 200
• 假设两个设备在整个传输过程中都保持相同的窗口大小，不受外界影响

 

前面的流量控制例子，我们假定了发送窗口和接收窗口是不变的，但是实际上，发送窗口和接收窗口中所存放的字节数，都是放在操作系统内存缓冲区中的，而操作系统的缓冲区，会被操作系统调整。

当应用进程没办法及时读取缓冲区的内容时，也会对我们的缓冲区造成影响。

当应用程序没有及时读取缓存时，发送窗口和接收窗口的变化。

考虑以下场景：

• 客户端作为发送方，服务端作为接收方，发送窗口和接收窗口初始大小为 360；
• 服务端非常的繁忙，当收到客户端的数据时，应用层不能及时读取数据。

 

 可见最后窗口都收缩为 0 了，也就是发生了窗口关闭。当发送方可用窗口变为 0 时，发送方实际上会定时发送窗口探测报文，以便知道接收方的窗口是否发生了改变，这个内容后面会说，这里先简单提一下。

当服务端系统资源非常紧张的时候，操作系统可能会直接减少了接收缓冲区大小，这时应用程序又无法及时读取缓存数据，那么这时候就有严重的事情发生了，会出现数据包丢失的现象。

 

所以，如果发生了先减少缓存，再收缩窗口，就会出现丢包的现象。

为了防止这种情况发生，TCP 规定是不允许同时减少缓存又收缩窗口的，而是采用先收缩窗口，过段时间再减少缓存，这样就可以避免了丢包情况。

4.1 窗口关闭 

在前面我们都看到了，TCP 通过让接收方指明希望从发送方接收的数据大小（窗口大小）来进行流量控制。

如果窗口大小为 0 时，就会阻止发送方给接收方传递数据，直到窗口变为非 0 为止，这就是窗口关闭。

事实上，窗口关闭是一个非常危险的举动，因为，当发送方在接到接收方窗口关闭的报文之后，会等待接收方处理完缓存数据再次打开窗口的报文，但如果这个报文在网络中丢失了以后，会出现死锁的现象：

 

为了解决这个问题，TCP 为每个连接设有一个持续定时器，只要 TCP 连接一方收到对方的零窗口通知，就启动持续计时器。

如果持续计时器超时，就会发送窗口探测 ( Window probe ) 报文，而对方在确认这个探测报文时，给出自己现在的接收窗口大小。

窗口探测的次数一般为 3 次，每次大约 30-60 秒（不同的实现可能会不一样）。如果 3 次过后接收窗口还是 0 的话，有的 TCP 实现就会发 RST 报文来中断连接。

4.2 糊涂窗口 

糊涂窗口其实是一个很简单的概念，它的意思就是，当接受方的窗口非常小的时候，它还是会毫不顾忌地发送接收方能容纳的数据量过去，但是一次的传输就为了传送少量的数据量的时候，开销也就过大了。

于是为了解决这个问题，当接收方的窗口过小的时候，会直接给发送方报0 

5.拥塞控制 

前面的流量控制是避免「发送方」的数据填满「接收方」的缓存，但是并不知道网络的中发生了什么。

一般来说，计算机网络都处在一个共享的环境。因此也有可能会因为其他主机之间的通信使得网络拥堵。

在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环被不断地放大....

所以，TCP 不能忽略网络上发生的事，它被设计成一个无私的协议，当网络发送拥塞时，TCP 会自我牺牲，降低发送的数据量。

于是，就有了拥塞控制，控制的目的就是避免「发送方」的数据填满整个网络。

为了在「发送方」调节所要发送数据的量，定义了一个叫做「拥塞窗口」的概念。

拥塞窗口 cwnd是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。

我们在前面提到过发送窗口 swnd 和接收窗口 rwnd 是约等于的关系，那么由于加入了拥塞窗口的概念后，此时发送窗口的值是swnd = min(cwnd, rwnd)，也就是拥塞窗口和接收窗口中的最小值。

拥塞窗口 cwnd 变化的规则：

• 只要网络中没有出现拥塞，cwnd 就会增大；
• 但网络中出现了拥塞，cwnd 就减少；

其实只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了拥塞。

拥塞控制主要是四个算法：

• 慢启动
• 拥塞避免
• 拥塞发生
• 快速恢复

5.1 慢启动

TCP 在刚建立连接完成后，首先是有个慢启动的过程，这个慢启动的意思就是一点一点的提高发送数据包的数量，如果一上来就发大量的数据，这不是给网络添堵吗？

慢启动的算法记住一个规则就行：当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。

这里假定拥塞窗口 cwnd 和发送窗口 swnd 相等，下面举个栗子：

• 连接建立完成后，一开始初始化 cwnd = 1，表示可以传一个 MSS 大小的数据。
• 当收到一个 ACK 确认应答后，cwnd 增加 1，于是一次能够发送 2 个
• 当收到 2 个的 ACK 确认应答后， cwnd 增加 2，于是就可以比之前多发2 个，所以这一次能够发送 4 个
• 当这 4 个的 ACK 确认到来的时候，每个确认 cwnd 增加 1， 4 个确认 cwnd 增加 4，于是就可以比之前多发 4 个，所以这一次能够发送 8 个。

 

 图片可以看出，慢启动发送数据包的个数呈现指数增长

但是，cwnd也不是无限增长的

有一个叫慢启动门限 ssthresh （slow start threshold）状态变量。

• 当 cwnd < ssthresh 时，使用慢启动算法。
• 当 cwnd >= ssthresh 时，就会使用「拥塞避免算法」。

5.2 拥塞避免算法

前面说道，当拥塞窗口 cwnd 「超过」慢启动门限 ssthresh 就会进入拥塞避免算法。

一般来说 ssthresh 的大小是 65535 字节。

那么进入拥塞避免算法后，它的规则是：每当收到一个 ACK 时，cwnd 增加 1/cwnd。

接上前面的慢启动的栗子，现假定 ssthresh 为 8：

• 当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd 一共增加 1，于是这一次能够发送 9 个 MSS 大小的数据，变成了线性增长。

 

所以，我们可以发现，拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长，还是增长阶段，但是增长速度缓慢了一些。

就这么一直增长着后，网络就会慢慢进入了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进行重传。

当触发了重传机制，也就进入了「拥塞发生算法」。

5.3 拥塞发生

当网络出现拥塞，也就是会发生数据包重传，重传机制主要有两种：

• 超时重传
• 快速重传

这两种使用的拥塞发送算法是不同的，接下来分别来说说。

当发生了「超时重传」，则就会使用拥塞发生算法。

这个时候，ssthresh 和 cwnd 的值会发生变化：

• ssthresh 设为 cwnd/2，
• cwnd 重置为 1 （是恢复为 cwnd 初始化值，我这里假定 cwnd 初始化值 1）

 

但是，让cwnd的值突然回到慢启动状态，手段太过强烈，可能会出现网络卡顿的现象

5.4 快速恢复 

快速重传和快速恢复算法一般同时使用，快速恢复算法是认为，你还能收到 3 个重复 ACK 说明网络也不那么糟糕，所以没有必要像 RTO 超时那么强烈。

正如前面所说，进入快速恢复之前，cwnd 和 ssthresh 已被更新了：

• cwnd = cwnd/2 ，也就是设置为原来的一半;
• ssthresh = cwnd;

然后，进入快速恢复算法如下：

• 拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；
• 重传丢失的数据包；
• 如果再收到重复的 ACK，那么 cwnd 增加 1；
• 如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态；