网络编程模型

#网络 · #Socket · #epoll · #C10K · #事件驱动 · #Reactor

网络编程远不止 socket()/connect()/send()/recv()。从 C10K 到 C10M，从单线程阻塞到事件驱动，再到异步 I/O，网络编程模型的演进就是互联网基础设施的演进史。

---

1. Socket 基础

1.1 TCP Socket 完整流程

sequenceDiagram
    participant Server
    participant Client

    Server->>Server: socket() 创建套接字
    Server->>Server: bind() 绑定端口
    Server->>Server: listen() 开始监听
    Server->>Server: accept() 阻塞等待连接

    Client->>Client: socket() 创建套接字
    Client->>Server: connect() 发起连接
    Server->>Server: accept() 返回新 fd
    Server->>Client: ESTABLISHED

    Client->>Server: send() / write()
    Server->>Client: recv() / read()

    Client->>Server: close()
    Server->>Server: close()

1.2 关键 API

API	功能	关键参数
socket()	创建套接字	AF_INET, SOCK_STREAM, 0
bind()	绑定端口	sockaddr_in 含 IP + Port
listen()	转被动套接字	backlog（全连接队列大小）
accept()	接受连接	返回新的 fd
connect()	发起连接	目标 IP + Port
send()/recv()	数据传输	flags (MSG_DONTWAIT etc.)
close()	关闭连接	—
shutdown()	半关闭	SHUT_RD / SHUT_WR / SHUT_RDWR

fd 是连接的入口，也是最容易被耗尽的资源：

listen fd: 服务端监听端口，只负责 accept
conn fd:   accept/connect 返回的新连接，每条 TCP 连接至少占一个 fd

一个代理通常至少有两类 conn fd：
  client → proxy 的上游 fd
  proxy → backend 的下游 fd

因此 1 个请求链路可能占用 2 个甚至更多 fd。

资源	说明	泄漏后果
fd 表项	进程打开文件表，受 ulimit -n 限制	too many open files，无法 accept/connect/open 文件
socket buffer	内核收发缓冲区	内存增长，影响全机网络栈
goroutine/thread	等待读写或业务处理	调度开销、栈内存、上下文切换增加
业务对象	请求上下文、连接池对象、buffer	应用内存泄漏或 GC 压力增大

1.3 网络字节序

大端（Big Endian）：高位字节在低地址 → 网络字节序
小端（Little Endian）：低位字节在低地址 → x86/ARM 主机字节序

转换函数：
htonl()  /  ntohl()    : 32 位
htons()  /  ntohs()    : 16 位

1.4 简易 TCP Echo 服务（Go）

package main

import (
    "bufio"
    "fmt"
    "net"
)

func main() {
    ln, err := net.Listen("tcp", ":8080")
    if err != nil {
        panic(err)
    }
    for {
        conn, err := ln.Accept()
        if err != nil {
            continue
        }
        go handle(conn)  // 每个连接一个 goroutine
    }
}

func handle(conn net.Conn) {
    defer conn.Close()
    scanner := bufio.NewScanner(conn)
    for scanner.Scan() {
        fmt.Fprintln(conn, "echo:", scanner.Text())
    }
}

生产代码不能只依赖 defer Close()。还需要设置超时，避免对端不读、不写、半开时 goroutine 永久卡住：

func handle(conn net.Conn) {
    defer conn.Close()
    _ = conn.SetDeadline(time.Now().Add(30 * time.Second))

    scanner := bufio.NewScanner(conn)
    for scanner.Scan() {
        _ = conn.SetDeadline(time.Now().Add(30 * time.Second))
        fmt.Fprintln(conn, "echo:", scanner.Text())
    }
}

对长连接服务，通常不要设置一次性的固定 deadline，而是每次成功读写后刷新 deadline，或者用应用层心跳维护连接活性。

1.5 代理双向连接：为什么下游堵住会拖垮上游

代理不是简单的一个 socket，而是一组连接生命周期的组合：

flowchart LR
    C["Client"] <-->|"上游连接 fd1"| P["Proxy"] <-->|"下游连接 fd2"| M["MySQL / Upstream"]

    P --> CP["连接池"]
    P --> TP["业务 goroutine/thread"]
    P --> BUF["请求/响应 buffer"]

危险场景：下游 MySQL 堵住

