重点部分：

掌握Internet的传输层协议：

• UDP：无连接传输服务
• TCP： 面向连接的传输服务
• TCP拥塞控制

传输层服务概述.png

如图，传输层协议为运行在不同HOST上的进程提供了一种逻辑通信机制

端系统运行传输层协议：

• 发送方：将应用递交的消息分成一个或多个的segment(数据报文段)， 并向下传给网络层
• 接收方：将接收到的segment组装成消息，并向上交给应用层

传输层可以为应用提供多种协议

• Internet上的TCP
• Internet上的UDP

传输层 vs 网络层

网络层：提供主机之间的逻辑通信机制
传输层：提供应用进程之间的逻辑通信机制

• 位于网络层之上
• 依赖于网络层服务
• 对网络层服务进行（可能的）增强

Internet传输层协议

可靠、按序的交付服务(TCP)

• 拥塞控制
• 流量控制
• 连接建立

不可靠的交付服务(UDP)

• 基于“尽力而为(best-effort)”的网络层，没有做可靠性方面的扩展

两种服务均不保证

• 延迟
• 带宽

---

多路复用和多路分用

如果某层的一个协议对应直接上层的多个协议/实体，则需要复用/分用
接收端进行多路分用：传输层依据头部信息将收到的segment交给正确的socket，即不同的进程（从下往上）
发送端进行多路复用：从多个socket接收数据，为每块数据封装上头部信息，生成segment，交给网络层（从上往下）

多路分用

尽管TCP和UDP不同，但它们都满足以上格式

主机接收到IP数据报(datagram)

• 每个数据报携带源IP地址、目的IP地址
• 每个数据报携带一个传输层的段(segment)
• 每个段携带源端口号和目的端口号

主机收到segment之后，传输层协议提取IP地址和端口号信息，将segment导向相应的socket

• TCP会做更多处理

无连接分用（面向UDP）

UDP的socket用二元组标识

• (目的IP地址，目的端口号)

主机收到UDP段后

• 检查段中的目的端口号
• 将UDP段导向绑定在该端口号的socket

来自不同源IP地址和/或源端口号的IP数据包被导向同一个socket

面向连接的分用

TCP的socket用四元组标识

• 源IP地址
• 源端口号
• 目的IP地址
• 目的端口号

接收端利用所有的四个值将segment导向合适的socket
服务器可能同时支持多个TCP socket

• 每个socket用自己的四元组标识

web服务器为每个客户端开不同的socket
(TCP是一对一的，一个客户机进程对应一个服务器进程)

---

UDP

UDP：user datagram protocol（RFC 768）
UDP只是在IP协议上增加了两点
基于Internet IP协议

• 复用/分用
• 简单的错误校验（只有校验，没有错误恢复）
  （传输层提供的是一个端到端的协议，所以需要在传输层增加一个错误检测机制）

“Best effort”服务，UDP段可能

• 丢失
• 非按序到达

无连接

• UDP发送方和接收方之间不需要握手
• 每个UDP段的处理独立于其他段

UDP为什么存在？

• 无需建立连接（减少延迟）
• 实现简单：无需维护连接状态
• 头部开销少（UDP：8个字节 TCP：20个字节）
• 没有拥塞控制：应用可更好地控制发送时间和速率

常用于流媒体应用

• 容忍丢失
• 速率敏感

UDP还用于

• DNS
• SNMP

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

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

UDP头部

UDP校验和(checksum)

目的：检测UDP段在传输中是否发生错误（如位翻转）
发送方：

• 将段的内容视为16-Bit整数
• 检验和计算：计算所有整数的和，进位加在和的后面，将得到的值按位求反，得到校验和
• 发送方将校验和放入checksum字段

接收方：

• 计算所收到段的校验和
• 将其与校验和字段进行对比：1.不相等：检测出错误 2.相等：没有检测出错误（但可能有错误，例如有两个位发生了翻转...）

校验和计算示例：

校验和计算

• 注意：最高位进位必须被加进去，加到最末一位

---

可靠数据传输原理

可靠：不错、不丢、不乱
可靠数据传输：rdt
信道的不可靠特性决定了可靠数据传输协议(rdt)的复杂性

• 可靠数据传输协议基本结构：接口
  可靠数据传输协议

利用状态机（Finite State Machine, FSM）刻画传输协议

