计算机网络学习笔记12--UDP&可靠数据传输协议

https://www.bilibili.com/video/BV1Up411Z7hC?p=41

如有错误之处请指出，谢谢！

目录

UDP

基于Internet IP协议

“Best effort”服务，UDP段可能

无连接

为什么需要UDP

常用于流媒体应用

UDP还用于

在UDP上实现可靠数据传输

UDP的报文段格式

 checksum UDP校验盒：

发送方：

接收方

校验和例子

 可靠数据传输原理

什么是可靠？

可靠数据传输协议

可靠数据传输协议基本结构：接口

双向控制消息流动实现可靠数据传输

Rdt1.0

底层信道完全可靠

发送方和接收方的FSM独立

 Rdt2.0

底层信道可能翻转分组中的位（bit）

如何从错误中恢复？

基于这种重传机制地rdt协议称为

Rdt2.0中引入的新机制

FSM规约

 无错误场景

 有错误地场景

 Rdt2.0有什么缺陷

如果ACK/NAK消息发生错误/被破坏（corrupted）会怎么样？

如何解决重复分组问题？

Rdt 2.1

发送方FSM

 接收方FSM

Rdt2.1与Rdt2.0的区别

发送方：

接收方

需判断分组是否是重复

Rdt2.2

Q我们真的需要两种确认消息（ACK+NAK）吗

实现：

FSM

 Rdt3.0

Q弱国信道既可能发生错误，又可能丢失分组，怎么办？

方法：发送方等待”合理“时间

需要定时器

Rdt3.0FSM

例子

Rdt3.0性能分析

 Rdt3.0 停等操作

---

p41-45

UDP

User Datagram Protocol【RFC 768】

把端到端的服务暴露给应用层

基于Internet IP协议

复用/分用

简单的错误校验

Q为什么错误检测

A端到端的原则，不能确保中间链路层与路由器存储转发过程中没有错误，所以要在距离应用层最近的传输层进行错误检测

“Best effort”服务，UDP段可能

丢失

非按序到达

无连接

UDP发送方和接收方之间不需要握手

每个UDP段的处理独立于其他段

为什么需要UDP

不需要建立连接（减少延迟）

实现简单（不需要维护连接状态）

头部开销少

没有拥塞控制（应用可更好地控制发送时间和速率，完全由应用掌控速率）

常用于流媒体应用

容忍丢失

速率敏感

UDP还用于

DNS

SNMP

在UDP上实现可靠数据传输

在应用层增加可靠性机制

应用特定的错误恢复机制

UDP的报文段格式

 checksum UDP校验盒：

目的：检测UDP段在传输中是否发生错误（如位翻转）

发送方：

将段的内容视为16-bit整数

校验和计算：计算所有整数的和，进位加在和的后面，将得到的值按位求反，得到校验和

发送方将校验和放入校验和字段

接收方

计算所收到段的校验和

将其与校验和字段进行对比

   不相等：检验出错误

   相等：没有检测出错误（但可能有错误）

校验和例子

 可靠数据传输原理

什么是可靠？

不错、不丢、不乱

可靠数据传输协议

可靠数据传输对应用层、传输层、链路层都很重要

网络Top-10问题

信道的不可靠特性决定了可靠数据传输协议（rdt）的复杂性

可靠数据传输协议基本结构：接口

 不可靠的信道：IP协议 unreliable channel

发送：上层应用单向调用接口

接受：底层做好所有事情才把数据交给应用层

双向控制消息流动实现可靠数据传输

渐进地设计可靠数据传输协议的发送方和接收方

只考虑单向数据传输：但控制信息双向流动

利用有限状态自动状态机（Finite State Machine，FSM）刻画传输协议

Rdt1.0

可靠信道上的可靠传输协议

底层信道完全可靠

不会发生错误（bit error）

不会丢弃分组

发送方和接收方的FSM独立

 

 Rdt2.0

产生位错误的信道

底层信道可能翻转分组中的位（bit）

利用校验和检测位错误

如何从错误中恢复？

引入了ACK、NAK、重传机制

确认机制（Acknowledgement。ACK）：接收方显式地告知发送方分组已正确接收

NAK：接收方显示地告知发送方分组有错误

发送方收到NAK后，重传分组

基于这种重传机制地rdt协议称为

ARQ（Automatic Repeat Request）协议

Rdt2.0中引入的新机制

差错检测

接收方反馈控制消息：ACK/NAK

重传

FSM规约

stop and wait停-等协议

^ 表空

 无错误场景

 有错误地场景

 Rdt2.0有什么缺陷

如果ACK/NAK消息发生错误/被破坏（corrupted）会怎么样？

为ACK/NAK增加校验和，检错并纠错

 发送方收到被破坏ACK/NAK时不知道接收方发生了什么。添加额外的控制消息

如果ACK/NAK坏掉，发送方重传

不能简单地重传，否则产生重复分组

如何解决重复分组问题？

序列号（Sequence number）：发送方给每个分组增加序列号

接收方丢弃重复分组

使用停等协议

Rdt 2.1

发送方，应对ACK/NAK破坏

发送方FSM

 接收方FSM

 错误发送ACK：当前需要0,结果发来1，那么为了得到1，只能告诉这次ack了，让发送方下次发送0，而接收方继续保持接收0的状态即可

Rdt2.1与Rdt2.0的区别

发送方：

   为每个分组增加了序列号

   Q两个序列号（0，1）就够用，为什么

   A使用停等协议

   需校验ACK/NAK消息是否发生错误

   状态数量翻倍

   状态必须”记住“”当前“的分组序列号

接收方

需判断分组是否是重复

当前所处状态提供了期望收到分组的序列号

注意：接收方无法知道ACK/NAK是否被发送方正确收到

Rdt2.2

无NAK消息协议

Q我们真的需要两种确认消息（ACK+NAK）吗

与rdt2.1功能相同，但是只使用ACK

实现：

接受方通过ACK告知最后一个被正确接受的分组

在ACK消息中显式地加入被确认分组的序列号

发送方收到重复ACK之后，采取与收到NAK消息相同的动作

重传当前分组

FSM

 Rdt3.0

Q弱国信道既可能发生错误，又可能丢失分组，怎么办？

“校验和+序列号+ACK+重传”够用吗？

方法：发送方等待”合理“时间

如果没有收到ACK。重传

如果分组或ACK知识延迟而不是丢了

   重传会产生重复，序列号机制能够处理

   接收方需在ACK中显式告知所确认的分组

需要定时器

Rdt3.0FSM

例子

 D：计时器设置过短：之后每个包都会发两次

Rdt3.0性能分析

Rdt3.0能够正确工作，但性能很差

示例：1Gbps链路，15ms端到端传播延迟，1KB分组

等待·15ms等待延迟

发送方李永利：发送方发送时间百分比

在1Gbps链路上每30ms才发送一个分组->33KB/sec

Rdt3.0效率很低

网络协议限制了物理资源的利用 

 Rdt3.0 停等操作