CN-计算机网络传输层

Molaters Lv5
  2023-11-24 10:14:50 2023-11-24 10:14:50 创建   2023-10-12 17:05:47 2023-10-12 17:05:47 更新      
# 计算机网络传输层

传输层服务概述

传输层服务和协议

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

端系统运行传输层协议

  • 发送方：将应用递交的消息分成一个或者多个的Segment,并向下传递给网络层

  • 接收方：将接收到的Segment组装成消息，并上交给应用层

传输层可以为应用提供多种协议

  • Internet上的TCP

  • Internet上的UDP

传输层 vs 网络层

网络层： 提供主机之间的逻辑通信机制

传输层：提供应用进程之间的逻辑通信机制

  • 位于网络层之上

  • 依赖于网络服务

  • 对网络层服务进行（可能的）增强

家庭类比

  • 12个孩子给12个孩子写信
  • 应用进程 = 孩子
  • 应用消息 = 信封里面的信
  • 主机 = 房子
  • 传输层协议 = 李雷和韩梅梅
  • 网络层协议 = 邮政服务

Internet传输层协议

  • 可靠、按序的交付服务(TCP)

    • 拥塞控制
    • 流量控制
    • 连接建立

  • 不可靠的交付服务(UDP)

    • 基于 “尽力而为(Best-effort)” 的网路，没有做可靠性方面的拓展

  • 两种服务均不保证

    • 延迟
    • 带宽

多路复用和多路分用

Why? $\rightarrow$ 如果某层的一个协议对应直接上层的多个协议/实体，那么就需要复用/分用

1694605856597

接收端进行多路分用

传输层依据头部信息将收到的Segment交给正确的Socket，即不同的进程

发送端进行多路复用

从多个Socket接受数据，为每块数据封装上头部信息，交给网络层

分用如何工作

  • 主机接收到IP数据报（datagram）

    • 每个数据报携带源IP地址、目的IP地址

    • 每个数据报携带一个传输层的端（Segment）

    • 每个段携带源端口号和目的端口号

1694607845406

  • 主机收到Segment之后，传输层协议提取IP地址和端口号信息，将Segment导向相应的Socket
1694606950930

无连接分用

  • 利用端口号创建Socket [completion:: 2023-09-26]
1
2
DatagramSocket mySocket1 = new DatagramSocket(99111);
DatagramSocket mySocket2 = new DatagramSocket(99222);
  • UDP的Socket用二元组标识
    • UDP的Socket用二元组标识

主机收到UDP段之后

  • 检查段中的目的端口号

  • 将UDP段导向绑定在该端口号的Socket

来自不同源IP地址和/或源端口号的IP数据包被导向同一个Socket

1
DatagramSocket serverSocket = new DatagramSocket(6428);
1694607649470

SP提供返回地址

面向连接的分用

TCP的Socket用四元组标识
- 源IP地址
- 源端口号
- 目的IP地址
- 目的端口号

接收端利用所有的四个值将Segment导向合适的Socket

服务器可能同时支持多个TCPSocket
- 每个人Socket用自己的四元组标识

Web服务器为每个客户端开不同的Socket

1694609096055 1694609108885

UDP

UDP :User Datagram Protocol [RFC 768]

  • 基于Internet IP协议

    • 复用/分用

    • 简单的错误校验

  • “Best effort”服务，UDP段可能

    • 丢失

    • 非按序到达

  • 无连接

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

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

  • 常用于流媒体应用

    • 容忍丢失

    • 速率敏感

  • UDP还用于

    • DNS

    • SNMP

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

    • 在应用层增加可靠性机制

    • 应用特定的错误恢复机制

UDP检验和(Checksum)

目的:检测UDP段是否发生错误,比如位翻转

  • 发送方

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

    • 检验和计算:计算所有整数的和,进位加在和的后面,将得到得知安慰囚犯,得到校验和

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

  • 接收方

    • 计算所受到段的校验和
    • 将其与校验和字段进行对比
      • 不相等:检测出错误
      • 相等:没有检测出错误

校验和计算实例

注意: 最高位必须被加进去

示例:

1694611617018

可靠数据传输原理

❓什么是可靠
- 不错,不乱,不丢

可靠数据传输协议

  • 可靠数据传输对应用层/传输层/链路层都很重要
  • 网络的Top10问题
  • 信道的不可靠特性决定了可靠数据传输协议(rdt)的复杂性
1694612237418 1694612260649 1694612273475

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

1694612283387

可靠数据传输协议

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

1694612449445

Rdt1.0:可靠信道上的可靠数据传输

