TCP传输的数据切片与ACK介绍

你的名字 2022-11-14 10:17 450阅读 0赞

### 前言 ###

写这篇文章的初衷是为了总结TCP传输过程，利用Socket抓包进行测试。、  
重点探讨了传输层的数据切片以及接受包后的ACK机制。

#### TCP传输示例 ####

![image-20210328143819605][]

上方是三次握手建立连接

红框为传数据

下方四次挥手断开连接

注意传输的TCP数据部分最大即1460字节，因为在传输层进行了分片。

MTU为1500，考虑到数据链路层传输限制，要保证最大长度为**MTU - IP首部（20） - TCP首部（20）。**

#### IP数据包分片 ####

参考文献  
[https://my.oschina.net/xinxingegeya/blog/483138][https_my.oschina.net_xinxingegeya_blog_483138]

[https://blog.csdn.net/passionkk/article/details/100538418][https_blog.csdn.net_passionkk_article_details_100538418]

[https://blog.csdn.net/qq\_22238021/article/details/80476498][https_blog.csdn.net_qq_22238021_article_details_80476498]

[https://blog.csdn.net/holyshit666/article/details/52601024][https_blog.csdn.net_holyshit666_article_details_52601024]

**为什么需要分片？**

因为链路层有**最大的承载数据量限制**

当两台主机之间的通信要通过多个具有不同MTU值的网络时，MTU的瓶颈是**通信路径上最小的MTU值**，它被称为路径MTU。

**举例**

举一个最简单的场景，你在家用自己的笔记本上网，用的是路由器，路由器连接电信网络，然后访问了`www.baidu.com`，从你的笔记本出发的一个以太网数据帧总共经过了以下路径：

笔记本 -> 路由器 -> 电信机房 -> 服务器

其中，每个节点都有一个MTU值，如下：

1500     1500                 1500
    笔记本 -> 路由器 -> 电信机房  -> 服务器

假设现在我把笔记本的MTU最大值设置成了1700，然后发送了一个超大的ip数据包（2000），这时候在以外网传输的时候会被拆成2个包，一个1700，一个300，然后加上头信息进行传输。

1700     1500                1500
    笔记本 -> 路由器 -> 电信机房 -> 服务器

路由器接收到了一个1700的帧，发现大于自己设置的最大值：1500，如果IP包DF标志位为1，也就是不允许分包，那么路由器直接就把这个包丢弃了，根本就不会到达电信机房，也就到不了服务器了，所以，到这里我们就会发现，MTU其实就是在每一个节点的管控值，只要是大于这个值的数据帧，要么选择分片，要么直接丢弃。

> 在TCP/IP分层中，数据链路层用MTU（Maximum Transmission Unit，最大传输单元）来限制所能传输的数据包大小，MTU是指一次传送的数据最大长度，不包括数据链路层数据帧的帧头，如以太网的MTU为1500字节，实际上数据帧的最大长度为1512字节，其中以太网数据帧的帧头为12字节。
> 
> 当发送的IP数据报的大小超过了MTU时，IP层就需要对数据进行分片，否则数据将无法发送成功。
> 
> MTU （最大传输单元）决定 IP报文是否分片。

**避免IP层分片（传输层进行分片）**

在网络编程中，我们要避免出现IP分片，那么为什么要避免呢？\*\*\*原因是IP层是没有超时重传机制的 ，如果IP层对一个数据包进行了分片，只要有一个分片丢失了，只能依赖于传输层进行重传，结果是所有的分片都要重传一遍，这个代价有点大。\*\*\****由此可见，IP分片会大大降低传输层传送数据的成功率，所以我们要避免IP分片。***

对于TCP协议，应用层就不需要考虑这个问题了，因为传输层已经帮我们做了。***在建立连接的TCP三次握手的过程中，连接双方会相互通告MSS（Maximum Segment Size，最大报文段长度1460），MSS一般是MTU - IP首部（20） - TCP首部（20），每次发送的TCP数据都不会超过双方MSS的值，所以就保证了IP数据报不会超过MTU，避免了IP分片。***

![img][]

> 如果发送一段2000字节的TCP报文，那么会导致TCP分段，**因为其超过了最大报文段的长度，一般是MTU - IP首部（20） - TCP首部（20）。**
> 
> 分段后的每一段TCP报文段再加上IP首部后的长度不可能超过MTU，因此也就不需要在网络层进行IP分片了。因此TCP报文段很少会发生IP分片的情况。

#### TCP报文送达确认ACK机制 ####

[https://blog.csdn.net/cd\_yourheart/article/details/108245652][https_blog.csdn.net_cd_yourheart_article_details_108245652]

[https://blog.csdn.net/woshifennu1234/article/details/78349302][https_blog.csdn.net_woshifennu1234_article_details_78349302]

由于通信过程的不可靠性，传输的数据不可避免的会出现丢失、延迟、错误、重复等各种状况，TCP协议为解决这些问题设计了一系列机制。这个机制的核心，就是发送方向接收方发送数据后，接收方要向发送方发送ACK（回执）。如果发送方没接收到正确的ACK，就会重新发送数据直到接收到ACK为止。比如：发送方发送的数据序号是seq，那么接收方会发送seq + 1作为ACK，这样发送方就知道接下来要发送序号为seq + 1的数据给接收方了。

![img][img 1]

*  **数据丢失或延迟**。发送方发送数据seq时会起一个定时器，如果在指定时间内没有接收到ACK seq + 1，就把数据seq再发一次。
 *  **数据乱序**。接收方上一个收到的正确数据是seq + 4，它返回seq + 5作为ACK。这时候它收到了seq + 7，因为顺序错了，所以接收方会再次返回seq + 5给发送方。
 *  **数据错**。每一个TCP数据都会带着数据的校验和。接收方收到数据seq + 3以后会先对校验和进行验证。如果结果不对，则发送ACK seq + 3，让发送方重新发送数据。
 *  **数据重复**。接收方直接丢弃重复的数据即可。
    
        TCP的报文到达确认（ACK），是对接收到的数据的最高序列号的确认，并向发送端返回一个下次接收时期望的TCP数据包的序列号（Ack Number）。例如，主机A发送的当前数据序号是400，数据长度是100，则接收端收到后会返回一个确认号是501的确认号给主机A。

TCP提供的确认机制，可以在通信过程中可以不对每一个TCP数据包发出单独的确认包（Delayed ACK机制），而是在传送数据时，顺便把确认信息传出，这样可以大大提高网络的利用率和传输效率。同时，TCP的确认机制，也可以一次确认多个数据报，例如，接收方收到了201，301，401的数据报，则只需要对401的数据包进行确认即可，对401的数据包的确认也意味着401之前的所有数据包都已经确认，这样也可以提高系统的效率。

若发送方在规定时间内没有收到接收方的确认信息，就要将未被确认的数据包重新发送。**接收方如果收到一个有差错的报文，则丢弃此报文，并不向发送方发送确认信息**。因此，TCP报文的重传机制是由设置的超时定时器来决定的，在定时的时间内没有收到确认信息，则进行重传。这个定时的时间值的设定非常重要，太大会使包重传的延时比较大，太小则可能没有来得及收到对方的确认包发送方就再次重传，会使网络陷入无休止的重传过程中。接收方如果收到了重复的报文，将会丢弃重复的报文，但是必须发回确认信息，否则对方会再次发送。

TCP协议应当保证数据报按序到达接收方。如果接收方收到的数据报文没有错误，只是未按序号，这种现象如何处理呢？TCP协议本身没有规定，而是由TCP协议的实现者自己去确定。通常有两种方法进行处理：一是对没有按序号到达的报文直接丢弃，二是将未按序号到达的数据包先放于缓冲区内，等待它前面的序号包到达后，再将它交给应用进程。后一种方法将会提高系统的效率。例如，发送方连续发送了每个报文中100个字节的TCP数据报，其序号分别是1，101，201，…,701。假如其它7个数据报都收到了，而201这个数据报没有收到，则接收端应当对1和101这两个数据报进行确认，并将数据递交给相关的应用进程，301至701这5个数据报则应当放于缓冲区，等到201这个数据报到达后，然后按序将201至701这些数据报递交给相关应用进程，并对701数据报进行确认，确保了应用进程级的TCP数据的按序到达。

TCP协议中，接收方成功接收到数据后，会回复一个ACK数据包，表示已经确认接收到ACK确认号前面的所有数据。ACK字段长度为32位，能表示0~2^32-1之间的值。

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

接收方在接收到数据后，不是立即会给发送方发送ACK的。这可能由以下原因导致：

1、收到数据包的序号前面还有需要接收的数据包。因为发送方发送数据时，并不是需要等上次发送数据被Ack就可以继续发送TCP包，而这些TCP数据包达到的顺序是不保证的，这样接收方可能先接收到后发送的TCP包（注意提交给应用层时是保证顺序的）。

2、为了降低网络流量，ACK有延迟确认机制。

3、ACK的值到达最大值后，又会从0开始。

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

1、这样做的目的是ACK是可以合并的，也就是指如果连续收到两个TCP包，并不一定需要ACK两次，只要回复最终的ACK就可以了，可以降低网络流量。

2、如果接收方有数据要发送，那么就会在发送数据的TCP数据包里，带上ACK信息。这样做，可以避免大量的ACK以一个单独的TCP包发送，减少了网络流量。

#### TCP校验和 ####

参考  
[https://blog.csdn.net/qq\_15437629/article/details/79183076][https_blog.csdn.net_qq_15437629_article_details_79183076]  
TCP校验和（Checksum）是一个端到端的校验和，由发送端计算，然后由接收端验证。其目的是为了发现TCP首部和数据在发送端到接收端之间发生的任何改动。如果接收方检测到校验和有差错，则TCP段会被直接丢弃。

举个例子来解释该校验方法：

![这里写图片描述][df9b2cefdb51e886b3f0aea2dc8ac22b.png]

1、首先将检验和置零；  
2、然后将TCP伪首部部分，TCP首部部分，数据部分都划分成16位的一个个16进制数  
3、将这些数逐个相加，记得溢出的部分加到最低位上，这是循环加法：  
0xc0a8+ 0x0166+……+0x0402=0x9b49  
4、最后将得到的结果取反，则可以得到检验和位0x64b6

[image-20210328143819605]: /images/20221022/cff2ceb55dd24bf3935dd33126c6b3ae.png
[https_my.oschina.net_xinxingegeya_blog_483138]: https://my.oschina.net/xinxingegeya/blog/483138
[https_blog.csdn.net_passionkk_article_details_100538418]: https://blog.csdn.net/passionkk/article/details/100538418
[https_blog.csdn.net_qq_22238021_article_details_80476498]: https://blog.csdn.net/qq_22238021/article/details/80476498
[https_blog.csdn.net_holyshit666_article_details_52601024]: https://blog.csdn.net/holyshit666/article/details/52601024
[img]: /images/20221022/0e21bb9dc25949cca476828bc83bc20a.png
[https_blog.csdn.net_cd_yourheart_article_details_108245652]: https://blog.csdn.net/cd_yourheart/article/details/108245652
[https_blog.csdn.net_woshifennu1234_article_details_78349302]: https://blog.csdn.net/woshifennu1234/article/details/78349302
[img 1]: /images/20221022/ff2aed638b964ea2b6c7c588944ecbf2.png
[https_blog.csdn.net_qq_15437629_article_details_79183076]: https://blog.csdn.net/qq_15437629/article/details/79183076
[df9b2cefdb51e886b3f0aea2dc8ac22b.png]: https://img-blog.csdnimg.cn/img_convert/df9b2cefdb51e886b3f0aea2dc8ac22b.png