Socket 编程与连接管理深度：状态机、超时、长连接、心跳与连接池

服务端常用调用（顺序）：
  socket()  创建套接字（指定协议族、类型、协议）
  bind()    绑定本地地址与端口
  listen()  进入监听（backlog 指定等待队列上限）
  accept()  从队列取出一个已建立的连接（阻塞直到有连接）

客户端常用调用：
  socket() → connect()（发起 SYN 建立连接）
  close() / shutdown()（断开连接）

数据收发：
  send() / recv()（阻塞或非阻塞）
  write() / read()（系统调用的封装）
  sendfile() / epoll 配合 → 零拷贝提升吞吐

建立连接（三次握手）：
  客户端：CLOSED → SYN_SENT →（收到 SYN+ACK）→ ESTABLISHED
  服务端：CLOSED → LISTEN → SYN_RCVD → ESTABLISHED

正常关闭（四次挥手）：
  主动方：ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED
  被动方：ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED

关键状态的异常含义：
  TIME_WAIT：主动关闭方等待 2×MSL（约 60s），防旧报文串扰
  CLOSE_WAIT：对端已发 FIN，本地却未 close() ← 泄漏根源
  SYN_RCVD：半连接（SYN 队列积压，常因 accept 太慢）
  LAST_ACK 积压：对端迟迟不响应 FIN_ACK

# 一眼看清当前连接状态分布
ss -s
# 按状态计数（看 CLOSE_WAIT / TIME_WAIT 是否异常多）
ss -tan | awk '{print $1}' | sort | uniq -c | sort -nr
# 单独查看某一状态
ss -tan state CLOSE-WAIT
ss -tan state TIME-WAIT | wc -l

1. 阻塞 IO（BIO）
   线程调用 recv 后挂起等数据，线程被占用
   高并发 → 一个线程一个连接，线程数爆炸

2. 非阻塞 IO（NIO）
   调用立即返回，无数据则返回 EAGAIN，应用轮询
   轮询浪费 CPU，需配合事件通知机制

3. 多路复用（Reactor）
   用一个线程监视大量 fd 的就绪事件（select/poll/epoll）
   就绪后才真正读写，是 Netty/Java NIO 的基础
   epoll：Linux 高并发首选（水平 + 边缘触发）

4. 异步 IO（AIO）
   内核完成数据后回调，应用完全非阻塞
   Linux 原生 AIO 支持有限，io_uring 是新一代尝试

// Reactor / epoll 概念：监听就绪事件，再分发处理
// Netty 的 EventLoop、Java NIO Selector 都是这个模型
// Go 的 net 包把 epoll 封装成"阻塞式写法 + 非阻塞内核"
server, _ := net.Listen("tcp", ":8080")
for {
    conn, err := server.Accept()   // 内核就绪才返回
    go handleConn(conn)            // 每个连接一个 goroutine
}

1. 连接超时（connectTimeout）：
   客户端发 SYN 后等待的最长时间，超时即放弃
   过大 → 对端假死时请求长时间卡住；过小 → 网络抖动误报

2. 读超时（socketTimeout / readTimeout）：
   等待对端数据的最大空闲时间
   用于识别"对端不再发数据"的假死连接

3. 写超时（writeTimeout）：
   对端接收缓冲区打满后，写操作阻塞的最长时间

4. TCP keepalive：
   操作系统内置探测，默认间隔 2 小时，偏保守
   用于回收内核层已断的僵尸连接，非业务级心跳

// Java Socket 超时 —— 语义与语言无关
Socket socket = new Socket();
socket.connect(new InetSocketAddress(host, port), 3000); // 连接超时 3s
socket.setSoTimeout(5000);        // 读超时 5s：recv 最多等 5s
socket.setTcpNoDelay(true);       // 禁用 Nagle，降低小包延迟
socket.setKeepAlive(true);        // 开启内核 keepalive（默认偏保守）