底层信道完全可靠

  • 不会发生错误(bit error)
  • 不会丢弃分组
    发送方和接收方的FSM独立

1694612519572

Rdt 2.0

Rdt 2.0: 产生位错误的信道

底层信道可能反转分组中的位

  • 利用校验和检测为错误

如何从错误中回复？

  • **确认机制(Acknowledgements,ACK):**接收方显式的告知发送方分组已经正确接收

  • NAK：接收方显式的告知发送方的分组有错误

  • 发送方收到NAK之后，重发分组

基于这种重传机制的rdt协议称为ARQ(Automatic Repeat reQuest) 协议

Rdt 2.0中引入的新机制

  • 差错检测(校验和的方式)

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

  • 重传

Rdt 2.0:FSM规约

1694736520687

1694736529915

Rdt 2.1 和 2.2

对Rst 2.0的改进，先要知道Rdt 2.0有什么缺陷？

如果ACK和NAK消息发生错误了怎么办？

Solution 1:为NAK和NCK增加校验和，检错并纠错

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

Solution 3:如果ACK/NAK坏掉，就重传。但是不能简单的重传，因为会产生重复分组。

怎么解决重复分组问题？

序列号(Sequance number):发送方给每个分组增加序列号

接收方丢弃重复分组

stop and wait:
Sender sends one packet, then waits for reciever response.

1694764764860

1694764776396

Rdt 2.1 vs Rdt 2.0

发送方

为每个分组增加了序列号

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

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

状态数量翻倍
状态必须记住当前的分组序列号

接收方

需要判断分组是不是重复
当前所处的状态提供了期望收到分组的序列号

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

Rdt 2.2: 无NAK消息协议

我们真的需要两种确认消息(ACK+NAK)?

和rdt2.1 的功能相同，但是只使用NAK

🧐怎么实现？

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

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

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

  • 重传当前的分组

Rdt 2.2 FSM片段

1694765185191

Rdt 3.0

如果信道极可能发生错误，也可能丢失分组，怎么办

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

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

如果timeout，有没有收到ACK就可以采取动作了 $\rightarrow$ 重传

☹但是时间是很难设定的，如果只是延迟了，就会引起重复的问题

  • 但是序列号能够处理
  • 接收方需要在ACK中显式的告知所确认的分组
  • 需要定时器

Rdt 3.0 发送方FSM

1694766165886

Rdt 3.0 运行实例

1694766219749

⬆ 发送方和接收方在传输过程中没有丢包的存在

1694766226555

⬆ 在发送过程当中发生丢失的情况，执行停-等协议，造成超时，所以重新传输分组

1694766471113

⬆ 标识收到了两个分组（相同序列号），那就丢掉一个然后进行传输ACK

1694766548272

⬆ 标识两次都发送了，表明第一次正确接收了，但是返回ACK的过程当中触发执行停等协议然后重新发送了一次。收到了ACK1之后会传换成发送pkt0，第二次发的ACK1到达的时候正好有了ACK0。
称之为计时器时间过短、timeout早熟

Rdt 3.0 性能分析

Rdt 3.0能够正常工作，但是性能很差

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

$T_{transmit}=\frac{L(packet \ length \ in \ bits)}{R(transmission \ rate, \ bps)}=\frac{8kb/pkt}{10^9b/sec}=8 ms$

发送方的利用率：发送方发送时间百分比

$U_{sender}=\frac{L/R}{RTT+L/R}=0.008/30.008=0.00027$

在1Gbps链路上每30毫秒才能发送一个分组 $\Rightarrow$ 33KB/s

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

1694767041067

$U_{sender}=\frac{L/R}{RTT+L/R}=0.008/30.008=0.00027$

流水线的机制和滑动窗口协议

1694768215316

回顾最初的Rdt 3.0操作

可以更改为同时发多个分组，这样就能有更好的性能

1694768312234

$U_{sender}=\frac{3*L/R}{RTT+L/R}=\frac{0.024}{30.008}= 0.0008$

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

  • 更大的序列号范围

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

1694768451060

很明显可以看出效率有明显提高

滑动窗口协议

滑动窗口协议：Sliding-window protocol

  • 窗口

    • 允许使用的序列号范围
    • 窗口尺寸为N：最多有N个等待确认的消息

  • 滑动窗口

    • 随着协议的运行，窗口在序列号空间内向前滑动

滑动窗口协议：GBN，SR

1694768609208

GBN(Go-Back-N)

发送方

  • 分组头部包含k-bit序列号
  • 窗口尺寸为N，最多允许N个分组未确认

