计算机网络3.1、传输层

龙妞

已于 2023-09-12 11:49:26 修改

阅读量58

点赞数

分类专栏：计算机网络文章标签：计算机网络网络

于 2023-08-03 16:38:53 首次发布

本文链接：https://blog.csdn.net/qq_43573570/article/details/132086774

版权

计算机网络专栏收录该内容

7 篇文章 0 订阅

订阅专栏

可靠数据传输（RDT，ralid datagram transport）的原理********

rdt3.0：带有计时器的具有比特差错和分组丢失的信道

概述和传输层服务
- 传输服务和协议
  - 为运行在不同主机上的应用进程提供逻辑通信
  - 传输协议运行在端系统
    - 发送方
      - 传输层将应用层的报文分成报文段，然后传给网络层
    - 接收方
      - 传输层将网络层传过来的报文段重新组成报文，然后传递给应用层
  - 有多个传输层协议可供应用选择
    - TCP/UDP
- 传输层 vs 网络层
  - 网络层服务
    - 主机之间的逻辑通信
  - 传输层服务
    - 进程间的逻辑通信
    - 依赖于网络层的服务
      - 延时、带宽
    - 对网络层的服务进行加强
      - 数据丢失、顺序混乱、加密
- Internet传输层协议
  - 可靠的、保序的传输：TCP
    - 多路复用、解复用
    - 拥塞控制
    - 流量控制
    - 建立连接
  - 不可靠的、不保序的传输：UDP
    - 多路复用、解复用
    - 没有为IP服务添加更多的其他额外服务
  - 都不提供的服务
    - 延时保证
    - 带宽保证
多路复用/解复用
- 大致流程
  - 发送方主机
    - 从多个socket接收来自多个进程的报文，根据socket对应的ip地址和端口号等信息对报文段用头部加以封装（该头部信息用于以后的解复用）
  - 接收方主机
    - 根据报文段的头部信息中的IP地址和端口号将接收到的报文段发给正确的socket和对应的应用进程
- 多路复用在发送端，多路解复用在接收端
- 多路复用
  - 面向TCP的多路复用
    - 服务器能够在一个TCP端口上同时支持多个TCP套接字，因为tcp socket是由四元组定义的，不仅受源主机的影响，还受目标主机的影响，socket是进程间会话的唯一标识
    - Web服务器对每个连接客户端有不同的socket
- 多路解复用
  - 多路解复用工作原理
    - 解复用作用
      - TCP或UDP实体采用哪些信息，将报文段的数据部分交给正确的Socket，从而交给正确的进程
    - 主机收到IP数据报
      - 每个数据报有源IP和目标IP
      - 每个数据报承载一个传输层报文段
      - 每个报文段有一个源端口号和目标端口号
    - 主机联合IP地址和端口号将报文段发送给合适的socket，进而发送给合适的进程
    - TCP/UDP报文段格式
  - UDP多路解复用
    - 在接收端，UDP套接字用二元组标识 (目标IP地址、目标端口号)
    - 当主机收到UDP报文段：
      - 检查报文段的目标端口号
      - 用该端口号将报文段定位给对应的socket
    - 如果有两个不同源IP和源端口号的数据报，但是有相同的目标ip和目标端口号，则被定位到相同socket
  - TCP多路解复用
    - 发送端根据TCP socket的四元组定位接收主机ip并发送TCP报文段（包含目标端口号）
    - 接收主机用这TCP socket四元组来定位目标端口号
    - 用该端口号将报文段定位到合适的目标socket
无连接传输：UDP
- UDP报文段格式
- UDP
  - 发送端和服务器没有握手
  - 每个udp报文段都被独立的处理
- UDP校验和
  - 检测在传输报文段中的差错
  - 发送端
    - 将报文段的内容视为16比特的整数
    - 校验和：报文段的加法和（1的补运算）
    - 发送方将校验和放在UDP的校验和字段
  - 接收端
    - 计算接收到的报文段的校验和
    - 检查计算出的校验和与校验和字段的内容是否相等：
      - 不相等–--检测到差错
      - 相等–--没有检测到差错，但也许还是有差错，比如残存错误