1. Client 请求持续进入 Proxy
2. Proxy 从下游连接池拿 MySQL 连接
3. MySQL 慢查询、锁等待、线程池满，或者网络半断
4. Proxy 的读写 goroutine 卡在 read/write/query
5. 上游 client 连接没有及时响应，也不释放
6. 下游连接异常关闭后，Proxy 错误分支漏 close → CLOSE_WAIT
7. fd 数持续上涨，最终超过 ulimit -n
8. Proxy 无法 accept 新连接，也无法 connect MySQL

这个问题的关键不是“调大 fd 上限”。调大 ulimit -n 只能延后雪崩，不能解决连接生命周期泄漏和下游背压缺失。

防护点	代码/配置要求
上游读超时	client 不发完整请求时及时断开
下游连接超时	connect timeout、read timeout、write timeout 必须分开配置
请求总超时	一次代理请求必须有 deadline/context cancellation
错误分支 close	任意中途失败都要释放上下游 fd
连接池上限	max open 限制保护下游，等待队列不能无限增长
背压/熔断	下游慢时快速失败，避免把 proxy 自己拖死
fd 监控	监控 /proc/<pid>/fd、process_open_fds、各 TCP 状态

---

2. C10K 问题

背景：2000 年左右，Web 规模爆发。一台服务器如何同时处理 10,000 个并发连接？

2.1 传统模型为何不行

模型	问题
每连接一线程/进程	10,000 连接 = 10,000 线程 → 上下文切换/内存开销爆炸
select	fd_set 上限 1024，O(n) 轮询
poll	无 fd 上限，但仍是 O(n) 轮询

2.2 解决之道

方案	机制	代表
epoll (Linux)	事件通知，O(1) 就绪事件获取	Nginx, Redis
kqueue (BSD/macOS)	类似 epoll 的事件通知	—
IOCP (Windows)	真正的异步 I/O	IIS
Reactor 模式	事件驱动，单线程处理 I/O	Node.js (libuv)

---

3. epoll 详解

本节聚焦 epoll 在编程模型中的角色与用法。底层原理（内核红黑树 + 就绪链表、完整 I/O 链路从网卡到用户态的性能分析）详见 I/O 模型。

3.1 三个核心 API

int epoll_create1(0);                          // 创建 epoll 实例
int epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev);  // 添加/修改/删除监听的 fd
int epoll_wait(epfd, events, maxevents, timeout); // 等待就绪事件

3.2 epoll 事件触发模式

模式	行为	适用场景
LT (Level Triggered)	只要缓冲区有数据，每次 epoll_wait 都通知	默认模式，安全但可能多通知
ET (Edge Triggered)	只在状态变化时通知一次	高性能，但必须一次读完

// ET 模式下的正确读取方式
while (1) {
    n = read(fd, buf, sizeof(buf));
    if (n < 0) {
        if (errno == EAGAIN || errno == EWOULDBLOCK) break;
        // 真正的错误
    }
    // 处理 buf
}

3.3 epoll 为什么快

flowchart LR
    subgraph SP["select/poll"]
        S1["每次调用传入<br/>完整 fd 数组"]
        S2["内核 O(n) 轮询<br/>所有 fd"]
        S3["返回: 所有 fd<br/>（含未就绪的）"]
        S1 --> S2 --> S3
    end

    subgraph EP["epoll"]
        E1["epoll_ctl 注册一次<br/>存入红黑树"]
        E2["fd 就绪 → 回调<br/>→ 加入就绪链表"]
        E3["epoll_wait O(1)<br/>直接取就绪链表"]
        E1 --> E2 --> E3
    end

epoll 使用红黑树管理所有注册的 fd（O(log n) 增删），用双向链表维护就绪队列（O(1) 获取）。"事件驱动"的核心：内核主动通知"哪个 fd 好了"，而不是应用层反复问"你好了没？"。

---

4. Reactor 与 Proactor

4.1 Reactor（反应器）模式

Reactor 的核心思想：用一个线程（或少量线程）监听多个 fd 的事件，事件到达后分发给 Handler 同步处理 I/O。这不是一个固定的模式，而是有三种常见变体——选择哪种取决于你的"业务处理"是 CPU 密集还是 I/O 密集：

