拆开 Hical:一个 HTTP 请求从 socket 字节到路由分发的完整旅程

[Hical] 一个 HTTP 请求在 Hical 里经历了什么?从 socket 字节到路由分发 本专栏文章:拆开 Hical · 第 1 篇 用过 Web 框架的人很多,知道"一个请求怎么从 socket 字节变成 handler 参数"的人很少。大部分框架把这层封装得严严实实,你只要写 app.get("/", handler) 就行。 但这篇文章要干相反的事——把 Hical 的整个请求处理链路扒开看。读完你能回答:请求头为什么零堆分配、响应头怎么一次 async_write 发出去、ReadBufferPool 为什么是请求级 borrow 而不是连接级持有。 1. 大图:一个请求的完整旅程 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 socket 上来了字节 │ ▼ readBuf = ReadBufferPool::acquire() ← 借一块 8KB 缓冲 │ ▼ picohttpparser 解析 → phr_header[64] ← 请求头解析到栈数组 │ ▼ 构造 NativeRequest (string_view) ← 零拷贝,指针指到 readBuf │ ▼ Router::dispatch(req) ──→ handler 协程 ← 你的业务代码 │ ▼ NativeResponse::serializeHeadTo(buf) ← 序列化到栈上 512 字节 │ ▼ async_write(socket, buf) ← 一次异步写 │ ▼ readBuf 还给 ReadBufferPool::return_() ← 归还 8KB 缓冲 下面每一步都拆开讲"为什么这样设计"。 ...

August 10, 2026 · 6 min · 1273 words

Hical v2.6.0 性能优化心得:从 27K 到 159K QPS 的完整旅程

Hical v2.6.0 性能优化心得:从 27K 到 159K QPS 的完整旅程 这篇文章记录了 Hical 从 v2.5.2 到 v2.6.0 的完整性能优化历程。不是罗列"我做了什么改动",而是分享怎么发现问题、怎么思考方案、怎么验证效果——以及那些"看起来应该有用但实际没用"的弯路。希望对做 C++ 高性能服务器开发的同学有参考价值。 目录 Hical v2.6.0 性能优化心得:从 27K 到 159K QPS 的完整旅程 目录 1. 起点:27K QPS,差距 6 倍 2. 第一个教训:不要猜,要量 3. 找对方向:火焰图告诉你真相 4. 三阶段优化路线 5. 阶段一:调度模型重构(27K → 132K) 5.1 SO_REUSEPORT:消除跨线程调度 5.2 连接级 Timer + atomic 时间戳 5.3 结果 6. 阶段二:去 Beast,自研 HTTP/WS 栈(132K → 140K) 6.1 四个 Phase 6.2 零拷贝请求解析 6.3 结果 7. 阶段三:热路径微优化(140K → 159K) 7.1 修复 readBuf 残留数据丢弃(功能 BUG + 性能) 7.2 scatter-gather I/O 替代单 buffer 合并 7.3 其他微优化(含后续延迟分配优化) 7.4 结果 8. 最终火焰图:确认优化到位 9. 走过的弯路 弯路 1:优化不是瓶颈的代码 弯路 2:FixedBuffer 栈缓冲区太大 弯路 3:过早放弃 10. 总结:性能优化的方法论 原则一:Profiling 驱动,不靠直觉 原则二:按占比排序,从大到小 原则三:每步验证,不要积累 原则四:知道何时停手 最终成绩单 1. 起点:27K QPS,差距 6 倍 v2.5.1 的 Hical 在 Docker 环境(Ubuntu 24.04, GCC 14, 4 线程)下跑 Hello World benchmark,wrk 报出 ~27K QPS。 ...

May 11, 2026 · 6 min · 1235 words

Hical v2.6.0:移除 Boost.Beast,自研 HTTP/WebSocket 栈全记录

Hical v2.6.0:移除 Boost.Beast,自研 HTTP/WebSocket 栈全记录 Hical v2.6.0 完成了一次关键架构升级——彻底移除 Boost.Beast 依赖,HTTP 解析/序列化和 WebSocket 全部替换为自研实现。本文从动机、架构设计、关键技术细节、性能数据四个维度,完整记录这次"去 Beast"的工程实践。 目录 Hical v2.6.0:移除 Boost.Beast,自研 HTTP/WebSocket 栈全记录 目录 1. 为什么移除 Boost.Beast 2. 新架构总览 3. 自研 HTTP 解析栈 3.1 picohttpparser:极致轻量的 C 解析器 3.2 零拷贝 NativeRequest 3.3 HeaderMap:L1 友好的头部容器 4. 自研 HTTP 响应序列化 4.1 栈缓冲 + Scatter-Gather I/O 4.2 状态行预计算 5. 自研 WebSocket 栈(RFC 6455) 5.1 帧解析器:WsFrame 5.2 握手协议:WsHandshake 5.3 Permessage-Deflate 压缩 5.4 消息分片重组 5.5 协议安全校验 6. 编译防火墙与工程化 7. 性能对比数据 火焰图逐项对比 QPS 端到端对比 与同类框架对比 8. 迁移影响与 Breaking Changes 对框架使用者 对框架使用者透明的改动 9. 新增依赖 picohttpparser zlib 10. 总结 1. 为什么移除 Boost.Beast Beast 是一个优秀的 HTTP/WebSocket 库,但在 Hical 的高性能场景中,它成了主要瓶颈: ...

May 11, 2026 · 9 min · 1738 words