01再谈 HTTP 协议
为什么需要协议
需要明确的边界
- 开始
- 结束
能够携带信息 - 什么消息
- 消息类型
协议里有什么
状态码
HTTP/1.1、HTTP/2、HTTP/3 演变
2HTTP 框架的设计与实现
分层设计
高内聚 易复用 低耦合
应用层需求
- 冗余性
- 兼容性
- 可测性
- 可见性 做到可理解，文档说明作用不大
中间件需求
中间件需求
- 配合 Handler 实现一个完整的请求处理生命周期
- 拥有预处理逻辑与后处理逻辑
- 可以注册多中间件
- 对上层模块用户逻辑模块易用
核心逻辑与通用逻辑分离，跟切面的思想类似
举例： - 日志记录
- 性能统计
- 安全控制
- 事务处理
- 异常处理
设计流程
- 既然要实现预处理和后处理，那这个就很像调用了一个函数
- 路由上可以注册多 Middleware，同时也可以满足请求级别有效只需要将 Middleware 设计为和业务和 Handler 相同即可。
- 用户如果不主动调用下一个处理函数怎么办?
帮用户主动调用中间件 - 出现异常想停止怎么办?
设置最大值，跳出循环
路由设计
框架路由实际上就是为 URL 匹配对应的处理函数 (Handlers
- 静态路由: /a/b/c、/a/b/d
- 参数路由: /a/:id/c (/a/b/c，/a/d/c)、/*all
- 路由修复: /a/b <-> /a/b/
- 冲突路由以及优先级: /a/b、/:id/c
- 匹配 HTTP 方法
- 多处理函数:方便添加中间件
如何做设计
- 明确需求:考虑清楚要解决什么问题、有哪些需求
- 业界调研:业界都有哪些解决方案可供参考
- 方案权衡:思考不同方案的取舍
- 方案评审:相关同学对不同方案做评审
- 确定开发:确定最合适的方案进行开发
协议层设计
网络层设计
五种IO模型：
阻塞式IO（bloking IO）、非阻塞式IO（non-blocking IO）、多路复用IO模型（multiplexing IO）、信号驱动IO模型（signal-driven IO）以及异步IO模型（asynchronous IO）
设计总结
- API 设计:可理解性、简单性.
- 中间件设计:洋葱模型
- 路由设计:前缀匹配树
- 协议层设计: 抽象出合适的接口
- 网络层设计: 网络模型
03性能修炼之道
总结
HTTP框架修炼之道的学习，使得对网络各个层次有了更深的理解，尤其是中间件设计和路由设计，此外 HTTP在企业上不光要考虑性能，追求易用还要打通生态。
