Chapter 5
传输层
端到端通信的核心：TCP可靠传输与UDP高效传输
传输层概述
传输层核心功能 HOT
- 端到端通信（进程到进程），区别于网络层的主机到主机
- 复用和分用：多个进程共用网络层，通过端口号区分
- 差错控制、流量控制、拥塞控制
- 传输单位：TCP报文段、UDP用户数据报
端口号 KEY
- 范围：0-65535
- 熟知端口(0-1023)：FTP(21)、SSH(22)、SMTP(25)、DNS(53)、HTTP(80)、HTTPS(443)
- 登记端口(1024-49151)
- 动态端口(49152-65535)
无连接服务与面向连接服务
| 对比项 | 面向连接（TCP） | 无连接（UDP） |
|---|---|---|
| 连接建立 | 必须建立连接（三次握手） | 无需建立连接 |
| 可靠性 | 可靠传输（序号+确认+重传） | 不可靠，尽力而为 |
| 传输方式 | 面向字节流 | 面向数据报 |
| 流量控制 | 有（滑动窗口） | 无 |
| 拥塞控制 | 有（慢开始/拥塞避免等） | 无 |
| 首部开销 | 大（20字节+选项） | 小（8字节） |
| 适用场景 | 文件传输、网页浏览、邮件 | 视频语音、实时游戏、DNS查询 |
| 是否按序 | 保证按序交付 | 不保证按序 |
| 通信端点 | 一对一（全双工） | 一对一、一对多、多对多 |
TCP协议
TCP特点 HOT
- 面向连接、可靠传输、面向字节流
- 全双工通信
- 有流量控制和拥塞控制
- 报文段格式：源端口、目的端口、序号、确认号、数据偏移、标志位、窗口、校验和
- TCP报文段首部：
- 源端口(2字节)：发送方端口号
- 目的端口(2字节)：接收方端口号
- 序号(4字节)：本报文段数据第一个字节的序号
- 确认号(4字节)：期望收到对方下一个字节的序号，ACK=1时有效
- 数据偏移(4位)：TCP首部长度，以4字节为单位，最大60字节
- 保留(6位)：预留，设为0
- 标志位(6位)：
- URG：紧急指针有效
- ACK：确认号有效
- PSH：推送操作，立即交付应用层
- RST：复位连接
- SYN：同步序号，建立连接用
- FIN：发送方数据发完，释放连接
- 窗口(2字节)：接收窗口大小rwnd，用于流量控制
- 校验和(2字节)：强制检验，含伪首部
- 紧急指针(2字节)：URG=1时有效，紧急数据字节数
- 选项：MSS、窗口扩大、时间戳、SACK等，最多40字节
TCP三次握手
动画步骤 0 / 5
点击播放按钮开始动画演示
三次握手详解 HOT
- 第一次：Client → Server，SYN=1，seq=x
- 第二次：Server → Client，SYN=1，ACK=1，seq=y，ack=x+1
- 第三次：Client → Server，ACK=1，seq=x+1，ack=y+1
- 为什么不能两次：防止失效连接请求到达服务器
TCP四次挥手
动画步骤 0 / 5
点击播放按钮开始动画演示
四次挥手详解 HOT
- 第一次：Client → Server，FIN=1，seq=u
- 第二次：Server → Client，ACK=1，seq=v，ack=u+1
- 第三次：Server → Client，FIN=1，ACK=1，seq=w，ack=u+1
- 第四次：Client → Server，ACK=1，seq=u+1，ack=w+1
- TIME_WAIT状态：等待2MSL后关闭
- 为什么需要TIME_WAIT：
- 确保最后一个ACK到达（若Server未收到ACK，可重传FIN，Client重新发送ACK）
- 防止失效的连接请求报文段出现在本连接中（让本连接期间产生的所有报文段从网络中消失）
TCP可靠传输机制 HOT
- TCP通过以下机制保证可靠传输：
- 序号(seq)：TCP首部有序号字段，数据的每一个字节都有编号
- 序号字段值指本报文段所发送数据的第一个字节的序号
- 初始序号(ISN)：连接建立时随机选择
- 确认(ACK)：累计确认，确认号表示期望收到对方下一个字节的序号
- ACK=1时确认号字段才有效
- 收到不连续的数据时，先缓存，等缺失部分到达后再上交
- TCP通常采用延迟确认（收到两个最大报文段或延迟500ms内发送ACK）
- 超时重传：发送方在规定时间内未收到确认，重传报文段
- 重传超时时间(RTO)：动态计算，略大于加权平均往返时间RTT_s
- Karn算法：重传报文段的往返时间样本不被采用，避免二义性
- 超时重传时RTO加倍（指数退避）
- 选择确认(SACK)：接收方告知发送方哪些数据已收到，只重传丢失的
- 需要在选项字段中携带SACK信息
- 提高传输效率，类似数据链路层的选择重传
- 序号(seq)：TCP首部有序号字段，数据的每一个字节都有编号
- 快重传：收到3个重复ACK就立即重传，不必等待超时（见拥塞控制部分）
TCP流量控制 KEY
- 目的：让发送方的发送速率不超过接收方的处理能力，防止接收方缓存溢出
- 方法：滑动窗口机制，接收方在TCP首部的窗口字段通知自己的接收窗口大小(rwnd)
- 发送窗口 = min(拥塞窗口cwnd, 接收窗口rwnd)
- 流量控制过程：
- 建立连接时，双方通告自己的初始窗口大小
- 接收方在ACK中携带当前窗口大小
- 发送方根据接收窗口调整发送量
- 接收窗口=0时，发送方停止发送数据
- 死锁问题：接收方发送了窗口为0的ACK后，后续发送的非零窗口通知丢失，发送方一直等待
- 解决方法：发送方设置持续计时器，窗口为0时定期发送探测报文（1字节），询问接收窗口大小
- 糊涂窗口综合征：发送方每次只发少量数据，导致大量小报文，效率低
- 解决：Nagle算法——收集足够数据再发送，或接收方延迟确认
- Nagle算法：数据积累到一个MSS或收到ACK时才发送
发送窗口大小 = min(cwnd, rwnd)
TCP拥塞控制
拥塞控制算法 HOT
- 慢开始：cwnd从1开始，每RTT翻倍（指数增长）
- 拥塞避免：cwnd每RTT加1（线性增长）
- 快重传：收到3个重复ACK立即重传
- 快恢复：ssthresh=cwnd/2，cwnd=ssthresh，执行拥塞避免
- ssthresh（慢开始门限）：cwnd达到ssthresh时由慢开始转为拥塞避免
拥塞控制窗口变化曲线
动画步骤 0 / 27
点击播放按钮开始动画演示
UDP协议
UDP特点
- 无连接、不可靠、面向数据报
- 无流量控制和拥塞控制
- 首部仅8字节：源端口(2)+目的端口(2)+长度(2)+校验和(2)
- 适用场景：DNS、视频、语音等实时应用
UDP数据报与检验
- UDP首部（8字节）：
- 源端口：2字节，发送方端口，可选（不需要时填0）
- 目的端口：2字节，接收方端口，必须
- 长度：2字节，UDP首部+数据的总长度，最小值为8
- 校验和：2字节，可选，全0表示不检验
- UDP检验和计算：
- 计算时需加上伪首部（12字节）：源IP(4)+目的IP(4)+0(1)+协议(1)+UDP长度(2)
- 伪首部不传输，仅用于校验，确保数据报送达正确的主机和进程
- 检验范围：伪首部 + UDP首部 + UDP数据
- 计算方法：二进制反码求和，结果取反填入校验和字段
- 接收方重新计算，若结果全1（即无错误），则通过
- UDP检验和是可选的（与TCP不同，TCP是强制的）
- 注意：
- UDP是面向报文的，对应用层交下来的报文，添加首部后直接交给网络层
- 一次发送一个UDP报文，报文边界不合并也不拆分
- 没有流量控制和拥塞控制，适合实时应用（音视频、游戏）
TCP vs UDP 对比
| 比较项 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接 | 无连接 |
| 可靠性 | 可靠传输 | 不可靠 |
| 传输方式 | 字节流 | 数据报 |
| 首部大小 | 20字节 | 8字节 |
| 流量控制 | 有 | 无 |
| 拥塞控制 | 有 | 无 |
| 适用场景 | HTTP/FTP/SMTP | DNS/视频/语音 |