路由

从零构建现代C++ Web服务器（三）：路由、中间件与 SSL 系列导航：第一篇：设计理念 | 第二篇：协程与内存池 | 第三篇：路由、中间件与SSL（本文） | 第四篇：实战与性能 | 第五篇：Cookie、Session与文件服务 | 第六篇：数据库中间件 前置知识 阅读过本系列前两篇（架构分层、协程基础、PMR 内存池） 了解 HTTP 请求/响应基本结构 了解中间件（Middleware）的概念（如 Express/Koa 的洋葱模型） 目录 1. 路由系统设计 2. 洋葱模型中间件管道 3. 模板化 SSL：编译期零开销 4. WebSocket 集成 5. 组装：HttpServer 门面 6. 总结 1. 路由系统设计 1.1 双策略路由：快速与灵活的平衡 Web 框架的路由系统需要处理两类路径： 静态路由：/api/status、/api/users — 路径固定，可以精确匹配 参数路由：/users/{id}、/posts/{pid}/comments/{cid} — 路径含变量，需要模式匹配 hical 采用双策略设计： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 请求到达: GET /api/users/42 │ ▼ ┌─────────────────────────────┐ │ 1. 静态路由查找 (O(1)) │ │ unordered_map 哈希表 │ │ 查找 {GET, "/api/users/42"} │ │ → 未命中 │ └───────────┬─────────────────┘ │ ▼ ┌─────────────────────────────┐ │ 2. 参数路由匹配 (线性扫描) │ │ 遍历 paramRoutes_: │ │ {GET, "/users/{id}"} │ │ → 匹配！提取 id = "42" │ └───────────┬─────────────────┘ │ ▼ 执行 handler 为什么不统一用 Trie 树？因为绝大多数实际应用中，静态路由占比远大于参数路由。用哈希表处理静态路由是 O(1)，比 Trie 的 O(path_length) 更快。参数路由数量通常很少（几十个），线性扫描完全可以接受。 ...