flowchart TB
    subgraph Single["单 Reactor 单线程"]
        S_Reactor["Reactor<br/>(epoll_wait + accept + read + write + 业务)<br/>全在同一个线程"]

        S_Client1["Client 1"]
        S_Client2["Client 2"]

        S_Client1 <--> S_Reactor
        S_Client2 <--> S_Reactor
    end

    subgraph Multi["单 Reactor 多线程"]
        M_Reactor["Reactor<br/>(epoll_wait + accept + read + write)<br/>单个线程"]
        M_TP["Thread Pool<br/>执行业务逻辑"]
        M_Decode["Handler<br/>编解码"]

        M_Reactor -->|"事件分发"| M_Decode
        M_Decode -->|"业务处理"| M_TP
    end

    subgraph MasterSlave["主从 Reactor 多线程"]
        MR["Main Reactor<br/>(accept + 分发连接)"]
        SR1["SubReactor 1<br/>(read/write + 分发事件)"]
        SR2["SubReactor 2<br/>(read/write + 分发事件)"]
        MS_TP["Thread Pool"]

        MR -->|"分配连接"| SR1
        MR -->|"分配连接"| SR2
        SR1 --> MS_TP
        SR2 --> MS_TP
    end

模型	Reactor	业务线程	瓶颈	代表
单 Reactor 单线程	1 个，处理一切	0（Reactor 自己做）	业务逻辑阻塞会卡死所有连接	Redis 6.0 前（纯内存，无阻塞）
单 Reactor 多线程	1 个，处理 I/O	N 个线程池	Reactor 线程可能成为瓶颈	—
主从 Reactor 多线程	1 Main + N SubReactor	M 个线程池	几乎无瓶颈	Netty, Nginx

为什么 Redis 6.0 要引入多线程：Redis 5 之前是经典的单 Reactor 单线程——"纯内存操作极快，单个线程不是瓶颈"这个前提在简单命令上成立，但 DEL bigkey（释放几 GB 内存）和 FLUSHDB 等操作会阻塞事件循环。Redis 6.0 引入的"多线程 I/O"本质上是把 socket read/write 交给了线程池，命令执行仍单线程（保证原子性）。

4.2 Proactor（前摄器）模式

与 Reactor 的关键区别——Reactor 通知你"fd 可读了，去读吧"；Proactor 通知你"我已经读完了，数据在这里，直接用"。

	Reactor	Proactor
I/O 执行者	Handler（用户态）	OS 内核
通知内容	fd 就绪	I/O 完成
需要自己 read/write？	✅ 需要	❌ 不需要，数据已在 buf
Linux 实现	epoll（同步 I/O 多路复用）	io_uring（5.1+）
Windows 实现	select（性能差）	IOCP（原生）
编程复杂度	低（逻辑在线程内）	高（回调/协程）

4.3 主流框架的网络模型归类

框架	模型	说明
Nginx	多进程 + 每进程单 Reactor	master fork 多个 worker，每个 worker 独立 epoll 循环
Redis 6.0+	单 Reactor + I/O 多线程	命令执行单线程，socket read/write 多线程
Netty	主从 Reactor 多线程	bossGroup(accept) + workerGroup(read/write)
Go net/http	每连接一 goroutine	M:N 调度模拟同步，底层 netpoller 异步
Node.js	单线程事件循环 (libuv)	单 Reactor，异步回调/async-await

---

5. Go netpoller

Go 的网络 I/O 使用 netpoller 将异步 I/O 转换为同步阻塞语义：

flowchart TB
    G["goroutine: conn.Read()"] -->|"syscall"| NP["netpoller (epoll/kqueue/IOCP)"]
    NP -->|"fd 未就绪"| PARK["gopark() — goroutine 挂起"]
    NP -->|"fd 就绪"| READY["goready() — goroutine 恢复"]
    READY --> G2["goroutine 继续执行"]

关键设计：

• goroutine 做 conn.Read() 时如果 fd 未就绪，goroutine 被 park
• netpoller 线程等待 epoll（或 kqueue/IOCP）事件
• fd 就绪时，netpoller 唤醒对应的 goroutine
• 从 goroutine 角度看，I/O 是"阻塞"的（同步语义）
• 从系统角度看，线程没有被阻塞（真正的异步 I/O）

这就是为什么 Go 可以用同步代码风格写出高并发网络服务。

SO_REUSEPORT — 多核网络加速

传统 bind() 上，一个端口只能被一个进程/线程监听——即使你用多进程 fork，accept 争抢（惊群效应）也是瓶颈。Linux 3.9 引入的 SO_REUSEPORT 让多个 socket 绑定同一端口，内核负责将连接均匀分发：

