第三章传输层

传输层协议为运行在不同host上的进程提供了一种逻辑通信机制。（端到端）

将消息封装为数据段或将数据段解封装交给应用层。

协议：

• Internet上的TCP
• Internet上的UDP

网络层提供主机之间的逻辑通信机制，传输层提供应用进程之间的逻辑通信机制。传输层位于网络层之上，依赖于网络层服务，对网络层服务进行增强。

多路复用和多路分用

如果某层的一个协议对应上层的多个协议/实体，则需要复用/分用。

无连接分用

UDP的Socket用二元组标识（目的IP地址、目的端口号）。

主机收到UDP段后：

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

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

面向连接的分用

TCP用四元组标识：

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

UDP

基于Internet IP协议：

• 复用/分用
• 简单的错误校验

尽力而为的服务模型，UDP段可能丢失也可能非按序到达，无需建立连接，因此发送方和接收方之间不需要握手，每个UDP段的处理独立于其他段。

• 无需建立连接（减少延迟）
• 实现简单，无需维护连接状态
• 头部开销
• 妹有拥塞控制，应用可更好地控制发送时间和速率

常用于容忍丢失速率敏感的流媒体应用，还用于DNS和SNMP，如果要实现可靠数据传输，则应该在应用层上实现增加可靠性机制以及错误恢复机制。

UDP校验和

检测UDP段在传输中是否发生错误。

发送方：

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

接收方：

• 计算校验和
• 对比如果不相等检测出错误，相等也不一定无错误

TCP

可靠数据传输

不错、不丢、不乱

rdt1.0 ：可靠信道上的可靠数据传输

底层信道完全可靠（不会发生错误，不会丢弃分组）

发送方和接收方的FSM独立

rdt2.0 

底层信道可能翻转分组中的位（bit）：利用校验和检测位错误。

• 确认机制（ACK）：接受方显式地告知发送方分组已经正确接收
• NAK：接收方显示地告知发送方分组有错误
• 发送方收到NAK后，重传分组

Rdt2.0：

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

停-等协议 

rdt2.1

• 为ACK/NAK增加校验和，检错并纠错
• 发送方收到被破坏ACK/NAK时不知道接收方发生了什么，添加额外的控制消息
• 如果ACK/NAK坏掉，发送方重传
• 不能简单的重传，产生重复分组
• 发送方为每个分组增加序列号
• 接收方丢弃重复分组
• 仍然使用停-等协议

发送方：

接收方：

发送方：

•  为每个分组添加序列号
• 需检验ACK/NAK消息是否发生错误
• 状态数量翻倍：需要记住当前分组的序列号

接收方：

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

rdt2.2

• 只使用ACK
• 接收方通过ACK告知最后一个被正确接收的分组
• 在ACK消息中显式地加入被确认分组的序号
• 收到重复ACK之后重传当前分组

rdt3.0

• 信道极可能发生错误，也可能丢失分组
• 发送方等待合理的时间：如果没收到ACK，重传
• 定时器

 

 

流水线机制 

提高资源利用率

• 允许发送方在收到ACK之前连续发送多个分组
• 需要更大的序列号范围
• 发送方和接收方需要更大的存储空间以缓存分组

滑动窗口协议

窗口：

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

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

GBN协议（后退N帧协议）

• 分组头部包含k-bit序列号
• 窗口尺寸为N，最多允许N个分组未确认
• ACK(n)：确认到序列号n（包含n）的分组均已被正确接收：可能收到重复ACK
• 为空中的分组设置计时器
• 超时事件：重传序列号大于等于n，还未收到ACK的所有分组

 发送方没啥好说的不写了

接收方

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

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

乱序到达的分组：

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

SR协议

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

 Ns + Nr <= 2^k

TCP协议

• 点对点的通信：一个发送方，一个接收方
• 可靠的、按序的字节流
• 流水线机制：TCP拥塞控制和流量控制机制设置窗口尺寸
• 发送方/接收方缓存
• 全双工：同一连接中能够传输双向数据流
• 面向连接：通信双方在发送数据之前必须建立连接；连接状态只在连接的两端中维护，在沿途节点中并不维护状态；TCP连接包括：两台主机上的缓存、连接状态数量、socket等
• 流量控制机制

TCP段结构

序列号： 

• 序列号指的是一个段中第一个字节的编号，而不是段的编号
• 建立TCP连接的时候，双方随机选择序列号

ACK:

• 希望接收到的下一个字节的序列号
• 累计确认：该序列号之前的所有字节均已被正确收到

TCP可靠数据传输

• 在IP层提供的不可靠服务基础上实现可靠数据传输服务
• 流水线机制
• 累计确认
• TCP使用单一重传计时器
• 触发重传的事件：超时，收到重复ACK

RTT和超时

定时器超时时间：大于RTT（过短导致不必要重传，过长导致对段丢失反应慢）

发送方

从应用层收到数据：

• 创建段
• 序列号是段的第一个字节的编号
• 开启计时器
• 设置超时时间

超时：

• 重传引起超时的段
• 重启计时器

收到ACK

• 如果确认此前未确认的段：更新sendbase，如果还有未被确认的分组，重启计时器

快速重传机制

通过重复的ACK检测分组丢失，如果收到对同一数据的三个ACK，则假定该数据之后的段已经丢失，快速重传：在定时器超时之前即进行重传。

TCP流量控制

本质为速度匹配机制。

TCP连接管理

 

 

拥塞控制原理

拥塞：太多主机发送太多数据或速度太快，以至于网络无法处理

• 分组丢失（路由器缓存溢出）
• 分组延迟过大（在路由器缓存中排队）

端到端拥塞控制：

• 网络层不需要显式的提供支持
• 端系统通过观察loss、delay等网络行为判断是否拥塞
• TCP使用这种方法

网络辅助的拥塞控制：

• 路由器向发送方显式地反馈网络拥塞信息
• 简单的拥塞指示
• 指示发送方应该采用何种速率

TCP拥塞控制

• 限制发送速率
• Congwin：动态调整发送速率，反应所感知的网络拥塞

加性增，乘性减

逐渐增加发送速率，谨慎探测可用带宽，直到发生loss

1. 最开始指数性增长；
2. 当congwin达到loss时间前值的1/2时，开始线性增长；
3. loss事件发生时，被设置为loss时间前congwin值的1/2；

三个重复的ACK：

• congwin切到一半
• 然后线性增长

timeout事件：

• congwin直接设为一个MSS
• 然后指数增长
• 达到threshold之后，再线性增长

TCP拥塞控制算法

TCP性能分析

吞吐率：

congwin 超时时为W，0.75/RTT

传输层

服务的主要内容：

• 复用/解复用
• 可靠数据传输
• 流量控制
• 拥塞控制

传输层：

• UDP
• TCP