本文共 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 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！