flowchart TB
    subgraph Traditional["传统: 单 listen fd"]
        T_Proc["Master 进程<br/>listen fd"]
        T_Worker1["Worker 1<br/>竞争 accept()"]
        T_Worker2["Worker 2<br/>竞争 accept()"]
        T_Worker3["Worker 3<br/>竞争 accept()"]
        T_Proc --> T_Worker1
        T_Proc --> T_Worker2
        T_Proc --> T_Worker3
    end

    subgraph Reuseport["SO_REUSEPORT: 每 worker 独立 listen"]
        R_Kernel["内核<br/>按连接 hash 分发"]
        R_Worker1["Worker 1<br/>独立 listen fd"]
        R_Worker2["Worker 2<br/>独立 listen fd"]
        R_Worker3["Worker 3<br/>独立 listen fd"]
        R_Kernel --> R_Worker1
        R_Kernel --> R_Worker2
        R_Kernel --> R_Worker3
    end

    Traditional -->|"SO_REUSEPORT"| Reuseport

// Go 1.11+ net.ListenConfig 支持 SO_REUSEPORT
import "golang.org/x/sys/unix"

func listenReusePort(network, address string) (net.Listener, error) {
    lc := net.ListenConfig{
        Control: func(network, address string, c syscall.RawConn) error {
            var opErr error
            c.Control(func(fd uintptr) {
                opErr = unix.SetsockoptInt(int(fd), unix.SOL_SOCKET, unix.SO_REUSEPORT, 1)
            })
            return opErr
        },
    }
    return lc.Listen(context.Background(), network, address)
}

// Nginx 配置:
// listen 80 reuseport;
// 每个 worker 进程独立 listen，内核均匀分发连接

效果：在 8 核机器上，Nginx 开启 reuseport 后吞吐可提升 20-40%。Go 中用于多进程部署（如启动 4 个相同进程绑定同一端口），但单进程多 goroutine 用不到这个选项（goroutine 间不是竞争 accept）。

---

6. C10M 问题

C10M = 单机 1000 万并发连接。C10K 方案的瓶颈转移到了内核网络栈。

6.1 内核瓶颈

瓶颈	说明
Socket 缓冲区	每连接默认 ~2×85KB = 170KB，1000 万连接需 1.7TB 内存
中断处理	高 PPS 下中断风暴
内核协议栈开销	sk_buff 分配/释放、协议处理、上下文切换

6.2 解决方案

方案	原理	代表
DPDK	绕过内核，用户态驱动网卡	OVS-DPDK, VPP
XDP/eBPF	在网卡驱动层处理，零拷贝到用户态	Cilium, Katran
RDMA	直接内存访问，绕过 CPU	InfiniBand, RoCE
mTCP / F-Stack	用户态 TCP 栈	F-Stack (基于 DPDK)

---

7. 编程模型选型指南

场景	推荐模型	理由
长连接 + 低延迟	Go goroutine + netpoller	同步语义 + 高并发
静态内容 / 反向代理	Nginx (Reactor)	成熟、高性能、生态好
高 PPS 网络转发	DPDK + 轮询模式	绕过内核，零中断
通用高性能服务	epoll (C) / netty (Java)	工业标准
简单原型 / 低并发	每连接一线程	代码简单，调试容易

选型时还要看失败模式：

模型	优势	典型失败模式	防护重点
每连接一线程	编程简单	线程数爆炸、栈内存爆炸	线程池上限、超时、限流
Reactor	fd 扩展性好	Handler 阻塞会卡住事件循环	业务异步化、慢任务隔离
Go goroutine + netpoller	写法同步、并发成本低	goroutine 泄漏、fd 泄漏、连接池等待堆积	context、deadline、pprof、连接池指标
Proactor / io_uring	I/O 完成通知、系统调用少	编程模型复杂、回调生命周期难管理	buffer 生命周期、取消语义、限流
DPDK/XDP	极致 PPS	绕过内核后可观测性和协议处理复杂	自建监控、CPU 绑核、队列隔离

---

8. 工程实践：socket 真正难的是生命周期、背压和错误路径

8.0 一眼看懂：socket 问题大多卡在资源没收干净

flowchart LR
    A["socket / connect / accept"] --> B["read / write"]
    B --> C["超时 / 取消 / 半关闭"]
    C --> D["close / 回池 / 释放 fd"]
    D --> E["连接数、内存、goroutine 恢复"]

