传输层（TCP、UDP、RDT详解）

下层信道可能会出差错：将分组中的比特反转
- 用校验和来检验比特差错
问题：怎样从差错中恢复
- 确认（ACK：Acknowledgement）：接收方显式地告诉发送方已被正确接收
- 否定确认（NAK：Negative Acknowledgement）：接收方显式地告诉发送方分组发生了差错
  - 发送方收到NAK之后，发送方重传分组
Rdt2.0的新机制：采用差错控制编码进行差错检测
- 发送方差错控制编码、缓存
- 接收方使用编码检错
- 发送方的反馈：控制报文（ACK、NAK）：接收方 -> 发送方
- 发送方收到反馈相应的动作

Rdt2.0：FSM描述

Rdt2.0：没有差错时的操作

Rdt2.0：有差错时的操作

rdt2.0的致命缺陷！-> rdt2.1

如果ACK/NAK出错？

发送方不知道接收方发生了什么事情!
发送方如何操作？
- 重传？可能重复
- 不重传？可能死锁（或出错）
需要引入新的机制
- 序号

处理重复：

发送方在每个分组中加入序号
如果ACK/NAK出错，发送方重传当前分组
接收方丢弃（不发送给上层）重复分组

停等协议 ：发送方发送一个分组，然后等待接收方的应答

总结：下层信道可能会出错，所以引入校验和检测差错。如果接收方校验成功，发送ACK给发送方，发送方发送下一个分组；如果接收方校验失败，发送NAK给发送方，发送方重传上一个分组；存在问题：ACK与NAK可能在信道中出错。

3.Rdt2.1：序列号机制（处理出错的ACK/NAK）

发送方处理出错的ACK/NAK

接收方处理出错的ACK/NAK

Rdt2.1：讨论

发送方：

在分组中加入序列号
两个序列号（0，1）就足够了
- 一次只发送一个未经确认的分组
必须检测ACK/NAK是否出错（需要EDC）
状态数变成了两倍
- 必须记住当前分组的序列号是0还是1

接收方：

必须检测收到的分组是否是重复的
- 状态会指示希望接收到分组的序号是0还是1
注意：接收方并不知道发送方是否正确收到了其ACK/NAK
- 没有安排确认的确认

Rdt2.1的运行

总结：在Rdt2.0的基础之上，引入序号。

发送方发送pkt0，接收方等待0并接收pkt0，接收方取出pkt0的序号进行校验，如果序号错误，返回NAK0；如果序号正确，校验校验和，如果校验错误，返回NAK0，否则返回ACK0，随后等待1；
发送方等待ACK0或NAK0，如果收到ACK0，就发出pkt1；如果收到NAK0，重发pkt0；如果收到的确认出错，也重发pkt0；
此时接收方如果在等待0，那么不会收到1；如果在等待1，如果接收到0，说明发出的确认错误了，重发一个ACK。

4.Rdt2.2：无NAK的协议

功能同Rdt2.1，但是取消了NAK，只使用ACK（ack要编号）
接收方对最后正确接收的分组发ACK，以替代NAK
- 接收方必须显式地包含被正确接收分组的序号
当收到重复的ACK（例如：再次收到ACK0），发送方与收到NAK采取相同的动作：重传当前分组
为后面的一次发送多个数据单位做一个准备
- 一次能够发送多个
- 每一个的应答都有：ACK、NAK；麻烦
- 使用对前一个数据单位的ACK，代替本单位的NAK
- 确认信息减少一半，协议处理简单

Rdt2.2的运行

Rdt2.2：发送方和接受方片段

总结：使用ACK + 序号代替NAK。

5.Rdt3.0：具有比特差错和分组丢失（超时重传）的信道

新的假设：下层信道可能会丢失分组（数据或ACK）

会死锁
机制还不够处理这种状况
- 校验和
- 序列号
- ACK
- 重传

方法：发送方等待ACK一段合理的时间

