当前位置: 首页 > ai >正文

【计算机网络】第3章:传输层—可靠数据传输的原理

目录

一、PPT

二、总结

(一)可靠数据传输原理

关键机制

1. 序号机制 (Sequence Numbers)

2. 确认机制 (Acknowledgements - ACKs)

3. 重传机制 (Retransmission)

4. 校验和 (Checksum)

5. 流量控制 (Flow Control)

协议实现的核心:滑动窗口协议 (Sliding Window Protocol)

两种主要变体

(二)可靠数据传输协议(Rdt)演进详解

核心目标

Rdt 1.0:理想信道模型

假设条件

工作机制

缺陷

Rdt 2.0:引入差错检测与确认机制

解决核心问题

关键技术

有限状态机(FSM)

缺陷

Rdt 2.1:解决确认信号受损

核心改进

关键行为

优势

Rdt 2.2:无NAK确认协议

核心改进

接收方行为

优势

Rdt 3.0:解决丢包与超时重传

解决核心问题

关键技术

有限状态机(FSM)关键流程

性能问题

协议演进总结对比

后续演进方向


一、PPT

 

二、总结

(一)可靠数据传输原理

核心目标:确保数据在不可靠信道(可能发生比特差错、分组丢失、乱序、重复)上完整、有序、无重复地交付给接收方。

关键机制

1. 序号机制 (Sequence Numbers)

  • 作用:标识每个发送的数据段。

  • 原理

    • 发送方为每个数据段分配一个唯一的序号(通常是字节流中的偏移量或分组编号)。

    • 接收方利用序号:

      • 检测丢失分组:发现序号间隙。

      • 检测重复分组:收到相同序号的分组。

      • 按序重组:将乱序到达的分组按序号排序后交付上层。

  • 序号空间:序号需足够大(模运算处理回绕),常见32位(TCP)。

2. 确认机制 (Acknowledgements - ACKs)

  • 作用:接收方通知发送方已成功接收数据。

  • 原理

    • 累积确认 (Cumulative ACK)

      • 接收方发送 ACK n,表示已正确接收序号 n 之前(包括 n)的所有数据。

      • 优点:简单,ACK丢失容忍度较高(后续ACK能确认前面的数据)。

      • 缺点:不能精确告知哪些分组丢失(只能知道n+1丢失)。

    • 选择确认 (Selective ACK - SACK)

      • 接收方显式告知已正确接收的非连续数据块范围。

      • 优点:更高效地指明丢失分组,减少不必要的重传。

      • 缺点:实现更复杂,需要额外选项字段(TCP SACK)。

    • 否定确认 (Negative ACK - NAK)

      • 接收方显式通知发送方某个特定分组丢失或损坏(较少使用)。

      • 优点:快速通知丢失。

      • 缺点:需要额外机制处理NAK丢失。

3. 重传机制 (Retransmission)

  • 作用:在检测到数据丢失或损坏时重新发送数据。

  • 触发条件

    • 超时重传 (Timeout-based)

      • 发送方为每个已发送但未确认的分组启动一个重传定时器 (Retransmission Timer)

      • 如果在超时时间间隔 (Timeout Interval) 内未收到该分组的ACK,则重传该分组。

    • 快速重传 (Fast Retransmit)

      • 发送方收到3个重复ACK (Duplicate ACKs) 时,认为该重复ACK指示的分组已丢失(即使超时未到),立即重传该分组。

      • 显著减少因等待超时而导致的延迟。

  • 超时时间计算

    • 基于对往返时间 (Round-Trip Time - RTT) 的估计。

    • 常用算法:EstimatedRTT = (1-α) * EstimatedRTT + α * SampleRTT (α 常取 0.125)。

    • DevRTT 估计RTT的偏差。

    • TimeoutInterval = EstimatedRTT + 4 * DevRTT (TCP推荐公式)。

    • 关键点:动态适应网络变化,避免过早或过晚重传。

4. 校验和 (Checksum)

  • 作用:检测传输过程中数据(头部+载荷)是否发生比特差错。

  • 原理

    • 发送方:计算待发送数据的校验和,放入分组头部。

    • 接收方:对接收到的数据(包括校验和字段)重新计算校验和。

    • 如果接收方计算的校验和与头部携带的校验和不匹配(通常为0),则认为数据出错

    • 处理:丢弃出错分组(隐式通知丢失),等待重传。校验和本身无法纠正错误

