大厂必问题：三次握手、四次挥手、最大报文段长度、流量控制实践
接着上篇：
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流量控制
当通信双方的能力较差，而通信链路上的网速较好时，流量控制就将其作用发挥到了极致。
- 一旦发送发发送的数据过快，而接收方的数据处理不过来，那么将发生数据的丢失问题，一旦数据丢失就需要重传，那么就会浪费网络资源
- TCP协议利用滑动窗口机制来实现流量控制
双方均维护着自己的发送缓冲区和接收缓冲区，我们分开来看
发送窗口
从图中可以看出之所以称之为滑动窗口，是因为它左右各维护了一个指针，形成中间的窗口部分，总体趋势是向右滑动，同时指针可单独向右移动以控制整个窗口的大小。
- 灰色表示已传送并接收端已经确认，并从发送缓冲区清楚
- 蓝色表示已经传送，但是未被确认
- 黄色标识准备传送的数据
- 紫色表示等待传送的数据
2，3，4加起来表示发送缓冲区的大小
过程
- 发送窗口现在包含已经传送，但是未被确认的数据和准备传送的数据
- 有两个数据被确认，左指针向右进行滑动，右指针不变
- 接收窗口大于发送窗口，于是发送窗口增大，右指针向右进行滑动，左指针不变
接收窗口
- 灰色表示应用层已经读取，并从缓冲区清除的数据
- 蓝色表示已经接收，并被确认的数据
- 黄色表示等待接收资料的空缓冲区
- 紫色表示缓冲区中剩余未用的空间
2，3加起来就是接收缓冲区的大小
过程
- 接收缓冲区现在处于等待接收资料状态
- 有两个资料放到了窗口内，但是还未被应用层读取，于是左指针向右移动，右指针不变
- 有两个资料被应用层读取，并从缓冲区清除的数据，于是右指针向右移动，左指针不变
往期精彩：
高频面试题之汉诺塔：动图演示太好理解啦！
