反向代理核心逻辑用 socket + select/epoll/kqueue 实现 i/o 多路复用，透传 tcp 字节流而非解析 http；需循环处理 send/recv 并管理发送队列以避免粘包和写入阻塞。
反向代理核心逻辑用什么实现？
用 socket + select 或 epoll（Linux）/ kqueue（macOS）做 I/O 多路复用，而不是轮询或阻塞式 accept+recv。否则并发一高就卡死。
关键不是“转发 HTTP”，而是“透传 TCP 流”——绝大多数简单反向代理只需字节流搬运，不解析 HTTP 头。解析反而引入复杂性和兼容性问题（比如分块传输、HTTP/2、CONNECT 隧道）。
- 监听一个本地端口（如
8080），accept客户端连接 - 同时
connect到上游服务（如127.0.0.1:3000） - 用
select监听两端 socket 的可读事件，双向read/write - 任一端断开（
read返回 0 或 -1），就关闭对应连接并退出该代理会话
如何避免粘包和写入阻塞？
send 不保证一次发完；recv 可能只读到部分数据；TCP 是流式协议，没有消息边界。直接 send(buf, len) 后不管返回值，大概率丢数据。
必须循环处理：
- 对每个
recv到的字节数，调用send并检查返回值；若send返回-1且errno == EAGAIN或EWOULDBLOCK，说明内核发送缓冲区满，需等待可写事件再重试 - 若
send返回值小于请求长度，需保存剩余数据，下次继续发（即实现“发送队列”） - 不要用
MSG_WAITALL：它只对recv有效，且在非阻塞 socket 下会直接失败
示例片段（简化）：
ssize_t sent = send(dst_fd, buf, len, MSG_NOSIGNAL);
if (sent == -1) {
if (errno == EAGAIN || errno == EWOULDBLOCK) return; // 等下次可写
else close_conn(); // 真错误
} else if (sent <h3>为什么不能直接 fork 或 std::thread 每连接一个线程？</h3><p>Linux 默认每个进程最多打开 1024 文件描述符，一个连接至少占 2 个 fd（client + upstream），100 并发就逼近上限。线程栈默认 8MB，100 线程光栈就吃掉 800MB 内存。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill5502" title="C++ Code Review Master"><img
src="https://img.php.cn/upload/skill/000/000/081/179051228971575.jpg" alt="C++ Code Review Master" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill5502" title="C++ Code Review Master" class="overflowclass">C++ Code Review Master</a>
<p class="overflowclass">组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。</p>
</div>
<a rel="nofollow" href="/xiazai/skill5502" title="C++ Code Review Master" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><p>更现实的选择是：</p>
- 单线程 +
epoll（推荐初学）：一个 loop 管理所有连接，无锁、内存开销小 - 线程池 +
epoll：把事件分发给固定数量 worker，避免单核瓶颈 - 完全避开系统调用封装：用
libevent或libuv，但会引入外部依赖
注意：std::thread 创建开销大，且 C++ 标准库没提供跨平台的高效 I/O 多路复用封装——别指望 std::async 或 std::jthread 解决这个问题。
上游连接失败时怎么反馈给客户端？
如果 connect 上游超时或拒绝（Connection refused），不能静默断开。客户端会卡在等待响应，浏览器显示“连接已重置”或“ERR_EMPTY_RESPONSE”。
- 必须主动
send一个合法 HTTP 错误响应，例如：
const char* err_resp = "HTTP/1.1 502 Bad Gateway\r\nConnection: close\r\n\r\n"; send(client_fd, err_resp, strlen(err_resp), MSG_NOSIGNAL);
注意两点：
- 响应必须以
\r\n\r\n结尾，否则客户端无法识别 body 终止 - 务必加
Connection: close，防止客户端复用连接并持续等待 - 不要尝试重试或换上游——简单代理不维护健康检查，失败就是失败
真实场景里，这个 502 响应体甚至可以空着，只要状态行和头正确，浏览器就能显示友好的错误页。
真正麻烦的是 TLS 透传（HTTPS 反代）、WebSocket 升级、HTTP/2 多路复用——这些不是“简单”范畴，需要协议感知，别从零手撸。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
