第三章：TCP 协议——可靠的传输管道

TCP 是互联网最重要的协议之一。你每次打开网页、调用 API，底层都在用它。

本章用最通俗的方式，让你理解 TCP 的核心机制。

3.1 TCP 是什么？

TCP，全称 Transmission Control Protocol（传输控制协议）。

它解决的核心问题是：

怎样保证数据从 A 完整、有序、不丢失地传到 B？

网络环境很复杂——数据可能丢失、可能乱序到达、可能重复。TCP 的工作就是在这种不靠谱的网络上，建立一条”靠谱的管道”。

一个类比

想象你要在嘈杂的工地里和对面的人说一段很长的话：

你每说一句，就要等对方点头确认听到了
对方没点头？你再说一遍
说的内容要按顺序，不能跳着说
开始前先确认对方准备好了，结束后说”再见”

这就是 TCP 的工作方式。

3.2 关键概念：IP 地址和端口

在学 TCP 之前，先理解两个基础概念。

IP 地址——网络中的门牌号

每台联网的设备都有一个 IP 地址，就像每栋楼都有一个门牌号。

IPv4 示例：192.168.1.100       ← 你的电脑
IPv4 示例：104.18.7.192        ← OpenAI 的服务器

数据要从你的电脑发到 OpenAI 的服务器，首先得知道对方的 IP 地址。

端口——楼里的房间号

一台电脑（服务器）上可能同时运行很多程序——网页服务、数据库、AI 模型等等。

怎么区分数据是给哪个程序的？靠端口号。

IP 地址 = 一栋大楼的地址
端口号 = 楼里的房间号

104.18.7.192:443 → 这栋楼（服务器）的 443 号房间（HTTPS 服务）

常见端口号

端口号	对应服务	说明
80	HTTP	普通网页
443	HTTPS	加密网页（几乎所有现代网站）
3306	MySQL	数据库
6379	Redis	缓存数据库
8080	常用测试端口	本地开发常用

IP + 端口 = 完整地址

你的电脑 192.168.1.100:54321  ←→  OpenAI 服务器 104.18.7.192:443
          (随机端口)                              (HTTPS 端口)

TCP 连接需要知道”从哪来”和”到哪去”的完整地址（IP + 端口）。

3.3 三次握手——建立连接

TCP 是面向连接的协议。传数据之前，双方必须先”建立连接”。

这个过程叫三次握手（Three-Way Handshake）。

过程详解

客户端（你的电脑）                    服务器（API 服务）
      │                                    │
      │                                    │
      │  ① SYN ──────────────────────→     │
      │     "你好，我想和你建立连接"            │
      │     （我的初始序号是 100）              │
      │                                    │
      │     ←────────────────── ② SYN+ACK  │
      │     "收到，我也想和你建立连接"           │
      │     （你的 100 我收到了，我的初始序号是 200）│
      │                                    │
      │  ③ ACK ──────────────────────→     │
      │     "好的，收到你的确认，连接建立！"      │
      │     （你的 200 我也收到了）              │
      │                                    │
      │      ═══════ 连接建立 ═══════        │
      │         可以开始传输数据了              │

用打电话来理解

你：     "喂，能听到吗？"        ← 第一次握手（SYN）
对方：   "能听到，你能听到我吗？"  ← 第二次握手（SYN+ACK）
你：     "能听到，开始说正事吧"    ← 第三次握手（ACK）

为什么一定要三次？

两次行不行？不行。

第一次握手：服务器知道”客户端能发”
第二次握手：客户端知道”服务器能收也能发”
第三次握手：服务器知道”客户端也能收”

三次握手保证了：双方都确认了”我能发，对方能收”。

如果只有两次，服务器不知道客户端是否能收到自己发的消息，可能会白白占用资源。

对开发者的影响

三次握手需要时间（至少 1.5 个网络往返），这就是为什么：

第一次调用 API 比后续调用慢（需要建立连接）
使用”连接池”可以复用已有连接，提升性能
HTTPS 更慢（TCP 握手之后还要 TLS 握手）

3.4 数据传输——确认与重传

连接建立后，就可以传数据了。TCP 用”确认 + 重传”机制保证数据可靠送达。

基本原理

发送方                              接收方
   │                                  │
   │  ── 数据包 #1 ──────────────→    │
   │  ←──────────── 确认收到 #1 ──    │   ✅ 正常
   │                                  │
   │  ── 数据包 #2 ────── ✘ 丢失了    │
   │     （等了一会儿没收到确认...）      │
   │  ── 数据包 #2（重传）──────→      │   🔄 重传
   │  ←──────────── 确认收到 #2 ──    │   ✅ 成功
   │                                  │
   │  ── 数据包 #3 ──────────────→    │
   │  ←──────────── 确认收到 #3 ──    │   ✅ 正常

