---
tags: [计算机网络, TCP可靠传输, 序列号, 确认号, 重传]
create time: 2026-05-18 01:50
---

# 可靠传输机制

## 概述

TCP 承诺"可靠交付"——不管中间网络多么不可靠，发送方最终确保每个字节都被接收方完整、有序地收到。这是通过**序列号/确认号 + 重传 + 校验**组合实现的。

## 序列号（Sequence Number）

### 基本原理

每个 TCP 段有一个 32 bit 的序列号，代表该段的**第一个数据字节在整个流中的位置**。

```
发送方发出的数据流:
字节:  0     1     2     3     ...   99    100
      ├─────┼─────┼─────┼───┤       └───┤
      │ Seg1│ Seg2│ Seg3│...│         │SegN│
      seq=0 seq=50 seq=100             seq=99

Seq 值范围: 0 ~ 2^32 - 1 = 4,294,967,295 (约 4GB)
回绕: 到达最大值后回到初始 ISN (Initial Sequence Number)
```

### ISN（Initial Sequence Number）生成策略

```go
// Go 的 net包: ISN 使用随机化防止预测攻击
func getISN() uint32 {
    // crypto/rand 或 /dev/urandom
    return randomUint32()
}
```

Linux 默认 ISN = jiffies + hash(src/dst IP/port)，现代内核已改为完全随机化。

## 确认号（Acknowledgment Number）

| 含义 | 说明 |
|------|------|
| ack = N | "我已经收到了 **N-1 及之前**的所有字节" |
| ack = expected next byte | 期望对方下一个收到的字节序号 |
| ACK = 0 的情况 | 仅在 SYN/FIN 阶段出现（它们不占序列号空间）|

### SACK（Selective Acknowledgment）

标准 TCP 只能确认"前面的所有字节都到了"，SACK 允许接收方告诉发送方"**哪些乱序的块我也收到了**"：

```
正常 ACK:           SACK:
────────            ────────
收齐了 [0,49]       收到: [0,49] [100,149] [200,249]
ack=50              缺:   [50,99]  [150,199]
                      ↑
                  只重传缺的!
```

```bash
$ sysctl net.ipv4.tcp_sack
net.ipv4.tcp_sack = 1  # Linux 默认开启
```

## 超时重传（RTO - Retransmission Timeout）

### RTO 计算（Jacobson/Karels 算法）

```
RTT_sample = T_arrival - T_sent          // 本次往返时间
rtt_variance = (1 - β) * rtt_variance + β * |RTT_sample - RTT_avg|
                                           β = 1/4
RTO = RTT_avg + 4 * rtt_variance
                           α = 3/4

初始 RTO: 至少 1 秒 (RFC 6298)
最大 RTO: 60 秒
```

### 快速重传（Fast Retransmit）

如果收到**3 个重复 ACK**（duplicate ACK），说明某个包很可能丢了——不等 RTO 过期立即重传：

```mermaid
flowchart LR
    A["Segment 1 → recv ✅"] --> B["Segment 2 → recv ✅"]
    B --> C["Segment 3 → LOST ❌"]
    C --> D["DupACK for seg 2 ×3"]
    D -->|"触发快速重传"| E["Re-send Segment 3 immediately ✅"]
    
    style C fill:#FF6B6B,color:#fff
    style E fill:#98FB98,color:#000
```

```
传统 RTO 重传 vs 快速重传:
─────────────────────────
传统: 丢包 → 等 RTO(≥1s) → 重传 → 再等一个 RTT → 共 ≥ 2s
快速: 丢包 → 收到3个dup ACK(~1个RTT) → 立即重传 → 共 ~1 RTT
```

## Go 中的 TCP KeepAlive

```go
import "golang.org/x/sys/unix"

// 设置 TCP keepalive (Go stdlib 1.11+)
ln, _ := net.Listen("tcp", ":8080")
conn, _ := ln.Accept()

if tc, ok := conn.(*net.TCPConn); ok {
    // 每 30s 发送一次 keepalive probe
    tc.SetKeepAlive(true)
    tc.SetKeepAlivePeriod(30 * time.Second)
    
    // 最多重试 3 次 (内核参数 net.ipv4.tcp_keepalive_probes)
    // 总超时 = 30s * 3 = 90s
}
```

```bash
# Linux 内核默认值
$ sysctl net.ipv4.tcp_keepalive_time      # 首次探测前的空闲时间
net.ipv4.tcp_keepalive_time = 7200  # 2小时！
$ sysctl net.ipv4.tcp_keepalive_intvl     # 两次探测间隔
net.ipv4.tcp_keepalive_intvl = 75       # 75秒
$ sysctl net.ipv4.tcp_keepalive_probes    # 最多探测次数
net.ipv4.tcp_keepalive_probes = 9        # 9次
```

> [!tip] 为什么 Go http.Server 默认没有 keepalive？
> `http.Transport` 的 IdleConnTimeout 默认是 90s，但底层的底层 keepalive 由操作系统控制。高并发服务通常需要手动调小 `SetKeepAlivePeriod()` 和内核参数。

## 紧急数据（URG）

```
[普通数据] [URG flag set] [+1 urgent data byte] [普通数据]
                              ^^^^
                        "请立刻处理这个字节!"
```

紧急指针指向 URG 标志后的那个字节。但由于许多应用忽略 URG 功能（Nagle 算法可能与 URG 冲突），现代实践中极少使用。

## 粘包与拆包的根因

> ⚠️ 注意：这个问题虽然在本节讨论，但它其实是应用层协议的设计问题，详见 [[hhs/NETWORK/TCP粘包与拆包]]

### 为什么会粘包？

```
发送端 write("HELLO") → TCP 缓冲 → 合并成一个段 "HELLOWORLD" → 接收端 read() 拿到一整串
发送端 write("WORLD") → 因为 Nagle 算法延迟发送，合并了上一段
```

### 为什么会拆包？

```
发送端 write("HELLO WORLD THIS IS LONG") → 超过 MSS → TCP 自动分片
接收端 read(5) → 只读到 "HELLO" → 剩下在缓冲区等待下次 read()
```

## 关联笔记

- [[hhs/NETWORK/TCP粘包与拆包]] — 应用层解决方案详解
- [[hhs/NETWORK/TCP拥塞控制]] — 重传与拥塞窗口联动
- [[hhs/NETWORK/TCP流量控制]] — 滑动窗口管理