SO_SNDBUF / SO_RCVBUF：应用可调节的内核收发缓冲区
调大：提升大吞吐（高 BDP），但增加内存占用
调小：降低延迟、减少缓冲，适合小包高频场景

两个边界：
  - 对端消费慢但本地发送快 → send buf 打满 → 写侧阻塞/超时
  - 本地忙但对端狂发 → recv buf 满 → 对端最终阻塞
  → 压不住的本质是双方消费速度不匹配，需从应用层解

短连接的痛：
  - 每次都要三次握手（+ TLS 握手），频繁建立与释放
  - RTT 翻倍、CPU 耗在握手、端口快速耗尽（TIME_WAIT）
长连接的意义：
  - 复用已建立的 TCP 连接，省握手，吞吐高、延迟低
  - 适用：API 高频调用、消息推送、数据库连接、gRPC

两类落地方式：
  方案1：HTTP 连接池（keep-alive + 空闲复用）
       —— 高层协议自带连接复用，框架维护
  方案2：自定义长连接 + 心跳 + 可靠重连
       —— 长连接服务（IM/推送/游戏）自己管理

一个健康长连接应有的能力：
  建立：连接池预热（预热 + 懒建结合）
  复用：请求-响应多路复用（HTTP/2、gRPC）或排队共享
  监控：统计可用连接数、闲置数、失败数
  收回：空闲超时回收，池不无限膨胀
  重连：故障自动剔除 + 指数退避重建（防止重连风暴）

方式1：应用层 Ping/Pong（最常见）
  客户端定时发 Ping → 服务端回 Pong
  若超时未收到 Pong → 判定假死 → 发起重连

方式2：业务自增序列（数据库/消息类）
  客户端发 seq → 服务端回 seq + 结果
  既是心跳也是业务探活，一举两得

心跳间隔（关键权衡）：
  太短 → 垃圾包费带宽费 CPU
  太长 → 对端真挂了要很久才发现
  经验值：5~30s，读超时配成心跳间隔的 2~3 倍

兜底原则：
  心跳超时 = 2~3 × 心跳间隔
  读超时 ≥ 心跳超时，避免误杀慢业务

核心指标：
  MaxConn       最大连接数（防爆端口/资源）
  MinIdle       最小空闲数（保持池温）
  MaxIdleTime   空闲回收（防僵死连接堆积）
  MaxLifeTime   最长生命周期（回收底层已断的伪活连接）

获取连接流程：
  1. 从池中借一个空闲连接
  2. 校验（ping/轻量探活）→ 失效则销毁重建
  3. 用完归还到池
  4. 池满则排队等待（带等待超时）

// Go http 客户端连接池配置示例
client := &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        100,                 // 全局空闲连接上限
        MaxIdleConnsPerHost: 20,                  // 每 Host 的空闲上限
        IdleConnTimeout:     90 * time.Second,    // 空闲回收时间
        DialContext: (&net.Dialer{
            Timeout:   3 * time.Second,           // 连接超时
            KeepAlive: 30 * time.Second,          // TCP keepalive
        }).DialContext,
        ForceAttemptHTTP2: true,
    },
}

□ 所有网络调用都设 connect / read / write 三类超时
□ 业务层做心跳（5~30s）+ 读超时双重兜底
□ 高频服务用连接池，PerHost、MaxLifeTime 显式配置
□ 监控 CLOSE_WAIT / TIME_WAIT / LAST_ACK 状态分布
□ 长连接设计好空闲回收 + 指数退避重连
□ 校验连接健康再借出，避免使用已死连接
□ 优雅停机：先 shutdown 处理在途数据，再 close
□ 用 epoll/协程模型扛高并发，别一连接一线程

socket 用超时管假死、用心跳护长连接、用连接池控制资源，
CLOSE_WAIT 泄漏、TIME_WAIT 爆炸，两个状态一眼看出问题。