- 好处
  - 不建立连接（会增加延时）
  - 简单，在发送端和接收端没有连接
  - 报文段的头部很小，开销就小
  - 无拥塞控制和流量控制，UDP尽可能快的发送报文段
    - 应用传输的速率=主机到网络的速率
- 坏处
  - 报文段可能会丢失
  - 送到进程的报文段乱序
可靠数据传输（RDT，ralid datagram transport）的原理********
- 流程示意图
  - 上层接口
    - rdt_send()
      - 发送，被上层（比如应用层）调用，将数据交付给下方的发送实体
    - deliver_data()
      - 接收，被rdt调用，将数据发送给上层
  - 下层接口
    - udt_send()
      - 发送，被rdt调用，将packet放到不可靠的信道上传输到接收方
    - rdt_rev()
      - 接收，当packet通过信道到达接收方时被调用
- 信道
  - FSM
    - 有限状态机
  - 在可靠信道上的可靠数据传输
    - 下层的信道是完全可靠的
      - 没有比特出错
      - 没有分组丢失
    - 发送端和接收端的FSM
      - 发送方将数据发送到下层信道
      - 接收方从下层信道接收数据
  - rdt2.0：具有比特差错的信道
    - 下层信道可能发生出错，将分组中的比特翻转
    - 怎样从差错中恢复
      - 确认（ACK）
        接收方显式地告诉发送方分组已被正确接收
      - 未确认（NAK）
        接收方显式地告诉发送方分组发生了差错
        发送方收到NAK后，发送方重传分组
    - rdt2.0中的新机制：采用差错控制编码进行差错检测
      - 发送方差错控制编码、缓存
      - 接收方使用编码检错
      - 接收方的反馈：控制报文（ACK，NAK）：接收方->发送方
      - 发送方收到反馈相应的动作
  - rdt2.1：没有NAK的协议
    - 功能同rdt2.0，但只使用ACK(ack 要编号）
    - 接收方对最后正确接收的分组发ACK，以替代NAK
      - 接收方必须显式地包含被正确接收分组的序号
    - 当收到重复的ACK（如：再次收到ack0）时，发送方与收到NAK采取相同的动作：重传当前分组
    - 为后面的一次发送多个数据单位做一个准备
      - 一次能够发送多个
      - 每一个的应答都有：ACK，NACK；麻烦
      - 使用对前一个数据单位的ACK，代替本数据单位的nak
      - 确认信息减少一半，协议处理简单
  - rdt3.0：带有计时器的具有比特差错和分组丢失的信道
    - rdt3.0可以工作，但链路容量比较大的情况下，性能很差
      - 链路容量比较大，一次发一个PDU 的不能够充分利用链路的传输能力
      - 瓶颈在于：网络协议限制了物理资源的利用！
  - 流水线协议
    - 提高链路利用率
      - 增加n,能提高链路利用率
      - 但当达到某个n,其u=100%时,无法再通过增加n，提高利用率
      - 瓶颈转移了->链路带宽
    - 流水线
      - 允许发送方在未得到对方确认的情况下一次发送多个分组
      - 必须增加序号的范围:用多个bit表示分组的序号
      - 在发送方/接收方要有缓冲区
        发送方缓冲：未得到确认，可能需要重传
        接收方缓存：上层用户取用数据的速率≠接收到的数据速率；接收到的数据可能乱序，排序交付（可靠）
    - 滑动窗口(slide window)协议
      - 发送缓冲区≠发送窗口
        
        发送窗口<=发送缓冲区
        发送缓冲区
        形式：内存中的一个区域，落入缓冲区的分组可以发送
        功能：用于存放待发送或已发送但是没有得到确认的分组
        必要性：需要重发时可用
        发送缓冲区的大小：一次最多可以发送多少个未经确认的分组
        停止等待协议=1
        流水线协议>1，合理的值，不能很大，链路利用率不能够超100%
        发送缓冲区中的分组
        未发送的：落入发送缓冲区的分组，可以连续发送出去；
        已经发送出去的、等待对方确认的分组：发送缓冲区的分组只有得到确认才能删除
        发送窗口：发送缓冲区内容的一个范围
        那些已发送但是未经确认分组的序号构成的空间
        前沿移动
        一开始没有发送任何一个分组
        后沿=前沿
        之间为发送窗口的尺寸=0
        每发送一个分组，前沿前移一个单位
        发送窗口前沿移动的极限：不能够超过发送缓冲区
        后沿移动
        条件：收到老分组的确认
        结果：发送缓冲区罩住新的分组，来了分组可以发送
        移动的极限：不能够超过前沿
      - 接受窗口
        
        接收窗口 (receiving window)=接收缓冲区
        接收窗口用于控制哪些分组可以接收
        只有收到的分组序号落入接收窗口内才允许接收
        若序号在接收窗口之外，则丢弃；
        接收窗口尺寸Wr=1，则只能顺序接收
        接收窗口尺寸Wr>1 ，则可以乱序接收
        但提交给上层的分组，要按序
        接收窗口的滑动和发送确认
        滑动
        低序号的分组到来，接收窗口移动；
        高序号分组乱序到，缓存但不交付（因为要实现rdt，不允许失序），不滑动
        发送确认：
        接收窗口尺寸=1 ；发送连续收到的最大的分组确认（累计确认）
        接收窗口尺寸>1 ；收到分组，发送那个分组的确认（非累计确认）
      - 正常情况下的2个窗口互动
        
        发送窗口
        来了老的低序号分组的确认->后沿向前滑动->新的分组可以落入发送窗口的范围
        有新的分组落入发送缓冲区范围，发送->前沿滑动
        接收窗口
        收到分组，落入到接收窗口范围内，接收
        是低序号，发送确认给对方
        发送端上面来了分组->发送窗口滑动->接收窗口滑动->发确认
      - 异常情况下GBN窗口互动
        
        发送窗口
        新分组落入发送缓冲区范围，发送->前沿滑动
        超时重发机制让发送端将发送窗口中的所有分组发送出去
        来了老分组的重复确认->后沿不向前滑动->新的分组无法落入发送缓冲区的范围（此时如果发送缓冲区有新的分组可以发送）
        接收窗口
        收到乱序分组，没有落入到接收窗口范围内，抛弃
        （重复）发送老分组的确认，累计确认；
      - 异常情况下SR窗口互动
        
        发送窗口
        新分组落入发送缓冲区范围，发送->前沿滑动
        超时重发机制让发送端将超时的分组重新发送出去
        来了乱序分组的确认->后沿不向前滑动->新的分组无法落入发送缓冲区的范围（此时如果发送缓冲区有新的分组可以发送）
        接收窗口
        收到乱序分组，落入到接收窗口范围内，接收
        发送该分组的确认，单独确认；
    - 流水线协议：回退N步(GBN)
    - 流水线协议：选择重传(SR)
    - GBN协议和SR协议的异同
      - 相同之处
        发送窗口>1
        一次能够可发送多个未经确认的分组
      - 不同之处
        GBN :接收窗口尺寸=1
        接收端：只能顺序接收
        发送端：从表现来看，一旦一个分组没有发成功，如：0,1,2,3,4; 假如1未成功，234都发送出去了，要返回1再发送1
        SR: 接收窗口尺寸>1
        接收端：可以乱序接收
        发送端：发送0,1,2,3,4，一旦1未成功，2,3,4,已发送，无需重发，选择性发送1
    - 流水线协议：总结
      - Go-back-N
        发送端最多在流水线中有N个未确认的分组
        接收端只是发送累计型确认cumulative ack
        接收端如果发现gap，不确认新到来的分组
        发送端拥有对最老的未确认分组的定时器
        只需设置一个定时器
        当定时器到时，重传所有未确认分组
      - Selective Repeat
        发送端最多在流水线中有N个未确认的分组
        接收方对每个到来的分组单独确认individual ack（非累计确认）
        发送方为每个未确认的分组保持一个定时器
        当超时定时器到时，只是重发到时的未确认分组
    - GBN vs SR