TCP 快速重传为什么是三次冗余 ACK，这个三次是怎么定下来的？

点击上方关注 “终端研发部”

设为“星标”，和你一起掌握更多数据库知识

本回答首发于知乎！

想要了解在这个问题，那么你就要了解：TCP三次握手，四次分手以及ACK的基本原理了

话不多说，我直接上干货！

先了解一下TCP的ACK原理和延迟确认机制

ACK定义

TCP协议中，接收方成功接收到数据后，会回复一个ACK数据包，表示已经确认接收到ACK确认号前面的所有数据。

ACK字段长度为32位，能表示0~2^32-1之间的值。

ACK作用

发送方在一定时间内没有收到服务端的ACK确认包后，就会重新发送TCP数据包。发送方收到了ACK，表明接收方已经接收到数据，保证了数据的可靠达到。

ack的定义就是提醒向自己发送数据包的对端，下次发送给我，应该从ack位置的包进行发送。

假设客户端发送data，包的数量是1-100，那么服务端回送的ack则是从101开始。如果服务端回传的超时（或者有存在丢包情况），客户端就会重新发送这个包

ACK机制的工作原理

ACK延迟确认机制

接收方在收到数据后，并不会立即回复ACK,而是延迟一定时间。一般ACK延迟发送的时间为200ms，但这个200ms并非收到数据后需要延迟的时间。系统有一个固定的定时器每隔200ms会来检查是否需要发送ACK包。这样做有两个目的。

1、这样做的目的是ACK是可以合并的，也就是指如果连续收到两个TCP包，并不一定需要ACK两次，只要回复最终的ACK就可以了，可以降低网络流量。
2、如果接收方有数据要发送，那么就会在发送数据的TCP数据包里，带上ACK信息。这样做，可以避免大量的ACK以一个单独的TCP包发送，减少了网络流量。

TCP的三次握手，四次分手

如下图：

1种状态，在整个TCP建立连接和断开连接的整个过程！

面分开来详细看，首先是三次握手

上面这个图就是完整的三次握手过程

• 首先由 client 发出请求连接，即SYN=1 ACK=0，TCP 规定 SYN=1 时不能携带数据，但要消耗一个 seq，所以声明自己的seq=x

• 然后 Server 进行回复确认，即 SYN=1 ACK=1 seq=y ack=x+1

• 最后 Client 再进行一次确认，但不用SYN了，即ACK=1 seq=x+1 ack=y+1

整个过程中对应的TCP状态如下：

• CLOSED：初始状态，表示TCP连接是”关闭着的”或”未打开的”

• LISTEN：表示服务器端的某个SOCKET处于监听状态，可以接受客户端的连接

• SYN_RCVD：表示服务器接收到了来自客户端请求连接的SYN报文。这个状态是在服务端的，但是它是一个中间状态，很短暂，平常我们用netstat或ss的时候，不太容易看到这种状态，但是遇到SYN flood之类的SYN攻击时，会出现大量的这种状态，即收不到三次握手最后一个客户端发来的ACK，所以一直是这个状态，不会转换到ESTABLISHED

• SYN_SENT：这个状态与SYN_RCVD状态相呼应，，它是TCP连接客户端的状态，当客户端SOCKET执行connect()进行连接时，它首先发送SYN报文，然后随机进入到SYN_SENT状态，并等待服务端的SYN和ACK，该状态表示客户端的SYN已发送

• ESTABLISHED：表示TCP连接已经成功建立，开始传输数据

以上就是三次握手的五种TCP状态，单从客户端服务端角度来区分的话，CLOSED和ESTABLISHED会在客户端和服务端都出现，而LISTEN和SYN_RCVD通常是出现在服务端，SYN_SENT出现在客户端

接着看四次挥手的状态

数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗

6. MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

7. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

其大体流程如下：

• 客户端发其结束请求，发送seq=X，处于FIN_WAIT_1状态

• 服务端收到结束请求，发送应答ACK=X+1，处于CLOSE_WAIT状态

• 客户端收到X的应答后，处于FIN_WAIT_2状态，此时还可以接收来自服务端的数据

• 服务端没有数据要发送，也发送结束请求，seq=Y,处于LAST_ACK状态

• 客户端又收到服务端的结束请求，客户端回应ACK，此时处于TIME_WAIT状态，确保ACK能够到达服务端；服务端收到客户端最终ACK，关闭连接。

• 2MSL时间结束后，无论服务端是否收到最终ACK，客户端完全结束连接

补充一下为什么要四次挥手

为什么建立一个TCP连接需要三次握手，而终止一个连接需要四次挥手呢？这是因为TCP半关闭造成的。由于一个TCP连接是全双工的，在两个方向上都能传输数据，因此两个方向就需要单独关闭。所以这个流程是这样的：

• 客户端执行主动关闭，发送FIN报文，告诉服务端，我没有数据要发送了，我要关闭连接，当然了，你有啥数据要给我，我随时候着

• 服务端收到后，必须及时告诉客户端我收到了，因此先回复客户端一个ACK。但是服务端可能还有未发送完的数据，因此它可以将自己未完成的数据进行发送，发送完成之后，再发送给客户端FIN报文，表明我也没啥要发送的了，关闭吧

• 客户端收到后，也回复ACK响应，最终关闭连接

