本文共 1366 字，大约阅读时间需要 4 分钟。

前言

网络层只是尽可能努力地传输、但是不保证传输的正确性，是不可靠传输，所以需要传输层来实现可靠传输、传输层中两大常用协议有TCP和UDP，这里只讲TPC是如何实现可靠传输的

何为可靠传输？
保证接收方进程从缓存中读出的字节流和发送方输出的字节流一毛一样（顺序以及数量以及内容）

那么TPC是怎么实现可靠传输的呢？

1. 校验
2. 序号
3. 确认
4. 重传

1 序号和校验

1. 通过在报文段增加伪首部（UDP也是通过伪首部校验），其中报文段内容的一个字节占用一个序号（序号字段指一个报文段第一个字节的序号）
2. TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。
3. 这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

2 确认

假设发送方在发送缓存中有某报文段A，在发送到接收方的接收缓存中后，不会立刻删除报文段A，而是等待接收方返回一个确认信息，再删除报文段，防止发送途中丢失该报文段A

要注意的是：

1. 接收方返回的确认报文段不一定单独发送，有可能也会随着一些数据的发送而被携带上；
2. 确认报文段首部确认号为已传输数据最大的序号+1，如已发送1，2，3，则确认报文段首部确认号字段为4；
3. TPC使用累计确认；

何为累计确认：

假设本次传输是按照A,B,C顺序传输这三个报文段，A和C都被成功接收，B丢了，接收方察觉A和C顺序不对，则不会返回C的确认数据报，只会返回A报文段最后一个数据序号+1的确认，如此一来发送方也会察觉到B的丢失，且返回确认信息报中的序号之前的全部数据都被正常接收!

3 重传

确认重传不分家，TCP发送方在规定时间内没收到确认就会重传已发送的数据报，简称 “超时重传”。

这里我们思考2个重传会出现的问题：

1. 报文被分成报文段传播的时候，每个报文段传输的路径并不一致，路线长短、所处网络环境不尽相同，每个报文段到达接收方的时间无法确定；
2. 如果超时重传的超时时长过短，发送方会多发送一些不必要的数据，增大网络负荷和服务器开销；

TCP协议为了解决以上问题，采取了自适应算法：动态改变重传时间RTTs（加权平均往返时间）

简单介绍下RTTs的原理：

1. 假设发送方发送A,B,C三个报文段的时候，A发送后到接收到对于A的确认报文的时间T1, B发送后到接收到对于B的确认报文的时间T2,C发送后到接收到对于A的确认报文的时间T3
2. 然后使用T1,T2,T3这三个数据进行特殊计算，这里不讲高数了，最后将算出的结果动态赋值；

那么此时又又又出现一个小问题：

发送方在发送完毕报文，并且等待接收方返回确认报文段，直到超时的这段时间，岂不是白白浪费了？

嘿嘿你都能想到这个问题，设计TCP的大佬想不到吗~

大佬采用一个学名叫做：冗余ACK（冗余确认）的方式来解决

• 冗余ACK：每当比期望序号大的失序报文到达时，发送一个冗余ACK，指明下一个期待的字节的序号！
• 举个栗子：发送方发送A,B,C,D四个报文段，此时已收到了A，但是B丢了，此时接收方的期望值就是A最后一个字节的序号+1，此时正好C过来了，发现C的第一个字节序号不是期望的，直接就返回对A报文段的确认，D来了也是只返回A的确认，这时候发送方就明白了：原来老子的B丢了！我这就重新发！这个过程又可以称之为 “快速重传”

转载地址：https://blog.csdn.net/weixin_40597409/article/details/122760486 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！