zoukankan      html  css  js  c++  java
  • 云课堂入门整理---计算机网络-传输层(一)

    一、概述

    1.传输层协议为运行在不同Host(端系统/主机)上的进程提供了一种逻辑通信机制

    2. 端系统运行传输层协议

      • 发送方 : 将应用递交的消息分成一个或多个Segment,并向下穿给网络层
      • 接收方 : 将接收到的segment组装成消息,并向上交给应用层 
    3. 传输层可以为应用提供的协议主要有TCP和UDP(后面重点介绍)

    二、传输层与网络层(比较)

    1.网络层: 

    提供主机之间的逻辑通信 
    2.传输层: 

    -提供进程之间的逻辑通信 

    - 位于网络层之上

    - 依赖网络层服务  

    - 对网络层服务进行(可能的)增强

    三、多路复用和多路分用

    多路分用(接收端):传输层依据头部信息将收到的Segment交付给正确的Socket(应用层和传输层间的“门”),即正确的进程. 

    多路复用(发送端):多个Socket接收数据,为每块数据封装上头部信息(传输层),生成Segment,交给网络层.


    四、UDP协议(无连接传输)

    1.概述


    常用于流媒体应用

      • 容忍丢失
      • 速率敏感 
        UDP还用于DNS和SNMP

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

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

    UDP报文段结构

    UDP报文段结构很简单,主要有以下字段 

    |———-32bit———-| 

    |–源端口号–|–目的端口–| 

    |—-长度—-|—校验和—| 

    |——–应用数据———|


    2.UDP校验和(checksum)


    五、可靠数据传输(rdt)

    什么是可靠? -不错 -不丢 -不乱

    rdt1.0

    rdt1.0非常简单,假设下层信道是按序到达,不丢包,且不出现比特差错的. 
    那么rdt1.0的状态机很简单,不作赘述. 
    看图即可 
    rdt

    rdt2.0

    rdt2.0中假设的信道: 
    rdt2.0中假设信道可能会翻转分组中的位(bit)

    • 利用校验和检测位错误

    如何从错误中恢复?

    • 确认机制(Acknowledgements,ACK):接收方显式的告诉发送方分组已正确接收
    • NAK:接收方显式地告知发送方分组有错误
    • 发送方收到NAK后,重传分组

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

    rdt 2.0中引入的新机制

    • 差错检测
    • 接收方反馈控制:ACK/NAK
    • 重传

    rdt2.0的状态机 
    发送端状态机 

    接收端状态机 

    rdt2.1

    rdt2.0看起来能运行了,但是忽略了一个重要的事实,那就是ACK和NAK分组也可能会被损坏. 
    当ACK/NAK被损坏时,可以采取这几种方法:

    • 为ACK/NAK增加校验和,检错并纠错.(实现完全纠错代价太高)
    • 发送方收到被破坏ACK/NAK时不知道接收方发生了什么,添加额外的控制消息(很难确保额外的消息不会损坏,直接无解)
    • 如果ACK/NAK坏掉,发送方重传
    • 不能简单的重传:产生重复分组

    如何解决重复分组问题?

    • 序列号(Sequence number): 发送方给每个分组增加序列号
    • 接收方丢弃重复分组

    因为当发送端发送一个分组时,它会等待接收方的回复,因此这种协议被称为停止-等待协议

    rdt2.1的状态机

    发送方

    接收方

    发送方:

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

    接收方:

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

    rdt2.2

    rdt2.2在rdt2.1的基础上去除了NAK消息. 
    如何实现?

    • 接收方通过ACK告知最后一个被正确接收的分组
    • 在ACK消息中显式的被确认分组的序列号

    发送方收到重复ACK之后,采取和收到NAK一样的动作,重传当前分组.

    rdt3.0

    rdt3.0在2.X的基础上完全模拟了真实的信道.信道既可能发生错误,也可能丢失分组.

    为了解决这个问题? 
    方法: 发送方等待”合理”的时间

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

    rdt3.0的FSM 

    rdt3.0虽然能用,但是性能很差,因为这是一个停等协议.

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

    流水线机制:打破rdt3.0的停等

    流水线机制:提供资源的利用

    ------------------要实现流水线机制要有滑动窗口协议(GBN和SR)

    GBN(Go Back N)

    发送方:

    分组头部包含k-bit序列号

    窗口尺寸为N,最多允许N个分组未确认

    ACK(n):确认到序列号n的分组均已被正确接收(累计确认) 
    可能收到重复ACK 
    为空中的分组设置定时器(timer)

    超时Timeout(n)事件:重传序列号大于等于n,还未收到ACK的所有分组

    发送方FSM: 

    接收方: 
    ACK机制:发送拥有最高序列号的、已被正确接收的分区ACK

    • 可能产生重复ACK
    • 只需要记住唯一的expectedsequm

    乱序到达的分组

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

    接收方FSM 

    SR协议

    GBN的缺陷 
    * 重传所有分组,造成资源浪费

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

    SR协议的缺陷 
    如图 

    对于第一种和第二种情况,发送方发送的分组序号都是0,但是第一种情况发送的是重发的分组0. 
    而第二种情况发送的复用的序号0,实际上是一个新的分组0. 
    发送方无法分辨这两种情况. 
    因此对于SR协议,要求序列号空间满足Ns+NR<=2k


  • 相关阅读:
    第五章 条件语句
    第四章 javaScript运算符
    第三章 javaScript数据类型
    看电影学英语十
    英语口语会话十
    看电影学英语九
    英语口语会话九
    英语口语会话八
    看电影学英语八
    Linux command line and shell scripting buble
  • 原文地址:https://www.cnblogs.com/chz-blogs/p/9381024.html
Copyright © 2011-2022 走看看