欢迎来到 跌倒的小黄瓜 的博客

♪(^∇^*)我要当大佬,(#^.^#)哈哈哈哈,(。-ω-)zzz我要成为优秀的人,(*^▽^*)٩(๑>◡<๑)۶O(∩_∩)O哈哈~~~~~~~~欢迎━(*`∀´*)ノ亻!

计算机网络--传输层

传输层服务和协议

传输层协议为运行在不同Host上的进程提供了一种逻辑通信机制

  • 端系统运行传输层协议
    • 发送方:将应用递交的消息分成一个或多
  • 个的Segment,并向下传给网络层。
    • 接收方:将接收到的segment组装成消息,并向上交给应用层。
  • 传输层可以为应用提供多种协议
    • Internet上的TCP
    • Internet上的UDP

网络层:提供 主机之间的逻辑通信机制
传输层:提供 应用进程之间的逻辑通信机制,位于网络层之上,依赖于网络层服务,对网络层服务进行(可能的)增强

Internet传输层协议

  • 可靠、按序的交付服务(TCP)
    • 拥塞控制
    • 流量控制
    • 连接建立
  • 不可靠的交付服务(UDP)
    • 基于“尽力而为(Best-effort)”的网络层,没有做(可靠性方面的)扩展
  • 两种服务均不保证
    • 延迟
    • 带宽

多路复用/分用

如果某层的一个协议对应直接上层的多个协议/ 实体 , 则需要复用/分用

主机接收到IP数据报(datagram), 每个数据报携带源IP地址、目的IP地址。,每个数据报携带一个传输层的段(Segment)。每个段携带源端口号和目的端口号

主机收到Segment之后,传输层协议提取IP地址和端口号信息,将Segment导向相应的Socket,TCP做更多处理

无连接分用

利用端口号创建Socket
···
DatagramSocket mySocket1 = new DatagramSocket(99111);
DatagramSocket mySocket2 = new DatagramSocket(99222);
···

UDP的Socket用二元组标识( 目的IP 地址 , 目的端口号),主机收到UDP段后检查段中的目的端口号,将UDP段导向绑定在该端口号的Socket,来自不同源IP地址和/或源端口号的IP数据包被导向同一个Socket

面向连接的分用

TCP的Socket用四元组标识:源IP 地址,源端口号,目的IP 地址,目的端口号,接收端利用所有的四个值将Segment导向合适的Socket,服务器可能同时支持多个TCPSocket,每个Socket用自己的四元组标识,Web服务器为每个客户端开不同的Socket

面向连接的分用 : 多线程Web 服务器

UDP

  • 基于Internet IP协议
    • 复用/分用
    • 简单的错误校验
  • “Best effort”服务,UDP段可能
    • 丢失
    • 非按序到达
  • 无连接
    • UDP发送方和接收方之间不需要握手
    • 每个UDP段的处理独立于其他段

UDP 为什么存在?

  • 无需建立连接 ( 减少延迟)
  • 实现简单 : 无需维护连接状态
  • 头部开销少
  • 没有拥塞控制: 应用可更好地控制发送时间和速率

常用于流媒体应用:容忍丢失, 速率敏感

UDP还用于:DNS, SNMP

在UDP上实现可靠数据传输?

  • 在应用层增加可靠性机制
  • 应用特定的错误恢复机制

UDP 校验和(checksum)

目的 : 检测UDP 段在传输中是否发生错误 ( 如位翻转)

发送方: 将段的内容视为16-bit 整数,校验和计算 : 计算所有整数的和, 进位加在和的后面 , 将得到的值按位求反 , 得到校验和, 发送方将校验和放入校验和字段

接收方:计算所收到段的校验和, 将其与校验和字段进行对比
• 不相等 : 检测出错误
• 相等 : 没有检测出错误 ( 但可能有错误 )

可靠数据传输原理

  • 什么是可靠 ?
    • 不错、不丢、不乱
  • 可靠数据传输协议
    • 可靠数据传输对应用层、传输层、链路层都很重要
    • 网络Top-10问题
    • 信道的不可靠特性决定了可靠数据传输协议(rdt)的复杂性

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


渐进地设计可靠数据传输协议的发送方和接收方,只考虑单向数据传输,但控制信息双向流动,利用状态机(Finite State Machine, FSM)刻画传输协议

Rdt 1.0: 可靠信道上的可靠数据传输

底层信道完全可靠:不会发生错误(bit error),不会丢弃分组,发送方和接收方的FSM独立

Rdt 2.0: 产生位错误的信道

  • 底层信道可能翻转分组中的位(bit)
    • 利用 校验和 检测位错误
  • 如何从错误中恢复 ?
    • 确认机制(Acknowledgements, ACK): 接收方显式地告知发送方分组已正确接收
    • NAK: 接收方显式地告知发送方分组有错误
    • 发送方收到NAK 后 , 重传 分组
  • 基于这种重传机制的rdt 协议称为ARQ(Automatic Repeat reQuest) 协议
  • Rdt 2.0 中引入的新机制
    • 差错检测
    • 接收方反馈控制消息: ACK/NAK
    • 重传

Rdt 2.0: FSM

Rdt 2.0: 无错误场景

Rdt 2.0: 有错误场景

Rdt 2.1 和2.2

Rdt 2.0 有什么缺陷 ?

如果ACK/NAK 消息发生错误/ 被破坏(corrupted) 会怎么样 ?

  • 为ACK/NAK 增加校验和 , 检错并纠错
  • 发送方收到被破坏ACK/NAK 时不知道接收方发生了什么 , 添加额外的控制消息
  • 如果ACK/NAK 坏掉 , 发送方重传
  • 不能简单的重传 : 产生
    如何解决重复分组问题 ?
  • 序列号(Sequence number): 发送方给每个分组增加序列号
  • 接收方丢弃重复分组

Rdt 2.1: 发送方, 应对ACK/NAK 破坏

Rdt 2.1: 接收方, 应对ACK/NAK 破坏

发送方:

  • 为每个分组增加了序列号
  • 两个序列号(0, 1)就够用
  • 需校验ACK/NAK消息是否发生错误
  • 状态数量翻倍
    • 状态必须“记住”“当前”的分组序列号

接收方

  • 需判断分组是否是重复
    • 当前所处状态提供了期望收到分组的序列号
  • 注意:接收方无法知道ACK/NAK是否被发送方正确收到

Rdt 2.2: 无NAK 消息协议

我们真的需要两种确认消息(ACK + NAK) 吗 ?与rdt 2.1 功能相同 , 但是只使用ACK, 接收方通过ACK, 在ACK 消息中显式地加入被确认分组的序列号,发送方收到重复ACK 之后 , 采取与收到NAK 消息相同的动作, 重传当前分组

Rdt 3.0

如果信道既可能发生错误 , 也可能丢失分组 , 怎么办?“校验和 + 序列号 + ACK + 重传”够用吗?

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

  • 如果没收到ACK,重传
  • 如果分组或ACK只是延迟而不是丢了
    • 重传会产生重复,序列号机制能够处理
    • 接收方需在ACK中显式告知所确认的分组
  • 需要定时器

Rdt 3.0 发送方FSM





Rdt 3.0: 停等操作

流水线机制 : 提高资源利用率

流水线协议

允许发送方在收到ACK之前连续发送多个分组

  • 更大的 序列号范围
  • 发送方和/或接收方需要更大的存储空间以 缓存分组

滑动窗口协议

滑动窗口协议: Sliding-window protocol
窗口

  • 允许使用的序列号范围
  • 窗口尺寸为N:最多有N个等待确认的消息
    滑动窗口: 随着协议的运行,窗口在序列号空间内向前滑动
    滑动窗口协议:GBN, SR

Go-Back-N 协议

Go-Back-N(GBN) 协议: 发送方

  • 分组头部包含k-bit序列号
  • 窗口尺寸为N,最多允许N个分组未确认
  • ACK(n): 确认到序列号n(包含n)的分组均已被正确接收
  • 可能收到重复ACK
  • 为空中的分组设置计时器(timer)
  • 超时Timeout(n)事件: 重传序列号大于等于n,还未收到ACK的所有分组

GBN: 发送方扩展FSM

GBN: 接收方扩展FSM

ACK机制: 发送拥有最高序列号的、已被正确接收的分组的ACK,可能产生重复ACK只需要记住唯一的expectedseqnum

乱序到达的分组:

  • 直接丢弃接收方没有缓存
  • 重新确认序列号最大的、按序到达的分组


Selective Repeat 协议

GBN 有什么缺陷 ?

  • 接收方对每个分组单独进行确认
    • 设置缓存机制,缓存乱序到达的分组
  • 发送方只重传那些没收到ACK的分组
    • 为每个分组设置定时器
  • 发送方窗口
    • N个连续的序列号
    • 限制已发送且未确认的分组




小节

posted @ 2020-03-16 22:08  跌倒的小黄瓜  阅读(...)  评论(...编辑  收藏