反向代理的核心是连接生命周期管理，而非简单转发；难点在于客户端与后端TCP连接的安全配对、同步关闭及半开连接防控，需通过非阻塞I/O、双向shutdown、状态标记与缓冲区精细化控制来实现。
反向代理的核心不是“代理”，而是连接生命周期管理
直接上结论：C++写反向代理，最难的不是 send/recv 转发，而是两个 TCP 连接（客户端→代理、代理→后端）如何安全配对、同步关闭、避免半开连接堆积。很多实现一跑压测就 fd 耗尽或出现 Connection reset by peer，根源都在这里。
关键点在于：不能简单用单线程阻塞读写；不能等一端 close 再关另一端；必须处理 recv 返回 0（对端正常关闭）、-1（错误）、以及 EAGAIN/EWOULDBLOCK（非阻塞模式下无数据）这三种情况。
实操建议：
- 用
epoll（Linux）或kqueue（macOS）做 I/O 多路复用，每个连接设为非阻塞（fcntl(fd, F_SETFL, O_NONBLOCK)） - 为每对连接（client_fd ↔ backend_fd）维护一个结构体，含两个 socket fd、读写缓冲区、状态标志（如
is_client_closed/is_backend_closed） - 关闭逻辑必须双向触发：当任一端
recv返回 0，立刻标记该侧已关闭，并尝试向另一端shutdown(SHUT_WR)（不是close），等对方也读完再真正close - 避免使用
select—— 它在 fd 数量 >1024 时性能陡降，且无法跨平台处理边缘状态
转发缓冲区大小不是越大越好，64KB 是较稳妥的折中值
缓冲区太小（如 4KB）会导致频繁系统调用和小包碎片；太大（如 1MB）则浪费内存、增加延迟、且在突发流量下易触发内核 OOM killer 杀进程。实际测试中，64KB 缓冲区在吞吐与延迟间平衡性最好。
立即学习“C++免费学习笔记（深入）”；
注意：这个值是应用层缓冲，不是 TCP 的 SO_RCVBUF/SO_SNDBUF。后者建议保持系统默认（通常 256KB），除非你明确做了内核调优。
实操建议：
- 为每个方向（client→backend 和 backend→client）独立分配
std::vector<uint8_t> recv_buf{65536}</uint8_t> - 用
recv(fd, buf.data(), buf.size(), MSG_DONTWAIT)读取，检查返回值是否为正数、0 或 -1 - 转发时不要 memcpy 整个缓冲区，用
send(fd, buf.data(), n, MSG_NOSIGNAL)直接发实际读到的字节数n - 如果
send返回-1且errno == EAGAIN，说明对端接收窗口满，需把未发送数据暂存到待写队列，下次 epoll_wait 触发可写事件时再试
后端地址解析和连接失败必须重试 + 限流，否则雪崩从代理开始
常见错误是：代理启动后硬编码后端 IP:Port，connect 失败就直接 close(client_fd) 并 return。结果上游重试风暴打进来，代理反复连不上后端，大量连接卡在 SYN_SENT 或 TIME_WAIT，最终拒绝服务。
真实场景中，后端可能短暂不可达（部署重启、网络抖动），代理要能扛住几秒内的波动。
实操建议：
- 用
getaddrinfo解析域名，支持 IPv4/IPv6 双栈；失败时记录日志但不退出进程 -
connect非阻塞调用后，用epoll_ctl(EPOLL_CTL_ADD)监听该 fd 的可写事件（连接完成或失败都会触发） - 连接失败（
getsockopt(..., SO_ERROR)非零）时，按指数退避重试（如 100ms → 200ms → 400ms），最多 3 次；超时后返回502 Bad Gateway给客户端 - 对同一后端 IP:Port 维护连接失败计数器，5 秒内失败 ≥5 次，则自动熔断 30 秒，期间所有新请求快速失败，避免无效重试
别忽略 SIGPIPE，默认行为会 kill 进程
当代理往已关闭的 socket（比如后端提前断开）调用 send，系统默认发送 SIGPIPE，进程直接终止 —— 这是最隐蔽的崩溃原因，日志里往往只看到 “Killed”。
实操建议：
- 启动时加一句：
signal(SIGPIPE, SIG_IGN)（Linux/macOS 均有效） - 或者更严谨地用
sigprocmask屏蔽，但对简单代理，SIG_IGN足够 - 注意：屏蔽后
send在对端关闭时会返回 -1 且errno == EPIPE，此时应按正常关闭流程处理（标记该侧关闭、触发 shutdown 等） - 不要依赖
MSG_NOSIGNAL作为替代方案 —— 它仅在 Linux 有效，且部分旧内核不支持
真正的难点不在转发逻辑本身，而在于你能否在 client_fd 和 backend_fd 同时处于“正在关闭但尚未彻底断开”的中间态时，依然保证数据不丢、连接不泄漏、错误不扩散。这种状态在高并发短连接场景下高频出现，也是多数开源轻量代理（如 tinyproxy）容易出问题的地方。