发送端超时重传：如果没有收到ACK -> 重传
问题：如果分组（或ACK）只是被延迟了
- 重传会导致数据重复，但是利用序列号已经可以处理这个问题
- 接受方必须指明被正确接收的序列号
需要一个倒计时定时器

Rdt3.0发送方

Rdt3.0的运行

过早超时（延迟的ACK）也能正常工作，但是效率较低，一半的分组和确认是重复的
设置一个合理的超时时间是很重要的

Rdt3.0的性能

Rdt3.0可以工作，但链路容量比较大的情况下，性能很差
- 链路容量比较大，一次发一个PDU不能够充分利用链路的传输能力

例如：1Gbps的链路，15ms端到端的传播延迟，分组大小为1KB

Rdt3.0：停-等操作

总结：在Rdt2.2的基础上，加入了定时重传，防止了分组丢失。

6.流水线协议

流水线：提高链路利用率

流水线协议

流水线：允许发送方在未得到对方确认的情况下一次发送多个分组。

必须增加序号的范围：用多个bit表示分组的序号
在发送方/接收方要有缓冲区
- 发送方缓冲：未得到确认，可能要重传
- 接收方缓冲：上层用户取用数据的速率 != 接收到的数据速率；接收到的数据可能乱序，排序交互（可靠）

两种通用的流水线协议：回退N步（GBN）和选择重传（SR）

6.1滑动窗口（slide window）协议

发送缓冲区
- 形式：内存中的一个区域，落入缓冲区的分组可以重新发送
- 功能：用于存放已发送，但是没有得到确认的分组
- 必要性：需要重发时可用
发送缓冲区的大小：一次最多可以发送多少给未经确认的分组
- 停止等待协议 = 1
- 流水线协议 > 1，合理的值，不能很大，链路利用率不能超过100%
发送缓冲区中的分组
- 未发送的：落入缓冲区的分组，可以连续发送出去
- 已经发送出去、等待对方确认的分组 ：发送缓冲区的分组只有得到确认才能删除

|-------|-------|---------|
| 发送缓冲区 | 接收缓冲区 | 对应的协议 |
| 1 | 1 | 停止-等待协议 |
| 大于1 | 1 | CBN |
| 大于1 | 大于1 | SR |

发送窗口滑动过程：相对表示方法

采用相对移动方法表示，分组不动
可缓冲范围移动，代表一段可以发送的权利

滑动窗口协议（Slide Window）

发送窗口：发送缓冲区内容的一个范围
- 那些已发送但是未经确认分组的序号构成的空间
发送窗口的最大值
一开始：没有发送任何一个分组
- 后沿 = 前沿
- 之间为发送窗口的尺寸 = 0
没发送一个分组，前沿移动一个单位

发送窗口的移动 -> 前沿移动

发送缓冲区前沿移动的极限：不能超过发送缓冲区

发送窗口的移动 -> 后沿移动

发送窗口后沿移动
- 条件：收到老分组的确认
- 结果：发送缓冲区罩住新的分组，来了分组可用发送
- 移动的极限：不能超过前沿

6.2滑动窗口技术

发送窗口（sending window）

接收窗口（receiving window） = 接收缓冲区
- 接收窗口用于控制哪些分组可以接受
  - 只有收到的分组序号落入接收窗口内才允许接收
  - 若序号在接收窗口之外，则丢弃
- 接收窗口尺寸Wr = 1，则只能顺序接收
- 接收窗口尺寸Wr > 1，则可以乱序排放
  - 但是提交给上层的分组，要排序
- 例子：Wr = 1，在0的位置；只要有0号分组可以接受

向前滑动一个，罩在1的位置，如果来了第2号分组，则丢弃。

接收窗口的滑动和发送确认
- 滑动
  - 低序号的分组到来，接收窗口移动；
  - 高序号的分组乱序到，缓存但不交互（因为要实现Rdt，不允许失序），不滑动
