远方的岛第三章 传输层
type
status
date
slug
summary
tags
category
icon
password
3.1 传输层服务
传输层：为运行在不同主机上的进程提供了一种逻辑通信机制 北京卖家发货物给哈尔滨买家
- 发送方：将应用递交的消息分成一个或多个的Segment，并向下传给网络层。
- 接收方：将接收到的Segment组装成消息，并向上交给应用层。
区分 网络层：提供主机之间的逻辑通信机制 北京发物流到哈尔滨
Internet 传输层协议
- TCP：可靠、按序的交付服务，拥塞控制、流量控制、连接建立
- UDP：不可靠的交付服务，基于“尽力而为（Best-effort）”的网络层，没有做（可靠性方面的）扩展
两种服务均不保证延迟和带宽
3.2 传输层多路复用/分用
- 发送端进行多路复用：从多个Socket接收数据，为每块数据封装上头部信息，生成Segment，交给网络层
- 接收端进行多路分用：传输层依据头部信息将收到的Segment交给正确的Socket，即不同的进程
主机接收到IP数据报：源IP地址 + 目的IP地址 + Segment（源端口号 + 目的端口号 + 其他头部信息 + 应用数据）
主机收到Segment之后，传输层协议提取IP地址和端口号信息，将Segment导向相应的Socket
- 传输层无连接分用：UDP，(目的IP地址，目的端口号)
- 传输层面向连接的分用：TCP，(源IP地址，源端口号，目的IP地址，目的端口号)
3.3 UDP协议
- 基于Internet IP协议：复用/分用、简单的错误校验
- “Best effort”服务，UDP段可能丢失或非按序到达
- 无连接：UDP发送方和接收方之间不需要握手、每个UDP段的处理独立于其他段
为什么需要UDP?
- 无需建立连接（减少延迟）
- 实现简单：无需维护连接状态
- 头部开销少
- 没有拥塞控制：应用可更好地控制发送时间和速率
常用于流媒体应用（容忍丢失、速率敏感），还用于DNS和SNMP
UDP首部长度：8B
UDP校验和（checksum）：检测UDP段在传输中是否发生错误（如位翻转）
最后取反别忘了！
发送方和接收方都会在计算校验和时“构造”伪首部。但这个伪首部不会真正发送，只是在计算校验和时临时拼进去。
3.4 可靠数据传输原理
可靠：不错、不丢、不乱、不多
RDT（Reliable Data Transfer，可靠数据传输协议）
Rdt 1.0：可靠信道上的可靠数据传输
底层信道完全可靠：不会发生错误，不会丢弃分组
发送方和接收方的状态机FSM独立
Rdt 2.0：产生位错误的信道
引入差错检测、接收方反馈控制消息（ACK/NAK）、重传
底层信道可能翻转分组中的位：利用校验和检测位错误
- 确认机制（Acknowledgements, ACK）：接收方显式地告知发送方分组已正确接收
- NAK：接收方显式地告知发送方分组有错误，发送方收到NAK后重传分组
基于这种重传机制的rdt协议称为ARQ(Automatic Repeat reQuest)协议
缺陷：ACK/NAK发生错误/被破坏时产生重复分组
解决重复分组问题：序列号
Rdt 2.1：应对ACK/NAK破坏
发送方：为每个分组增加了序列号，两个序列号(0, 1)就够用、需校验ACK/NAK消息是否发生错误、状态数量翻倍
接收方：需判断分组是否是重复，当前所处状态提供了期望收到分组的序列号
接收方无法知道ACK/NAK是否被发送方正确收到
Rdt 2.2：无NAK消息协议
接收方通过ACK告知最后一个被正确接收的分组，在ACK消息中显式地加入被确认分组的序列号
发送方收到重复ACK之后，采取与收到NAK消息相同的动作，即重传当前分组
Rdt 3.0：停-等协议
信道既可能发生错误，也可能丢失分组
发送方等待“合理”时间，需要定时器
- 如果没收到ACK，重传
- 如果分组或ACK只是延迟而不是丢了：重传会产生重复，序列号机制能够处理，接收方需在ACK中显式告知所确认的分组
性能很差，信道利用率低
流水线机制：提高资源利用率，允许发送方在收到ACK之前连续发送多个分组
- 更大的序列号范围
- 发送方和/或接收方需要更大的存储空间以缓存分组
停等协议的信道利用率
滑动窗口协议
滑动窗口协议的信道利用率
GBN协议（Go-Back-N，后退N帧）
- 发送方
窗口尺寸为N，最多允许N个分组未确认
ACK(n)：确认到序列号n(包含n)的分组均已被正确接收，累计确认，可能收到重复ACK
设置计时器
超时Timeout(n)事件：重传序列号大于等于n，还未收到ACK的所有分组
- 接收方
ACK机制：发送拥有最高序列号的、已被正确接收的分组的ACK
接收方没有缓存，直接丢弃乱序到达的分组，重新确认序列号最大的、按序到达的分组
SR协议（Selective Repeat，选择重传）
接收方对每个分组单独进行确认，设置缓存机制，缓存乱序到达的分组
发送方只重传没收到ACK的分组，为每个分组设置定时器
窗口大小与序号空间的约束条件
序号进制：序号用完了要从0开始重新编
课堂练习
3.5 TCP协议
GBN/SR 是“可靠数据传输”的机制模型，TCP 是这种机制在传输层的实际工程实现（带更多功能），UDP 则完全不实现这些机制。
TCP概述
- 点对点：一个发送方，一个接收方
- 可靠的、按序字节流
- 流水线机制：TCP拥塞控制和流量控制，机制设置窗口尺寸
- 发送方/接收方缓存
- 全双工：同一连接中能够传输双向数据流
- 面向连接
- 通信双方在发送数据之前必须建立连接
- 连接状态只在连接的两端中维护，在沿途节点中并不维护状态
- TCP连接包括：两台主机上的缓存、连接状态变量、socket等
- 流量控制
- 拥塞控制
TCP段结构
序号是段（ Segment ）中第1个字节的编号
TCP首部最短长度：20B
TCP可靠数据传输
TCP在IP层的不可靠服务基础上实现可靠数据传输服务
- 累积确认
- TCP使用单一重传定时器
- 触发重传的事件：超时、收到重复ACK
- 渐进式
序列号和ACK、RTT和超时
快速重传机制：在定时器超时之前即进行重传，如果sender收到对同一数据的3个额外ACK，则假定该数据之后的段已经丢失
课堂练习
TCP流量控制
接收方为TCP连接分配buffer
速度匹配机制：
Receiver通过在Segment的头部字段将RcvWindow告诉Sender
Sender限制自己已经发送的但还未收到ACK的数据不超过接收方的空闲RcvWindow尺寸
TCP连接管理
建立连接：三次握手
步骤 1（客户端 → 服务端）：客户端主机向服务器发送一个 TCP SYN 段（同步报文）
- 客户端状态变化：
CLOSED→SYN-SENT
- 客户端发送： 一个带有
SYN=1的包，请求建立连接，并选择一个初始 序列号seq = x
- 服务端状态：
LISTEN，等待连接
- 此时不携带数据
步骤 2（服务端 → 客户端）：服务器主机收到 SYN 后，回复一个 SYNACK 段（同步确认报文）
- 服务端状态变化：
LISTEN→SYN-RECEIVED
- 服务器分配缓存和资源
- 服务端收到 SYN 包后，回应一个
SYN + ACK包： SYN = 1：表示服务端也同意建立连接ACK = 1：确认客户端的 SYNseq = y：服务端自己的初始 序列号ack = x+1：确认号是客户端 序列号 + 1
步骤 3（客户端 → 服务端）：客户端收到 SYNACK 后，发送一个 ACK 段（确认报文） 作为回应
- 客户端状态变化：
SYN-SENT→ESTABLISHMENT
- 客户端收到服务端的 SYN + ACK 后，回应一个
ACK包： ACK = 1：确认服务端的 SYNack = y+1：确认号是服务端 序列号 + 1
- 该段可以携带数据
这三次握手的 主要目的 是：
- 客户端确认服务端可达（第一次握手）
- 服务端确认客户端可达，并携带自己的 序列号（第二次握手）
- 客户端再次确认服务端的响应，确保双向通信建立（第三次握手）
关闭连接：四次挥手
第一次挥手：客户端发起关闭请求
- 客户端状态变化：
ESTABLISHMENT→FIN-WAIT-1
- 客户端动作： 应用层调用
close()，客户端发送FIN=1, seq=u，表示不再发送数据了，但仍可以接收数据
第二次挥手：服务端确认关闭请求
- 服务端状态变化：
ESTABLISHMENT→CLOSE-WAIT
- 服务端动作：
- 收到
FIN后，发送ACK=1, seq=v, ack=u+1表示确认 - 通知上层应用准备关闭
- 客户端状态变化：
FIN-WAIT-1→FIN-WAIT-2
第三次挥手：服务端发起关闭请求
- 服务端动作：
- 应用层处理完毕，发送
FIN=1, ACK=1, seq=w, ack=u+1
- 服务端状态变化：
CLOSE-WAIT→LAST-ACK
- 客户端动作： 收到该
FIN报文后，进入TIME-WAIT状态
第四次挥手：客户端确认服务端关闭
- 客户端动作： 发送
ACK=1, seq=u+1, ack=w+1
- 客户端状态变化：
TIME-WAIT→ 等待 2 个最大报文生存时间（2×MSL）后 →CLOSED
- 服务端状态变化： 收到 ACK 后 →
CLOSED
课堂练习
TCP拥塞控制
发送方限制发送速率：拥塞窗口CongWin
- 慢启动SS：指数性增长（刚建立连接或超时重传后）
- 收到每个ACK进行CongWin++操作
- 效果：每个RTT将CongWin翻倍
- 加性增—乘性减AIMD：逐渐增加发送速率，谨慎探测可用带宽，直到发生丢包（正常稳定传输阶段）
- AI：每个RTT将CongWin增大1个MSS（最大报文段长度）拥塞避免
- MD：发生丢包后将CongWin减半
发送方感知网络拥塞：Loss事件
Threshold变量：Loss事件发生时, Threshold 被设为Loss事件前 CongWin 值的1/2。
- CongWin小于Threshold → 慢启动（指数增长），每个RTT将CongWin翻倍
- CongWin大于Threshold → 拥塞避免（线性增长），每个RTT将CongWin增大1个MSS
- 3 次重复 ACK → 轻度拥塞，将Threshold 设置为 CongWin 的一半，并将 CongWin 设置为 Threshold
- 超时 → 严重拥塞，将Threshold 设置为 CongWin 的一半，并将CongWin 重置为 1 MSS
课堂练习
TCP吞吐率分析
TCP拥塞控制改进（未深讲）
TCP性能分析
TCP具有公平性，UDP不具有公平性
Loading...