关注点	先看什么	常见误区
生命周期	成功、失败、超时路径是否都 close()	只覆盖 happy path
背压	写不出去时是否排队失控	只关注可读不关注可写
代理场景	上下游 fd 是否成对释放	只修一侧连接
建连变慢	老连接是否退不掉	一上来只调 backlog

8.1 从 socket() 到 close()，每一步都可能把资源留在系统里

socket 编程在线上最难的地方，不是 API 数量，而是连接生命周期很长、分支很多：

• connect 失败要释放 fd
• accept 后业务异常也要释放 fd
• 半关闭、超时、取消、重试都要考虑清楚
• 上下游代理场景下一次请求可能同时占多个 fd

所以 socket 稳定性的核心，不是“收发成功”，而是 任何路径都能正确收尾。

8.2 accept() 慢，经常不只是监听参数问题，而是后面的处理链在拖累前面

如果服务端 accept 得慢，常见根因有：

• 业务线程/Goroutine 被下游调用占住
• 单 Reactor 事件循环被慢 handler 拖住
• fd 数逼近上限，accept 后续处理能力下降
• 短连接太多，建连和销毁成本过高

所以看到 listen 队列积压时，不要只想到调 somaxconn，更要问：

• 为什么现有连接释放这么慢？
• 为什么新连接进来比旧连接走得快？

8.3 半关闭、RST、超时取消，是最容易在错误路径里写漏的地方

线上很多“偶发连接异常”都来自这些细节：

• 一端 shutdown(SHUT_WR) 后，另一端仍按全双工处理
• 超时后业务返回了，但 fd 没及时关
• 为了快速失败直接 RST，结果把未发送完的数据也打断
• 上游取消了请求，下游连接还在继续占用

这类问题的危险在于：

• 平时不明显
• 压力一高就批量爆发
• 表面像网络不稳定
• 实际是应用没有处理好连接语义

8.4 背压如果不显式处理，就会从写路径一路反推到建连阶段

flowchart LR
    A["下游/客户端读取变慢"] --> B["send/write 变慢或返回 EAGAIN"]
    B --> C["应用待发送队列堆积"]
    C --> D["连接占用时长变长"]
    D --> E["fd、goroutine、buffer 持续增加"]
    E --> F["accept/connect 开始抖动"]

这就是为什么很多线上事故看起来是“新连接进不来”，但根因却是老连接写不出去。

8.5 代理最容易把一个下游问题放大成整个系统的问题

在 client -> proxy -> upstream 场景里，一个请求通常至少对应：

• 上游 socket
• 下游 socket
• 一个或多个 buffer
• 一段业务上下文

只要下游慢，代理就可能同时积压：

• 上游等待响应的连接
• 下游未释放的连接
• 内存里的待发送数据
• 线程或 goroutine

因此代理型程序最怕的不是单次失败，而是 失败来得慢、连接退不掉。

8.6 一个典型故障链：client -> proxy -> mysql

sequenceDiagram
    participant C as Client
    participant P as Proxy
    participant M as MySQL

    C->>P: 建连并发请求
    P->>M: 获取连接并转发
    Note over M: 慢 SQL / 锁等待 / 网络半断
    M-->>P: 返回延迟上升
    Note over P: 下游 fd 占用变久，写上游也变慢
    P-->>C: RT 升高 / timeout / reset
    Note over P: 新请求继续进入，fd 与缓冲持续上涨

8.7 常见误判

现象	容易误判为	实际可能是
accept 慢	内核参数太小	业务处理慢、连接释放慢
connect 失败	对端挂了	本机 fd 紧张、端口紧张、背压扩散
reset 多	网络抖动	应用错误路径主动 RST / 超时打断
goroutine 多	Go 调度器问题	连接长期未完成、读写被下游拖住
内存涨	GC 问题	待发送队列和连接上下文堆积

8.8 排障顺序

现象	优先看什么
accept 积压	listen 队列、fd 数、handler 是否阻塞
fd 快满	哪类连接状态最多、是否错误分支漏 close
reset 增多	超时、RST、应用主动关闭时机
内存涨且 RT 高	发送队列、buffer、慢客户端 / 慢下游
代理整体雪崩	下游 RT、连接池等待、背压是否生效

8.9 一个实战原则

socket 层要重点管理的不是“能不能收发”，
而是“连接什么时候该继续、什么时候该等待、什么时候必须尽快释放”。

参考

• The C10K Problem (Dan Kegel)
• Scalable Network Programming
• Go netpoller 源码分析
• epoll(7) man page