计算机网络：流量控制与可靠传输机制

目录

基本概念

流量控制：别噎着啦！

可靠传输：快递必达服务

传输差错：现实中的意外

滑动窗口

基本概念

换句话说：批量发货+排队验收

停止-等待协议 SW（发1份等1份）

超时重传：

分组编号：

信道利用率

回退N帧协议 GBN（批量发货，错了就从错的重发！）

选择重传协议 SR（只补丢的那杯）

---

基本概念

流量控制：别噎着啦！

概念：流量控制涉及对链路上的帧的发送速率的控制，以使接收方有足够的缓冲空间来接收每个帧（数据链路层，点到点；传输层也有流量控制，端到端）巴拉巴拉～～

🍔 吃汉堡比喻：

• 你（发送方）喂朋友（接收方）吃汉堡

• 朋友嘴里塞满时说："慢点！等我咽下去再喂！" → 这就是流量控制

• 如果不管不顾猛塞，朋友会吐（缓冲区溢出）

📱 手机内存例子：

• 旧手机接收大文件时跳提示："存储空间不足"

• 发送方需要暂停发送 → 流量控制起作用

可靠传输：快递必达服务

概念：尽管误码是不能完全避免的，但若能实现发送方发送什么，接收方就能收到什么，就称为可靠传输 => 有确认机制和超时重传机制 巴拉巴拉～～

换句话说：丢了就重发！

📦 网购快递场景：

1. 商家发货后要求："收到请按1"（确认ACK）

2. 三天没回复？自动补发（超时重传）

3. 收到破损件？申请换货（差错重传）

🚚 特别服务对比：

• 普通快递（UDP）：丢了不赔

• 顺丰保价（TCP）：丢件必赔

传输差错：现实中的意外

1、比特错误：使用差错检测技术，接收方的数据链路层就可检测出帧在传输过程中是否产生了误码

2、分组丢失、分组失序和分组重复：一般不出现在数据链路层，而在上层

🔧 常见问题：

• 比特错误 → 就像快递单被雨水打糊

• 分组丢失 → 快递车半路抛锚

• 分组乱序 → 快递员不按楼层送货

• 分组重复 → 商家不小心发了两件

🌐 有线vs无线：

网络类型	好比...	可靠性需求
有线网络	室内通话	小声说也能听清（一般不重传）
无线网络	工地对讲机	必须重复确认（必须可靠传输）

一般情况下，有线链路的误码率比较低，为了减小开销，并不要求数据链路层向上提供可靠传输服务。即使出现了误码，可靠传输的问题由其上层处理

无线链路易受干扰，误码率比较高，因此要求数据链路层必须向上层提供可靠传输服务

---

滑动窗口

基本概念

发送（接收）方维持一组连续的允许发送（接收）的帧的序号，称为发送（接收）窗口

发送方：发送窗口的大小代表在还未收到对方确认信息的情况下发送方最多还可以发送多少个数据帧。只有发送方接收到确认帧后发送窗口才可能向前滑动

接收方：只有收到数据帧的序号落在接收窗口内，才允许将帧收下，否则丢弃

换句话说：批量发货+排队验收

场景：奶茶店一次做5杯奶茶（窗口大小=5），顾客按顺序取。

• 发送方：连续做5杯（不用等每杯确认），但最多做5杯。

• 接收方：只按顺序喝，如果第3杯洒了，要求从第3杯重做（回退N帧）。

帧缓冲区：

1、目的：为了超时重发和判定重复帧的需要

2、实现方式：发送端在发送完数据帧时，必须在其发送缓存中保留此数据帧的副本，这样才能在出错时进行重传（只有收到确认帧ACK时，才删除副本）

停止-等待协议 SW（发1份等1份）

从滑动窗口机制的角度看，停止-等待协议相当于发送窗口和接收窗口大小均为1的滑动窗口协议

超时重传：

1、接收端检测到数据分组有误码时，将其丢弃并等待发送方的超时重传

2、重传时间一般略大于平均往返时间（平均 RTT），因为代价大，需要多来点时间避免又错啦！

分组编号：

为了让接收方（发送方）能够判断收到的数据分组是否重复，需要给数据（ACK）分组编号。由于停-等协议特性，只需一个比特编号即可（0、1）

场景：你给同学传纸条，必须等他回复“收到”再传下一张。

• 优点：简单。

• 缺点：慢！（像玩“你拍一我拍一”）

信道利用率

1、发送方在一个发送周期内，有效发送数据的时间占整个发送周期的比例

2、信道利用率U = TD / (TD + RTT + TA)

回退N帧协议 GBN（批量发货，错了就从错的重发！）

1、发送方连续发送帧，当接收方检测出失序的信息帧后，要求发送方重发最后一个正确接收的信息帧后的所有未被确认帧

场景：你开了一家奶茶店，顾客一次性点了5杯奶茶（编号1~5）。

• 正常情况：你按顺序做好5杯，顾客按顺序喝（1→2→3→4→5）。

• 出错情况：如果第3杯做错了（帧错误），顾客会说：“从第3杯开始，全部重做！”

  • 于是你把第3、4、5杯都重新做一遍（回退N帧）。

2、n比特编号，发送窗口大小：1 <= WT <= 2^n - 1 接收窗口大小：1

• 发送窗口（WT）：你最多能同时做多少杯奶茶（比如最多5杯）。

  • 如果编号用n个比特，最多能发 2^n - 1 杯（比如n=3，最多发7杯）。

• 接收窗口（WR）=1：顾客一次只喝1杯，必须按顺序，乱了就扔掉。

3、累计确认

• 顾客喝了第1、2、3杯后，只回复“3号收到”（代表1~3都OK）。

• 如果你没收到确认，就全部重发（比如3号丢了，就重发3~5）。

稍待确认：或者在自己有数据分组要发送时才按累计确认规则进行捎带确认

4、缺点

若信道的传输质量很差导致误码率较大时，不一定优于停止-等待协议

选择重传协议 SR（只补丢的那杯）

1、概述：设法只重传出现差错的数据帧和计时器超时的数据帧

• 每个发送缓冲区对应一个计时器，当计时器超时时，缓冲区的帧就会重传
• 一旦接收方怀疑帧出错，就会发一个否定帧NAK给发送方，要求发送方对NAK中指定的帧进行重传
• 接收端要设置具有相当容量的缓冲区来暂存那些未按序正确收到的帧

场景：奶茶店发现第3杯做错了，只重做第3杯，其他照常给。

• 优点：高效。

• 缺点：需要记录哪杯错了（复杂）。

2、缺点：需要开辟缓存空间用来存储数据

3、n比特编号，窗口大小：WR <= 2^(n-1)