应用调用 read(fd, buf, len)
    |
    | 【阶段一】等待数据就绪
    |   网络数据还在路上，或者只到了半个包，
    |   内核要等到 socket 接收缓冲区里有数据可读
    |   <- 这个阶段可能等几微秒，也可能等几分钟
    v
    | 【阶段二】把数据从内核拷贝到用户空间
    |   数据已经在内核的 socket 缓冲区里了，
    |   copy_to_user() 把它搬到你的 buf
    |   <- 这个阶段很快，纯内存拷贝，微秒级
    v
read 返回

// 最直白的写法
int n = read(fd, buf, sizeof(buf));   // 一直等，直到有数据
process(buf, n);

1 万个线程的代价：
  内存：1万 × 8MB 默认栈 = 80GB 虚拟内存（实际 RSS 小得多，但仍可观）
  调度：1万个可运行任务，CFS 调度周期被拉长（第 7 篇）
  切换：上下文切换开销急剧上升，cs 可能到几十万/s

// 设为非阻塞
int flags = fcntl(fd, F_GETFL, 0);
fcntl(fd, F_SETFL, flags | O_NONBLOCK);

// 轮询
while (1) {
    int n = read(fd, buf, sizeof(buf));
    if (n > 0) {
        process(buf, n);
        break;
    }
    if (n < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) {
        // 数据还没来，可以去干别的事
        do_something_else();
        continue;          // <- 但如果什么都不干就是【忙等】，白烧 CPU
    }
    if (n < 0) { /* 真的出错了 */ break; }
}

// 伪代码：经典的事件循环
while (1) {
    int n = epoll_wait(epfd, events, MAX_EVENTS, -1);   // 阻塞在这里
    for (int i = 0; i < n; i++) {
        int fd = events[i].data.fd;
        if (events[i].events & EPOLLIN) {
            read(fd, buf, sizeof(buf));      // 数据已就绪，读不会阻塞
            process(buf);
        }
    }
}

阻塞 IO：            1 个线程阻塞在 1 个 fd 上   -> 需要 N 个线程处理 N 个连接
IO 多路复用：        1 个线程阻塞在 N 个 fd 上   -> 1 个线程处理 N 个连接

signal(SIGIO, sigio_handler);
fcntl(fd, F_SETOWN, getpid());
int flags = fcntl(fd, F_GETFL);
fcntl(fd, F_SETFL, flags | O_ASYNC);

应用调用 aio_read() -> 立刻返回，进程去做别的事
                      v
                 内核等数据就绪
                      v
                 内核把数据拷贝到用户提供的 buf   <- 关键：内核代劳了
                      v
                 内核发信号 / 调回调，通知「数据已经在你的 buf 里了」

POSIX 定义：
  同步 IO：IO 操作会导致请求进程被阻塞，直到该 IO 操作完成
  异步 IO：IO 操作不会导致请求进程被阻塞

按这个定义：
  阻塞 IO       阶段二阻塞  -> 同步
  非阻塞 IO     阶段二阻塞  -> 同步   <- 名字叫「非阻塞」但它是同步的！
  IO 多路复用   阶段二阻塞  -> 同步
  信号驱动 IO   阶段二阻塞  -> 同步
  异步 IO       阶段二不阻塞 -> 异步

组合：
  同步阻塞     = 阻塞 IO
  同步非阻塞   = 非阻塞 IO、IO 多路复用
  异步非阻塞   = 真正的异步 IO（AIO、io_uring）
  异步阻塞     = 【不存在】异步的前提就是不阻塞

int select(int nfds, fd_set *readfds, fd_set *writefds,
           fd_set *exceptfds, struct timeval *timeout);

// 典型用法
fd_set readfds;
while (1) {
    FD_ZERO(&readfds);
    for (int i = 0; i < n; i++) FD_SET(fds[i], &readfds);   // ① 每次都要重新填
    
    select(maxfd + 1, &readfds, NULL, NULL, NULL);
    
    for (int i = 0; i < n; i++) {                            // ② 每次都要全部遍历
        if (FD_ISSET(fds[i], &readfds)) {
            read(fds[i], buf, sizeof(buf));
        }
    }
}

int poll(struct pollfd *fds, unsigned int nfds, int timeout);

struct pollfd {
    int   fd;         /* 要监听的 fd */
    short events;     /* 关心的事件（入参） */
    short revents;    /* 实际发生的事件（出参）<- 与 events 分开了 */
};

int epoll_create1(int flags);                                     // 创建 epoll 实例
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *ev);   // 增删改 fd
int epoll_wait(int epfd, struct epoll_event *events,
               int maxevents, int timeout);                        // 等待就绪