- 发送确认
  - 接收窗口尺寸 = 1；发送连续收到的最大的分组确认（累计确认）
  - 接收窗口尺寸 > 1；收到分组，发送的那个分组确认（非累计确认）

6.3窗口互动（GBN与SR）

正常情况下两个窗口的互动

异常情况下GBN的两个窗口互动

异常情况下SR的两个窗口互动

GBN协议与SR协议的异同

相同之处
- 发送窗口 > 1
- 一次能够发送多个未经确认的分组
不同之处
- GBN：接收窗口尺寸 = 1
  - 接收端：只能顺序接收
  - 发送端：从表现来看，一旦一个分组没有发成功，如：1，2，3，4，5；假如1未发成功，234都发出去了，要返回1再发送；GB1。（234也需要重新发送）
- SR：接收窗口尺寸 > 1
  - 接收端：可以乱序接收
  - 发送端：发送0，1，2，3，4，一旦1未成功，234都发出去了，无需重传，选择性发1（234无需再次发送）

6.4流水线协议：总结

Go-back-N：

发送端中最多在流水线中有N个未确认的分组
接收端只是发送累计型确认cumulative ack
- 接收端如果发现gap，不确认新到来的分组
发送端拥有对最老的未确认分组的定时器
- 只需设置一个定时器
- 当定时器到时时，重传所有未确认分组

Selective Repeat：

发送端最多在流水线中有N个未确认的分组
接受方对每个到来的分组单独确认indicidual ack（非累计确认）
发送方为每个未确认分组保持一个定时器
- 当超时定时器到时，只是重发到时的未确认分组

GBN：发送方扩展的FSM

GBN：接收方扩展的FSM

运行中的GBN

在接收端，乱序的不缓存；因此哪个n分组丢失了，GB到那个分组n，即使以后的分组传送都是正确的。

选择重传SR

接收方对每个正确接收的分组，分别发送ACKn（非累计确认）
- 接收窗口 > 1
  - 可以将缓存乱序的分组
- 最终将分组按顺序交付给上层
发送发只对那些没有收到ACK的分组进行重发-选择性重发
- 发送方为每个未确认的分组设置一个定时器
发送窗口的最大值（发送缓冲区）限制发送未确认分组的个数

选择重传

选择重传SR的运行

对比GBN和SR

窗口的最大尺寸

3.面向连接的传输：TCP

1.段结构

点对点
- 一个发送方，一个接收方
可靠的、按照顺序的字节流
- 没有报文边界
管道化（流水线）
- TCP拥塞控制和流量控制设置窗口大小
全双工数据
- 在同一连接中数据流双向流动
- MSS：最大报文段大小
面向连接
- 在数据交换之前，通过握手（交换控制报文）初始化发送方、接收方的状态变量
有流量控制
- 发送发不会淹没接收方

TCP报文段结构

TCP序号、确认号

序号

报文段首字节在字节流的编号

确认号

期望从另一方收到的下一个字节的序号
累计确认

简单telnet场景：

TCP往返延时（RTT）和超时

Q：怎样设置TCP超时？

比RTT要长
- 但是RTT是变化的
太短：过早超时
- 不必要的重传
太长：对报文段丢失反应太慢，消极

Q：怎样估计RTT？

SampleRTT ：测量从报文段发出到收到确认的时间
- 如果有重传，忽略此次测量
SampleRTT会变化，因此估计的RTT应该比较平滑
- 对几个最近的测量值求平均，而不是仅用当前的SampleRTT

设置超时

2.可靠数据传输

TCP在IP不可靠服务的基础上建立了Rdt
- 管道化的报文段
  - GBN or SR
- 累计重传（GBN）
- 单个定时重传（GBN）
- 是否可以接收乱序，没有规范
通过以下时间触发重传
- 超时（只重发那个最早的未确认段：SR）
- 重复的确认
  - 例子：收到ACK50之后，又收到30个ACK50
首先考虑简化TCP发送方
- 忽略重复的确认
- 忽略流量控制和拥塞控制