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

一、概述

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的状态机很简单,不作赘述. 

看图即可 

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): 发送方给每个分组增加序列
e3cf
号
接收方丢弃重复分组

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

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