// 简化的 eventpoll 结构（内核 fs/eventpoll.c）
struct eventpoll {
    struct rb_root_cached rbr;      // 红黑树：存放【所有】被监听的 fd
    struct list_head      rdllist;  // 双向链表：存放【已就绪】的 fd
    wait_queue_head_t     wq;       // 等待队列：阻塞在 epoll_wait 的进程
};

       红黑树 rbr                     就绪链表 rdllist
   （所有监听的 fd，10 万个）        （已就绪的 fd，可能只有几百个）
   
        ●                                 +---+---+---+
      ／   ＼                              |fd3|fd7|fd9|
    ●       ●          网卡数据到达 ------>+---+---+---+
   ／＼     ／＼         回调把 fd 挂进来           ^
  ●  ●    ●   ●                          epoll_wait 只看这个链表

① epoll_ctl(EPOLL_CTL_ADD)
   把 fd 插入红黑树（O(log n)），并给这个 fd 注册一个【回调函数】ep_poll_callback
   
② 网卡收到数据 -> 协议栈处理完 -> 唤醒等待队列
   -> 触发 ep_poll_callback
   -> 回调把这个 fd 直接【挂进就绪链表 rdllist】
   
③ epoll_wait 只需要检查 rdllist 空不空
   非空 -> 把就绪的 fd 拷给用户，返回个数
   空   -> 进程睡眠，等回调唤醒

10 万个长连接，同一时刻只有 500 个在传数据：
  select/poll：每次要检查 10 万个 fd          -> O(100000)
  epoll：      只处理就绪链表里的 500 个       -> O(500)

连接数少（< 100）且几乎全部活跃  -> select/poll 可能更快
                                    （epoll 有 epoll_ctl 的额外系统调用开销）
连接数多、活跃比例低              -> epoll 碾压
需要跨平台                        -> 用 libevent/libuv 封装，
                                    它们在 Linux 用 epoll，BSD 用 kqueue，
                                    Windows 用 IOCP

LT（Level Triggered，水平触发）—— 默认模式
  只要 fd 上还有数据可读，【每次】epoll_wait 都会返回它
  
ET（Edge Triggered，边缘触发）
  只在 fd 状态【从不可读变为可读】的那一刻通知一次
  之后即使数据没读完，也不再通知

场景：socket 缓冲区收到 1000 字节，应用每次只 read 100 字节

LT 模式：
  epoll_wait 返回 -> read 100 字节（还剩 900）
  epoll_wait 返回 -> read 100 字节（还剩 800）    <- 继续通知
  ...一直通知到读完
  
ET 模式：
  epoll_wait 返回 -> read 100 字节（还剩 900）
  epoll_wait 阻塞  <- 【不再通知！剩下 900 字节永远读不到】
  除非又有【新数据】到达，状态再次「变化」，才会通知

// ✅ ET 模式的正确写法：循环读到 EAGAIN
while (1) {
    ssize_t n = read(fd, buf, sizeof(buf));
    if (n > 0) {
        process(buf, n);
        continue;                       // 继续读
    }
    if (n == 0) {                       // 对端关闭
        close(fd);
        break;
    }
    if (n < 0) {
        if (errno == EAGAIN || errno == EWOULDBLOCK) {
            break;                      // ✅ 读干了，正常退出
        }
        if (errno == EINTR) continue;   // 被信号打断，重试
        close(fd);                      // 真的出错
        break;
    }
}

如果 ET 模式用了【阻塞】fd：
  循环 read 直到读干 -> 最后一次 read 时缓冲区已空
  -> 阻塞 fd 的 read 会【挂住】，等待新数据
  -> 整个事件循环卡死，其他所有连接都得不到处理
  
用【非阻塞】fd：
  最后一次 read 立即返回 EAGAIN -> 正常退出循环 -> 继续处理其他 fd  ✅

① accept 惊群
   多个进程 accept 同一个 listen fd
   -> Linux 2.6 起内核已经解决：只唤醒一个进程
   
② epoll 惊群
   多个进程把【同一个 listen fd】加进各自的 epoll
   -> 新连接到来时，内核会唤醒【所有】阻塞在这个 fd 上的进程
   -> nginx 面对的是这一种

events {
    accept_mutex on;      # 老版本默认 on，1.11.3+ 默认 off
}

ev.events = EPOLLIN | EPOLLEXCLUSIVE;
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);

int opt = 1;
setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &opt, sizeof(opt));
bind(fd, ...);       // 多个进程可以 bind 同一个端口
listen(fd, backlog);