5. 流量控制 (Flow Control)

  • 作用:防止发送方发送速率过快导致接收方缓冲区溢出

  • 原理 (TCP滑动窗口):

    • 接收方在ACK中通告其接收窗口大小 (Receive Window Size - rwnd),表示当前可用缓冲区空间。

    • 发送方维护一个发送窗口 (Send Window),其大小不超过 min(拥塞窗口cwnd, 接收窗口rwnd)

    • 发送方只能发送落在发送窗口内的数据。

    • 接收方处理数据并释放缓冲区后,通过后续ACK更新 rwnd,允许发送方发送更多数据。

  • 关键点:匹配发送速率与接收方的处理能力。

协议实现的核心:滑动窗口协议 (Sliding Window Protocol)

结合了序号、确认、重传和流量控制机制,允许多个分组在信道上“在途飞行”。

  • 发送窗口 (Send Window)

    • 包含已发送但未确认的分组 (Sent but not ACKed) 和可以立即发送的分组 (Can Send Now)。

    • 随着收到ACK向前“滑动”。

  • 接收窗口 (Receive Window)

    • 包含期望接收的下一个序号 (Next Expected Seq#) 及之后可以按序接收的序号范围。

    • 随着按序交付数据向前“滑动”。

两种主要变体

  1. 回退N步 (Go-Back-N - GBN)

    • 接收方只接受按序到达的分组,丢弃所有乱序分组。

    • 发送方收到ACK n 表示 n 及之前所有分组都已被确认。

    • 超时或收到NAK时,重传所有已发送但未确认的分组(从序号 n+1 开始)。

    • 优点:接收方实现简单(只需维护 expectedseqnum)。

    • 缺点:效率低,一个分组丢失可能导致大量正确分组被重传。

  2. 选择重传 (Selective Repeat - SR)

    • 接收方缓存所有正确接收但乱序的分组。

    • 发送方为每个分组维护独立的定时器。

    • 超时或收到NAK/SACK时,只重传特定丢失的分组。

    • 优点:效率高,只重传丢失分组。

    • 缺点:发送方和接收方实现更复杂(需要更大的缓冲区管理乱序分组和独立的定时器管理)。

特性Go-Back-N (GBN)Selective Repeat (SR)
接收处理只收按序,丢弃乱序缓存所有正确接收的分组 (乱序也存)
确认机制累积确认选择确认 (SACK/NAK)
重传触发超时或重复ACK触发重传 所有 未确认分组超时或SACK/NAK触发重传 单个 丢失分组
发送窗口需要管理需要管理 (更复杂)
接收窗口大小为1大于1
效率较低 (一个丢包引发大量重传)较高 (只重传丢失包)
复杂度较低较高

(二)可靠数据传输协议(Rdt)演进详解

核心目标

不可靠信道上实现无差错、无丢失、无重复、按序交付的数据传输。


Rdt 1.0:理想信道模型

假设条件

  • 底层信道完全可靠(无比特差错、无丢包)

工作机制

  1. 发送方
    • 将应用层数据打包成分组(Packet)直接发送。
  2. 接收方
    • 直接解包数据交付给应用层。

缺陷

  • 不切实际:真实网络存在比特差错和丢包。

Rdt 2.0:引入差错检测与确认机制

解决核心问题

  • 比特级差错(如传输中比特翻转)

关键技术

  1. 校验和(Checksum)
    • 检测分组内比特错误。
  2. 确认与重传
    • ACK:接收方显式确认正确接收。
    • NAK:接收方显式报告错误,触发发送方重传。
  3. 停等协议(Stop-and-Wait)
    • 发送方每发送一个分组后等待ACK/NAK。

有限状态机(FSM)

缺陷

  • ACK/NAK受损问题:确认信号本身可能出错,导致发送方无法判断接收方状态。

Rdt 2.1:解决确认信号受损

核心改进

  1. 添加序列号(Sequence Number)

    • 使用 1-bit 序号(0 或 1)标识分组。

  2. 冗余ACK处理

    • 接收方检测到重复分组时,重发上一次的ACK(非NAK)。

关键行为

  • 发送方

    • 收到受损ACK/NAK → 重传当前分组。

    • 收到重复ACK → 忽略(已确认接收方正确接收)。

  • 接收方

    • 收到重复分组 → 丢弃并重发ACK(避免重复交付)。

优势

  • 明确区分新分组 vs 重传分组


Rdt 2.2:无NAK确认协议

核心改进

  • 完全取消NAK,仅使用ACK + 序号确认。

接收方行为

  • 收到正确分组时:

    • 发送 ACK + 期望的下一序号(隐式确认当前分组)。

    • 例:发送 ACK0 表示成功接收 seq=1(期望下一分组 seq=0)。

  • 收到错误/非期望分组时:

    • 发送 ACK + 最后一次正确接收的序号(触发发送方重传)。

优势

  • 简化协议设计,统一反馈机制。


Rdt 3.0:解决丢包与超时重传

解决核心问题

  • 分组丢失(发送方/接收方均可能丢失分组)

  • ACK丢失

关键技术

  1. 倒计时定时器(Countdown Timer)

    • 发送方每发一个分组即启动定时器。

  2. 超时重传(Timeout Retransmission)

    • 定时器到期未收到ACK → 重传分组。

  3. 序号机制扩展

    • 仍使用1-bit序号,但需处理延迟ACK和重复分组。

有限状态机(FSM)关键流程

性能问题

  • 信道利用率低

    • 链路传播延迟(RTT)期间信道空闲(停等机制限制)。

    • 公式:Utilization = (L/R) / (RTT + L/R)
      L=分组大小, R=带宽, RTT=往返时延)