微信”已读”类比

你发一条消息 → 看到”已读” → 放心了（对方确认收到）
你发一条消息 → 一直没”已读” → 你会再发一遍（超时重传）
如果对方收到了两条一样的 → 它会自动忽略重复的（去重）

序号机制——保证有序

网络中数据包可能走不同的路线，到达的顺序可能和发送顺序不同。

TCP 给每个数据包编上序号，接收方按序号重新排列：

发送顺序：#1  #2  #3  #4  #5

实际到达：#1  #3  #2  #5  #4
                 ↓ TCP 重新排列
最终结果：#1  #2  #3  #4  #5  ✅

小结：TCP 的可靠传输三板斧

机制	解决的问题	类比
确认（ACK）	数据有没有送到？	微信”已读”
重传	数据丢了怎么办？	没”已读”就再发一遍
序号	数据顺序乱了怎么办？	给页码，按页码排列

3.5 四次挥手——断开连接

通信结束后，需要正式”断开连接”。这个过程叫四次挥手（Four-Way Handshake）。

过程详解

客户端                                服务器
   │                                    │
   │  ① FIN ──────────────────────→    │
   │     "我这边说完了，不再发数据了"        │
   │                                    │
   │     ←──────────────────── ② ACK   │
   │     "知道了，但我可能还有数据要发"       │
   │                                    │
   │     （服务器发送剩余数据...）           │
   │                                    │
   │     ←──────────────────── ③ FIN   │
   │     "我也说完了，不再发了"              │
   │                                    │
   │  ④ ACK ──────────────────────→    │
   │     "好的，再见！"                    │
   │                                    │
   │      ═══════ 连接关闭 ═══════       │

为什么是四次而不是三次？

因为 TCP 是全双工的——双方可以同时发送数据。

断开连接时，每一方都要独立地说”我说完了”：

客户端说”我说完了” → 服务器确认
服务器说”我也说完了” → 客户端确认

所以需要四次。

用挂电话来理解

你：     "我说完了"              ← 第一次挥手（FIN）
对方：   "好的我知道了"           ← 第二次挥手（ACK）
         （对方可能还有话要说...）
对方：   "我也说完了"             ← 第三次挥手（FIN）
你：     "好的，挂了，再见"       ← 第四次挥手（ACK）

3.6 TCP 的完整生命周期

把上面的内容串起来：

┌──────────────────────────────┐
│  第一阶段：三次握手（建立连接）    │
│  "你好" → "你好你好" → "开始吧"  │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│  第二阶段：数据传输              │
│  发送数据 → 确认 → 发送 → 确认   │
│  （丢了就重传，乱了按序号排列）    │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│  第三阶段：四次挥手（断开连接）    │
│  "我说完了" → "好" →            │
│  "我也说完了" → "再见"           │
└──────────────────────────────┘

TCP 就像打电话：拨号接通 → 通话 → 挂断。每一步都有确认，确保双方同步。

3.7 TCP 与 AI 开发的关系

场景	TCP 在做什么
调用 OpenAI API	你的电脑和 OpenAI 服务器建立 TCP 连接
发送请求	HTTP 请求数据通过 TCP 连接传输
等待响应	AI 生成的回答通过同一个 TCP 连接返回
流式输出	TCP 连接保持打开，数据分块持续传输
请求完成	TCP 连接关闭（或放回连接池复用）

你可能遇到的 TCP 层错误

# 连接超时——TCP 握手失败，对方服务器无响应
ConnectionTimeoutError: Connection to api.openai.com timed out

# 连接被拒绝——对方服务器存在，但端口没开
ConnectionRefusedError: [Errno 111] Connection refused

# 连接被重置——连接过程中对方突然断开
ConnectionResetError: [Errno 104] Connection reset by peer

看到这类错误，第一反应应该是检查：

网络是否通畅（能不能 ping 通对方）
对方服务器是否在运行
端口号是否正确
是否有防火墙/代理拦截

本章小结

TCP 是传输层协议，保证数据完整、有序、不丢失地传输
IP 地址 + 端口 = 网络中的完整地址
三次握手建立连接：SYN → SYN+ACK → ACK
确认 + 重传 + 序号保证数据可靠传输
四次挥手断开连接：FIN → ACK → FIN → ACK
TCP 就像打电话：接通 → 通话 → 挂断

记住核心：TCP 是一条可靠的管道。你把数据交给它，它保证送到。

下一章，我们学习 HTTP 协议——AI 应用开发中你每天都要打交道的协议。

← 上一章：网络分层模型 | 下一章：HTTP 协议 →