不用 SO_REUSEPORT：              用 SO_REUSEPORT：
   一个 listen fd                   worker1 -> listen fd 1 -> 独立队列 1
   v 所有 worker 抢                 worker2 -> listen fd 2 -> 独立队列 2
 w1 w2 w3 都被唤醒                  worker3 -> listen fd 3 -> 独立队列 3
   v                                内核按【四元组 hash】直接投递
 只有一个 accept 成功                零竞争，零惊群，负载天然均衡

# nginx 里开启
http {
    server {
        listen 80 reuseport;      # <- 加这个
    }
}

      用户态                        内核态
  +------------------+        +------------------+
  |  提交队列 SQ     |        |  内核读取并处理  |
  |  （写入请求）    | <----> |                  |
  +------------------+        +------------------+
          ^                            ^
          +--------- 共享内存 ---------+
  +------------------+        +------------------+
  |  完成队列 CQ     |        |  内核写入结果    |
  |  （读取结果）    | <----> |                  |
  +------------------+        +------------------+

批量提交：把 N 个请求写进 SQ，一次 io_uring_enter() 全部提交
轮询模式：SQPOLL 下内核线程主动轮询 SQ，【连这一次系统调用都不需要】

// 你写的代码看起来是阻塞的
func handle(conn net.Conn) {
    buf := make([]byte, 4096)
    n, err := conn.Read(buf)      // 看起来会阻塞
    // ...
}

// 每个连接一个 goroutine，写法极简
for {
    conn, _ := listener.Accept()
    go handle(conn)
}

conn.Read() 
    v
runtime 把 fd 设为【非阻塞】，调用 read()
    v
返回 EAGAIN（没数据）
    v
runtime 把这个 goroutine 挂到 netpoller 的等待列表，标记为 Gwaiting
    v
【调度器把 M（OS 线程）分配给其他 goroutine】<- 关键：线程没有被阻塞
    v
调度循环中定期调用 netpoll() -> 底层就是 epoll_wait
    v
fd 就绪 -> 找到对应的 goroutine -> 标记为 Grunnable，放回运行队列
    v
goroutine 被调度，conn.Read() 从内核视角「返回」了

cat /proc/$(pgrep gateway)/limits | grep -i "open files"
# Max open files            1048576   1048576   files     <- 不是这个问题

ls /proc/$(pgrep gateway)/fd | wc -l
# 28134                                                   <- 卡在这个数

ss -lnt
# State  Recv-Q Send-Q Local Address:Port
# LISTEN  512    511         0.0.0.0:8080
#         ^^^^^^ Recv-Q = 当前 accept 队列里堆积的连接数
#                ^^^^^^ Send-Q = 队列容量（backlog）
#         队列已经满了！

# 确认溢出计数在增长
nstat -az | grep -iE "ListenOverflows|ListenDrops"
# TcpExtListenOverflows           89234      0.0
# TcpExtListenDrops               89234      0.0
#                                 ^^^^^ 8.9 万次溢出 -> 大量连接被内核直接丢弃

cat /proc/sys/net/core/somaxconn
# 4096                    <- 系统限制是 4096，不是 511

# 那 511 是哪来的？是应用自己设的
# Go 的 net.Listen 默认用 somaxconn，但这个服务显式设了 backlog

# ① 内核：加大 accept 队列上限和半连接队列
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sysctl -w net.core.netdev_max_backlog=32768

# 持久化
cat >> /etc/sysctl.d/99-network.conf <<'EOF'
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 32768
EOF
sysctl --system

// ② 应用：不要自己设小 backlog，让它用 somaxconn
// ❌ 原来的代码
lc := net.ListenConfig{}   // 某些框架会硬编码 backlog=511

// ✅ 用默认值（Go 会读 /proc/sys/net/core/somaxconn）
ln, err := net.Listen("tcp", ":8080")

// ③ 关键：accept 循环里不要做任何耗时操作
for {
    conn, err := ln.Accept()
    if err != nil {
        continue
    }
    go handle(conn)        // ✅ 立刻交给 goroutine，accept 循环保持空转
    // ❌ 不要在这里做 TLS 握手、鉴权、日志等任何阻塞操作
}

ss -lnt
# State  Recv-Q Send-Q Local Address:Port
# LISTEN  0      65535       0.0.0.0:8080
#         ^ 队列不再堆积           ^^^^^ backlog 生效

nstat -az | grep ListenOverflows
# TcpExtListenOverflows           0          0.0     <- 归零

# 连接数
ls /proc/$(pgrep gateway)/fd | wc -l
# 98234                                              <- 突破了