TCP / TRANSMISSION CONTROL PROTOCOL
RFC 793 · 1981
互联网协议导览 · 第 01 讲

TCP 是
互联网的
可靠搬运工

它确保你点的每一份外卖、刷的每一个视频、敲的每一行消息, 都能按顺序、不丢、不重复地从一台机器送到另一台机器。

SYN=1 seq=x
按 → 或 空格 翻页
EP.01 · TCP FUNDAMENTALS
TABLE OF CONTENTS
02 / 13
本次讲解

我们要聊什么?

01
基础

什么是 TCP?

从快递员的比喻出发,理解面向连接、可靠、字节流。

P.03–04
02
报文

报文段结构

20 字节首部里藏了什么秘密。

P.05
03

三次握手
四次挥手

连接的建立与拆除。

P.06–08
04
可靠传输

序列号 · ACK · 重传 · 滑动窗口

为什么 TCP 永远送达。

P.09–10
05
拥塞控制

堵车了怎么办?

慢启动 · 拥塞避免 · 快重传 · 快恢复

P.11–12
06

总结

一句话记住 TCP。

P.13
共 13 页 · 约 25 分钟
USE ARROWS TO NAVIGATE
WHAT IS TCP
03 / 13
用一个比喻

TCP 像一位
较真的快递员。

你寄出 10 个包裹,他保证:
① 一个都不会丢,丢了他重发;
② 顺序不会乱,到件时按编号排好;
③ 不会送重复,对方签收他才放心。

面向连接 可靠传输 字节流 全双工
CLIENT SERVER #1 #2 #3 按编号送达 · 丢了重发 · 收到回执
OSI 第 4 层 · 传输层
TCP IS A RELIABLE STREAM
TCP vs UDP
04 / 13
同一层的两个邻居

如果 TCP 是挂号信
UDP 就是明信片

TCP

挂号信

01
  • ✓ 三次握手建立连接
  • ✓ 保证可靠送达
  • ✓ 保证按序到达
  • ✓ 拥塞 / 流量控制
  • ✗ 首部较大(20–60 字节)
  • ✗ 延迟较高
HTTP · HTTPS · SSH · FTP · SMTP · MySQL
UDP

明信片

02
  • ✗ 无连接 · 扔了就跑
  • ✗ 不保证可靠
  • ✗ 不保证顺序
  • ✓ 几乎没有开销
  • ✓ 首部仅 8 字节
  • ✓ 延迟极低
DNS · QUIC · 视频通话 · 游戏 · DHCP
选择哪个?看你怕丢还是怕慢
RFC 793 vs RFC 768
SEGMENT STRUCTURE
05 / 13
拆开报文段看看

20 字节首部里
藏了什么?

0 15 16 31 BITS 源端口 Source Port 目的端口 Destination Port 序列号 Sequence Number (32 bit) 确认号 Acknowledgment Number (32 bit) 数据偏移 保留 URG ACK PSH RST SYN FIN 6 个控制标志位 窗口大小 Window Size 校验和 Checksum 紧急指针 Urgent Pointer 选项 Options(可变长,0–40 字节) 数据 Data ↓
SEQ

序列号给每个字节编号,丢包检测和按序重组都靠它。

ACK

确认号=对方下一个该发的字节号。"我收到 x 前的所有数据。"

FLAGS

SYN 发起连接 · FIN 关闭连接 · RST 强制断开 · ACK 表示有效

WIN

窗口大小告诉对方"我还能接收多少",用于流量控制。

20 字节基本首部 + 0–40 字节选项
RFC 9293 (2022) · SECTION 3.1
3-WAY HANDSHAKE
06 / 13
建立连接

三次握手 · 能听到吗?

CLIENT SERVER 客户端 · 你的浏览器 服务端 · 网站 CLOSED SYN_SENT ESTABLISHED LISTEN SYN_RCVD ESTABLISHED ① SYN=1, seq=x "你好,我想建立连接" ② SYN=1, ACK=1, seq=y, ack=x+1 "我也听见你了,你能听到我吗?" ③ ACK=1, seq=x+1, ack=y+1 "听到了!开始传数据"
动画每次进入此页时自动播放
HANDSHAKE COMPLETED IN 1.5 RTT
WHY 3-WAY, NOT 2-WAY
07 / 13
常见追问

为什么是三次
两次不行吗?

假设:两次握手 会出问题

迷路的旧 SYN

想象一个早就被网络遗忘的旧连接请求,突然延迟送达。 如果只两次握手,服务端立刻就建立了一条幽灵连接, 白白消耗资源等数据。

✗ 资源浪费 · ✗ 状态不一致
正解:三次握手 恰好够用

三次的本质

  • ① 客户端:"我能发"
  • ② 服务端:"我能收 + 我能发"
  • ③ 客户端:"我能收"

