大厂必问题：三次握手、四次挥手、最大报文段长度、流量控制实践

接着上篇：
TCP协议理论和三次握手四次挥手实践

欢迎大家收藏和点赞，也欢迎大家在评论区和我一起交流哦~

TCP的最大报文长度MMS

上篇提到了以太网协议有MTU的概念，会限制IP数据包的大小不能超过MTU否则会进行ip数据包的分包，TCP协议中的选项部分包含MSS的概念，在连接建立的时候进行MMS大小互通，这样发送时候以最小的MSS来决定发送数据报的大小。

实验走起：

下面的截图是我使用两个服务器A和服务器B，从服务器A中利用tcpdump抓包获取的数据，服务器B向服务器A发送了2048字节的数据，关键的信息我已经使用红色的线段标出来啦，可见始终没有超过MSS的值。

有蹊跷

如果仅仅如此的话，那么我的实验毫无意义！大家可以接着看，我又有了新的发现：

这次我用黄色的线标出来啦，既然mss的值都是1460那么为什么这里的TCP报文段可以达到2048呢？我开始查阅各种资料寻找问题的根源，最后我找到了原因。

原因

说起这个不得不提到现代网卡的特性TCP Segmentation Offload（TOS），这个功能存在的目的就是为了解决过多的TCP报文段组装引起CPU的任务量增加问题，因此网卡挺身而出扛下来所有，将这个事情自己做，做好了之后交给内核。

通俗的来讲，就是在路由器之间传输任然是受到MSS的限制，但是对于网卡开启TSO特性的主机来说，接收到TCP报文段后都是由网卡进行报文段的组装，然后再交给系统的内核处理，而tcpdum是再内核处截获封包，因此它截取到的就是已经组装好的！

在这里可以给大家看一下TSO特性，我已经给大家标出来啦

TCP延时确认

延时确认背景

某些场景的要求下，需要频繁的在网络中传输数据，例如回显服务器。每输入一个字符就需要服务器发送一次确认，这就会大大的浪费网络资源，为了更有利于对网络资源的合理化利用，便有了时延确认，也就是服务器在回复带有ACK的确认报文段的时候与下一次需要发送的报文段合并成同一个。

通常延时确认是有时间限制的，也就是在收到后会开启一个定时器，如果下一个包在定时器结束之后还没有，那么就会单独进行确认，否则跟下一个包合并成一个报文段。这个时间通常是200ms。

TCP流量控制

当通信双方的能力较差，而通信链路上的网速较好时，流量控制就将其作用发挥到了极致。

1. 一旦发送发发送的数据过快，而接收方的数据处理不过来，那么将发生数据的丢失问题，一旦数据丢失就需要重传，那么就会浪费网络资源
2. TCP协议利用滑动窗口机制来实现流量控制

双方均维护着自己的发送缓冲区和接收缓冲区，我们分开来看

发送窗口

从图中可以看出之所以称之为滑动窗口，是因为它左右各维护了一个指针，形成中间的窗口部分，总体趋势是向右滑动，同时指针可单独向右移动以控制整个窗口的大小。

1. 灰色表示已传送并接收端已经确认，并从发送缓冲区清楚
2. 蓝色表示已经传送，但是未被确认
3. 黄色标识准备传送的数据
4. 紫色表示等待传送的数据

2，3，4加起来表示发送缓冲区的大小

过程

1. 发送窗口现在包含已经传送，但是未被确认的数据和准备传送的数据
2. 有两个数据被确认，左指针向右进行滑动，右指针不变
3. 接收窗口大于发送窗口，于是发送窗口增大，右指针向右进行滑动，左指针不变

接收窗口

1. 灰色表示应用层已经读取，并从缓冲区清除的数据
2. 蓝色表示已经接收，并被确认的数据
3. 黄色表示等待接收资料的空缓冲区
4. 紫色表示缓冲区中剩余未用的空间

2，3加起来就是接收缓冲区的大小

过程

1. 接收缓冲区现在处于等待接收资料状态
2. 有两个资料放到了窗口内，但是还未被应用层读取，于是左指针向右移动，右指针不变
3. 有两个资料被应用层读取，并从缓冲区清除的数据，于是右指针向右移动，左指针不变

往期精彩：
高频面试题之汉诺塔：动图演示太好理解啦！