这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天
HTTP协议
HTTP：超文本传输协议（Hypertext Transfer Protocol）
协议内容
- 请求行/状态行：方法名、URL、协议版本；协议版本、状态码、状态码描述
- 请求头/响应头：协议约定、业务相关
- 请求体/响应体
请求流程
不足与展望
HTTP1：队头阻塞、传输效率低、明文传输不安全
HTTP2：多路复用、头部压缩、二进制协议
QUIC：基于UDP实现、解决队头阻塞、加密减少握手次数、支持快速启动
HTTP框架的设计与实现
分层设计
| OSI七层网络模型 | TCP/IP四层钙奶模型 | 对应网络协议 |
|---|---|---|
| 应用层 | 应用层 | HTTP、TFTP、NFS、WAIS、SMTP |
| 表示层 | 应用层 | Telnet、Rlogin、SNMP、Gopher |
| 会话层 | 应用层 | SMTP、DNS |
| 传输层 | 传输层 | TCP、UDP |
| 网络层 | 网络层 | IP、ICMP、ARP、RARP、AKP、UUCP |
| 数据链路层 | 数据链路层 | FDDI、Ethernet、Arpanet、PDN、SLIP、PPP |
| 物理层 | 数据链路层 | IEEE 802.1A，IEEE 802.2到IEEE 802.11 |
应用层设计
提供合理的API
- 可理解性：如 ctx.Body()，ctx.GetBody(), 不要用 ctx.BodyA()
- 简单性：如 ctx.Request.Header.Peek(key), ctx.GetHeader(key)
中间件设计
- 配合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方法
- 多处理函数：方便添加中间件
前缀匹配树
中间件层：熔断、限流
重复header缓存
二进制协议：解析起来更高效
应用层：对请求进行抽象
中间件层：对请求预处理 后处理逻辑
路由层：大家注册选举，相关的操作
协议层：HTTP1.1无法满足需求
网络层：灵活替换网络库