因而整个过程需要四次挥手。

为何快速重传是选择3次ACK？

主要的考虑还是要区分包的丢失是由于链路故障还是乱序等其他因素引发。两次duplicated ACK时很可能是乱序造成的！三次duplicated ACK时很可能是丢包造成的！四次duplicated ACK更更更可能是丢包造成的！但是这样的响应策略太慢。丢包肯定会造成三次duplicated ACK!综上是选择收到三个重复确认时窗口减半效果最好，这是实践经验。

ACK丢失情形：

网络延时的情况：

重复ACK

数据包（1000~1499） 被网络延迟了，导致「发送方」没有收到 Ack 1500 的确认报文。

而后面报文到达的三个相同的 ACK 确认报文，就触发了快速重传机制，但是在重传后，被延迟的数据包（1000~1499）又到了「接收方」；

所以「接收方」回了一个 SACK=1000~1500，因为 ACK 已经到了 3000，所以这个 SACK 是 D-SACK，表示收到了重复的包。

这样发送方就知道快速重传触发的原因不是发出去的包丢了，也不是因为回应的 ACK 包丢了，而是因为网络延迟了

网友@楚来客是这个回答的

参考：httpss://blog.youkuaiyun.com/u010202588/article/details/54563648

在没有fast retransmit / recovery 算法之前，重传依靠发送方的retransmit timeout，就是在timeout内如果没有接收到对方的ACK，默认包丢了，发送方就重传，包的丢失原因1）包checksum 出错 2）网络拥塞 3）网络断，包括路由重收敛，但是发送方无法判断是哪一种情况，于是采用最笨的办法，就是将自己的发送速率减半，即CWND 减为1/2，这样的方法对2是有效的，可以缓解网络拥塞，3则无所谓，反正网络断了，无论发快发慢都会被丢；但对于1来说，丢包是因为偶尔的出错引起，一丢包就对半减速不合理。于是有了fast retransmit 算法，基于在反向还可以接收到ACK，可以认为网络并没有断，否则也接收不到ACK，如果在timeout 时间内没有接收到> 2 的duplicated ACK，则概率大事件为乱序，乱序无需重传，接收方会进行排序工作；而如果接收到三个或三个以上的duplicated ACK，则大概率是丢包，可以逻辑推理，发送方可以接收ACK，则网络是通的，可能是1、2造成的，先不降速，重传一次，如果接收到正确的ACK，则一切OK，流速依然（包出错被丢）。而如果依然接收到duplicated ACK，则认为是网络拥塞造成的，此时降速则比较合理。

补充：

常用的熟知端口号

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

为什么握手不能是两次呢？

如果只有两次握手，女孩子可能就不知道，她的那句我也爱你，男孩子是否收到，恋爱关系就不能愉快展开。

为什么握手不能是四次呢？

因为握手不能是四次呢？因为三次已经够了，三次已经能让双方都知道：你爱我，我也爱你。而四次就多余了。

补充：

动画：一招学会TCP的三次握手和四次挥手

为什么要四次挥手

为什么建立一个TCP连接需要三次握手，而终止一个连接需要四次挥手呢？这是因为TCP半关闭造成的。由于一个TCP连接是全双工的，在两个方向上都能传输数据，因此两个方向就需要单独关闭。所以这个流程是这样的：

• 客户端执行主动关闭，发送FIN报文，告诉服务端，我没有数据要发送了，我要关闭连接，当然了，你有啥数据要给我，我随时候着

• 服务端收到后，必须及时告诉客户端我收到了，因此先回复客户端一个ACK。但是服务端可能还有未发送完的数据，因此它可以将自己未完成的数据进行发送，发送完成之后，再发送给客户端FIN报文，表明我也没啥要发送的了，关闭吧

• 客户端收到后，也回复ACK响应，最终关闭连接

因而整个过程需要四次挥手~

我是程序员小于哥

@终端研发部

一个执着于技术的小猿猿，每天专注于技术开发小技巧，职场经验的分享，我希望我的回答能够给大家一些帮助哈～

本文篇幅不短，而且都是根据本人的技术面试官经验总结而成，所以对大家多少会有些帮助。如果大家看到稍有可取之处，也请劳驾点个赞。大家的赞，是对我最大的支持。

最后说一句（别白嫖，求关注）

回复 【idea激活】即可获得idea的激活方式
回复 【Java】获取java相关的视频教程和资料
回复 【SpringCloud】获取SpringCloud相关多的学习资料
回复 【python】获取全套0基础Python知识手册
回复 【2020】获取2020java相关面试题教程
回复 【加群】即可加入终端研发部相关的技术交流群
阅读更多
用 Spring 的 BeanUtils 前，建议你先了解这几个坑！

lazy-mock ，一个生成后端模拟数据的懒人工具

在华为鸿蒙 OS 上尝鲜，我的第一个“hello world”，起飞！

字节跳动一面：i++ 是线程安全的吗？

一条 SQL 引发的事故，同事直接被开除！！

太扎心！排查阿里云 ECS 的 CPU 居然达100%

一款vue编写的功能强大的swagger-ui，有点秀（附开源地址）


相信自己，没有做不到的，只有想不到的在这里获得的不仅仅是技术！



喜欢就给个“在看”