协议演进总结对比

版本解决的核心问题关键技术主要缺陷
1.0无(理想信道)直接发送不适用于真实网络
2.0比特差错校验和、ACK/NAK、停等协议ACK/NAK受损问题
2.1ACK/NAK受损1-bit序号、冗余ACK处理仍依赖NAK
2.2取消NAKACK携带期望序号(隐式确认)未解决丢包问题
3.0分组丢失 & ACK丢失超时重传、定时器机制信道利用率低(停等瓶颈)

后续演进方向

  • 流水线协议(Pipelining):

    • 允许连续发送多个分组(滑动窗口:GBN、SR协议)。

  • 动态调整窗口

    • TCP拥塞控制(AIMD、慢启动、快速重传等)。

  • 选择重传(SR)

    • 仅重传丢失分组,提升效率。

http://www.xdnf.cn/news/10378.html

相关文章:

  • [蓝桥杯]外卖店优先级
  • 【极客日常】分享go开发中wire和interface配合的一些经验
  • C++ 之 多态 【虚函数表、多态的原理、动态绑定与静态绑定】
  • Scratch节日 | 六一儿童节射击游戏
  • ​​技术深度解析:《鸿蒙5.0+:全场景能效的产业革命》​
  • idea中springboot2.7(由于步入另一个线程,已跳过 xxx 处的断点)
  • Azure Devops 系列之三- vscode部署function app
  • 017搜索之深度优先搜索——算法备赛
  • 智语心桥:当AI遇上“星星的孩子”,科技如何点亮沟通之路?
  • 目标检测我来惹1 R-CNN
  • 嵌入式学习笔记 - FreeRTOS v9.0.0 与v10.0.1不同版本占用资源对比
  • 2025——》NumPy中的np.random.randn使用/在什么场景下适合使用np.random.randn?NumPy标准正态分布生成全解析
  • [SAP] 矩阵复制(Matrix Copy)
  • C#里与嵌入式系统W5500网络通讯(4)
  • Python Day39 学习(复习日志Day4)
  • 【HarmonyOS Next之旅】DevEco Studio使用指南(二十九) -> 开发云数据库
  • [ElasticSearch] RestAPI
  • 数据存储与运算
  • 多端学习方案起笔
  • Linux基础 文件描述符,重定向及缓冲区理解
  • MCU如何从向量表到中断服务
  • Goreplay最新版本的安装和简单使用
  • asyncpg - Python异步PostgreSQL客户端库
  • 4、获取树莓派温度
  • Jenkins:自动化流水线的基石,开启 DevOps 新时代
  • 【Linux网络编程】数据链路层
  • 6个月Python学习计划 Day 11 - 列表推导式、内置函数进阶、模块封装实战
  • 让编程更智能高效:探索Claude Code工具的强大功能
  • Qt源码分析:QDataStream
  • 多模态大语言模型arxiv论文略读(103)