云课堂入门整理---计算机网络-传输层(一)

一、概述

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


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值