大家好,我是小杰。

接着上篇:


上次说完了TCP的三次握手和四次挥手,接下来我们接着实验。

TCP的最大报文长度MMS

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

实验走起:

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

TCP/IP协议之四TCP协议(中)—理论+实践给你讲清楚_服务器

有蹊跷

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

TCP/IP协议之四TCP协议(中)—理论+实践给你讲清楚_网络资源_02

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

原因

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

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

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

TCP/IP协议之四TCP协议(中)—理论+实践给你讲清楚_数据_03

TCP延时确认

延时确认背景

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

TCP/IP协议之四TCP协议(中)—理论+实践给你讲清楚_服务器_04

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

TCP流量控制

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

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

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

发送窗口

TCP/IP协议之四TCP协议(中)—理论+实践给你讲清楚_数据_05

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

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

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

过程

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

接收窗口

TCP/IP协议之四TCP协议(中)—理论+实践给你讲清楚_服务器_06

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

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

过程

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