三次握手让双方都确认自己的发送和接收能力都正常, 同时同步初始序列号,过滤掉幽灵 SYN。

✓ 双向确认 · ✓ 初始 SEQ 协商 · ✓ 防止旧连接复活
"听到了"+"听到了"+"听到了"= 双工通道开通
RFC 9293 § 3.5
4-WAY HANDSHAKE · CLOSE
08 / 13
关闭连接

四次挥手 · 慢慢说再见

CLIENT SERVER ESTABLISHED FIN_WAIT_1 FIN_WAIT_2 TIME_WAIT CLOSED ESTABLISHED CLOSE_WAIT LAST_ACK CLOSED ① FIN=1, seq=u "我说完了" ② ACK, ack=u+1 "知道了, 等等" ③ FIN=1, seq=v "我也说完了" ④ ACK, ack=v+1 "再见" 等待 2 MSL 后才真的关闭
为什么是四次:服务端的 ACK 和 FIN 不能合并发送
2MSL ≈ 60 SECONDS
RELIABLE TRANSFER · SEQ + ACK
09 / 13
可靠传输 · 之一

每个字节都有编号

SEQ NUMBER

字节流的编号

TCP 把要发的数据想象成连续的字节流, 每一字节都有一个连续递增的编号。

SEND
seq=1001, len=8 → 发送字节 1001~1008
ACK NUMBER

确认号 = 下一个期望

对方说 ack=1009, 意思是 "1009 以前的我都收到了,下一个发 1009"

→ seq=1001, len=8
← ack=1009
→ seq=1009, len=12
← ack=1021
累计确认 · CUMULATIVE ACK
一个 ACK 可以确认之前所有已收到的数据。
序列号让乱序变有序
32 BIT · 4 GB 不重复
SLIDING WINDOW & RETRANSMIT
10 / 13
可靠传输 · 之二

滑动窗口 · 边走边发

SLIDING WINDOW

允许"飞行中"的字节

SIZE = 6
已确认
已发未确认
可发送
不可发送

发送方不必等每个 ACK 才发下一个,而是一次塞满整个窗口, 收到 ACK 后窗口向右滑动 — 这就是"边走边发"的秘密。

RETRANSMIT

丢了?重发!

t=0 → 发送 seg#3
期待 ACK
t=RTO 超时! 重新发送 seg#3
t=RTO+ε ← 收到 ACK,继续

RTO(Retransmission Timeout)= 根据 RTT 动态计算的"该等多久"。

另有"快重传":收到 3 个重复 ACK 立即重传
窗口大小由接收方告知 = 流量控制
RFC 6298 · RTO COMPUTATION
CONGESTION CONTROL
11 / 13
路上堵车了

拥塞控制 · 不要把网络挤爆

CWND CURVE

拥塞窗口的经典曲线

单位:MSS
慢启动 指数增长

cwnd 每 RTT 翻倍,直到达到 ssthresh。

拥塞避免 线性增长

每 RTT 增加 1 MSS,温柔地探测带宽上限。

检测到拥塞 超时 / 3 dup ACK

ssthresh 减半,cwnd 重置或减半。

快恢复 不回到 1

3 个 dup ACK 后从 ssthresh 直接进入拥塞避免。

AIMD · Additive Increase, Multiplicative Decrease
TAHOE → RENO → CUBIC → BBR
FOUR ALGORITHMS
12 / 13
合在一起

四大算法 · 一张图记住

01
SLOW START

慢启动

×2

cwnd 每个 RTT 翻倍。听起来"快",叫"慢"是相对于一开始就发满。

cwnd: 1 → 2 → 4 → 8 …
02
CONGESTION AVOIDANCE

拥塞避免

+1

超过 ssthresh 后变线性,每 RTT 加 1,避免冲过头。

cwnd: 8 → 9 → 10 → 11 …
03
FAST RETRANSMIT

快重传

3 × ACK

收到 3 个重复 ACK 立即重传,不必等 RTO 超时。

省去一次超时等待
04
FAST RECOVERY

快恢复

½

配合快重传:不回到 1,直接从 ssthresh 进入拥塞避免。

Reno 的关键改进
现代 Linux 默认:CUBIC;Google 推动:BBR
RFC 5681 · TCP CONGESTION CONTROL
RECAP
13 / 13
一句话记住

TCP 用握手建立信任,
编号保证有序,
重传保证不丢,
窗口调节流量与拥塞。

CONNECT

3 次握手

ORDER

SEQ + ACK

RELIABLE

超时 + 快重传

CONTROL

滑动窗口 · AIMD

TCP · 互联网协议导览 第 01 讲
THANK YOU · ANY QUESTIONS?
01 / 13