状态机示意图

rdt 1.0: 可靠信道上的可靠数据传输

假设：底层信道完全可靠：

• 不会发生错误（bit error）
• 不会丢弃分组

发送方和接收方的FSM独立

rdt 1.0

---

rdt 2.0：产生位错误的信道

底层信道可能翻转分组中的位(bit)

• 利用校验和检测位错误

从错误中恢复：

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

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

Rdt 2.0中引入的新机制：

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

rdt 2.0

rdt 2.0的缺陷

如果ACK/NAK消息发生错误/被破坏， 有以下几种解决方法：

• 为ACK/NAK增加校验和，检测并纠错
• 发送方收到被破坏ACK/NCK时不知道接收方发生了什么，添加额外的控制消息
• 如果ACK/NAK坏掉，发送方重传
• 不能简单的重传：产生重复分组
• 解决重复分组问题：序列号，发送方给每个分组增加序列号，接收方丢弃重复分组

rdt2.1-发送方.png rdt2.1-接收方.png

rdt 2.2：无NAK消息协议

与rdt2.1功能相同，但是只使用ACK

• 接收方通过ACK告知最后一个被正确接收的分组
• 在ACK消息中显式地加入被确认分组的序列号
• 发送方收到重复ACK之后，采取与收到NAK消息相同的动作，重传当前分组
  rdt2.2.png

---

rdt 3.0

如果信道既可能发生错误，也可能丢失分组，则rdt 2.x 的“校验和+序列号+ACK+重传”不够用.
方法：发送方等待“合理”时间

• 如果没收到ACK，重传
• 如果分组或ACK只是延迟而不是丢了：重传会产生充分，序列号机制能够处理；接收方需在ACK中显式告知所确认的分组

• 需要定时器.

  
  rdt3.0.png

rdt3.0示例1 rdt3.0示例2.png

rdt 3.0性能分析

rdt 3.0能够正确工作，但性能很差

rdt3.0性能分析.png

rdt 3.0停等操作.png

流水线机制：提高资源利用率

流水线机制.png
流水线协议：允许发送方在收到ACK之前连续发送多个分组

• 更大的序列号范围（原本只有0和1，不够）
• 发送方和/或接收方需要更大的存储空间以缓存分组

---

滑动窗口协议（Sliding-window protocol）

窗口：

• 允许使用的序列号范围
• 窗口尺寸为N：最多有N个等待确认的消息

滑动窗口：

• 随着协议的运行，窗口在序列号空间内向前滑动

滑动窗口协议：GBN， SR

滑动窗口协议.png

---

滑动窗口协议一：GBN

GBN：Go-Back-N协议

• 分组头部包含K-bit序列号

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

  
  GBN.png
• ACK(n):确认序列号n（包含n）的分组均已被正确接收（是一个累积确认机制），可能收到重复ACK
• 为空中的分组设置计时器timer

• 超市Timeout(n)事件：重传序列号大于等于n，还未收到ACK的所有分组

  
  GBN：发送方扩展FSM.png

GBN：接收方扩展FSM.png

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

• 可能产生重复的ACK
• 只需要记住唯一的expectedseqnum（所以是没有缓存的，只记住一个expectedseqnum就好）

乱序到达的分组：

• 直接丢弃->接收方没有缓存

• 重新确认序列号最大的、按序到达的分组

  
  GBN示例.png
  

  如上图所示，是一个GBN的示例。首先发0～3个pk，其中0和1正确到达，接收方发给发送方ACK。而pk2丢失了，此时接收方的expectedseqnum是2，然而2并未正确的到达。当pk3到达时，此时接收方的expectedseqnum还是2，所以并不会接收pk3。由于ACK0和ACK1，窗口向后滑动，则开始发送pk4&5，它们和pk3一样，由于expectedseqnum是2,而不会被接收，会被丢弃。此时发生了超时，而ACK2还未到达，故重新从pk2开始发送。

---

滑动窗口协议二：SR

SR：Selective Repeat协议
GBN有很明显的缺陷：1.它是一个累积接收机制，如果有一个分组被丢弃，则后面的都会丢弃 2.从第一个被丢弃的分组开始重传，会导致很多重复的重传

SR的motivation:

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

SR发送方/接收方窗口.png SR协议.png SR协议示例.png