1694768789786

  • ACK(n):确认到序列号n(包含n)的分组均已经被正确接收

    • 可能收到重复的ACK

  • 为空中的分组设置计时器

  • 超时Timeout事件：重传序列号大于等于n，还没有收到ACK的所有分组

GBN：发送方扩展FSM

1694769021950

1
2
3
4
5
6
7
8
9
10
if(nextseqnum < base + N){ //意味着还有可用的seqnum意味着还可以接着发送分组
  sndpkt[nextseqnum]=make_pkt(nextseqnum.data.chksum);
  udt_send(sndpkt[nextseqnum]);
  if (base == nextseqnum){//如果base和nextseqnum相等的话，就启动定时器
    start_timer();
    nextseqnum++;
  }
  else 
    refuse_data(data);//如果窗口里面的序列号已经用光了，就可以refuse掉当前的数据
}

Timeout事件出现的操作

Timeout $\rightarrow$ start_timer()
udt_send(sndpkt[base])
……
udt_send(sndpkt[nextseqsum-1])

GBN：接收方扩展FSM

1694769484914

  • ACK机制：发送拥有最高序列号的、已经被正确的接收的分组的ACK
    • 可能产生重复的ACK
    • 只需要记住唯一的expectedseqnum
  • 乱序到达的分组：
    • 直接丢弃 $\rightarrow$ 接收方没有缓存
    • 重新确认序列号最大的按照序列到达的分组

GBN的实例

1694769749622

练习题

数据量链路层采用后退N帧的协议，发送方已经发送了编号为0~7的帧，当计时器超市的时候，如果发送方只收到了0，2，3号帧的确认，那么发送方需要重发的帧数是多少，分别是哪几个帧？

根据GBN的工作原理，GBN协议的确认是累计确认，所以此时发送端需要重发的帧数是4个，依次次分别是4、5、6、7

SR协议

Select Repeat协议

GBN有什么缺陷？

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

1694770256143

分布式系统的网络

Sender

  • data from above:
    • if next available seq # in window, send pkt
  • timeout (n):
    • resend pkt n, restart timer
  • ACK(n) in [sendbase,sendBase+N]:
    • mark pkt n as recieved
    • if n smallest unACKed pkt, advanced window base to next unACKed seq #

recevier

  • pkt n in [revbase, revbase+N-1]
    • send ACK(n)
    • out-of-order:buffer
    • in-order:deliver(also deliver buffered, in-order pkts), advance window to next not-yet-recieved pkt
  • pkt n in [rcvbase-N,rcvbase-1]
    • ACK(n)
  • otherwise:
    • ignore

1694770984071

SR协议：困境

  • 序列号：0，1，2，3
  • 窗口尺寸：3
  • 接收方能够区分开两种不同的场景吗？
    • (a)中发送方重发
      1694771172608
    • (b)中发送了第五个分组
      1694771259880

问题：序列号空间大小和窗口尺寸需要满足什么关系？

$N_S+N_R \leq 2^k$

  • 标题: CN-计算机网络传输层
  • 作者: Molaters
  • 创建于 : 2023-11-24 10:14:50
  • 更新于 : 2023-10-12 17:05:47
  • 链接: https://molaters.github.io/2023/11/24/计算机网络/CN-计算机网络传输层/
  • 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。
 评论
此页目录
CN-计算机网络传输层
  1. 传输层服务概述
    1. 传输层服务和协议
    2. 传输层 vs 网络层
    3. Internet传输层协议
  2. 多路复用和多路分用
    1. 分用如何工作
    2. 无连接分用
    3. 面向连接的分用
  3. UDP
    1. UDP :User Datagram Protocol [RFC 768]
    2. UDP检验和(Checksum)
    3. 校验和计算实例
  4. 可靠数据传输原理
    1. 可靠数据传输协议基本结构:接口
    2. 可靠数据传输协议
  5. Rdt 2.0
  6. Rdt 2.1 和 2.2
    1. Rdt 2.1 vs Rdt 2.0
    2. Rdt 2.2 FSM片段
  7. Rdt 3.0
    1. Rdt 3.0 发送方FSM
    2. Rdt 3.0 运行实例
    3. Rdt 3.0 性能分析
  8. 流水线的机制和滑动窗口协议
    1. 滑动窗口协议
  9. GBN(Go-Back-N)
    1. 发送方
    2. GBN：发送方扩展FSM
    3. GBN：接收方扩展FSM
    4. GBN的实例
    5. 练习题
  10. SR协议
    1. Select Repeat协议
    2. SR协议：困境