课程背景
再谈HTTP
1.1HTTP协议是什么，为什么需要协议
HTTP：超文本传输协议（Hypertext Transfer protocol）
需要明确的边界
-开始
-结束
能够携带信息
-什么消息
-消息类型
....
1.2协议里有什么
content-Length：28（描述了包里有多少个字节）
POST /sis HTTP/1.1（请求行）
请求行/状态行（方法名，URL，协议版本组成）/（协议版本，状态码，状态码描述）
请求头/响应头
请求体/响应体
Demo
1.3请求流程
分为：业务层，服务治理层依托中间件层，路由层，协议编（解）码层，传输层
1.4不足与展望
HTTP1：队头阻塞，传输效率低，明文传输不安全
HTTP2：多路复用，头部压缩，二进制协议
QUIC：基于UDP实现，解决队头阻塞，加密减少握手次数，支持快速启动
HTTP框架的设计与实现
2.1分层设计
特点：专注性，扩展性，复用性
HTTP也用分层设计：高内聚，低耦合，易复用，高扩展性
2.2应用层设计
提供合理的API
1.可理解性：如ctx.Body(),ctxGetBody(),
不要用 ctx.BodyA()
2.简单性
3.冗余性
4.兼容性
5.可测性
6.可见性
不要试图在文档中说明，很多用户不看文档
2.3中间件层
使用场景：日志记录，性能统计，安全控制，事务处理，异常处理
让中间件执行打印的操作
1.既然要实现预处理和后处理，那这个就很像调用了一个函数
2.路由上可以注册多Middleware，同时也可以满足请求级别有效只需要将Middleware设计和业务和Handler相同即可
3.用户如果不主动调用下一个处理函数怎么办
**核心：在任何场景下index保证递增
4.出现异常想停止怎么办？
让index设置为一个最大值，让它跳出循环
调用链
适用场景：1.不调用Next初始化逻辑且不需要在同一调用栈；2.调用Next后处理逻辑或需要在同一调用栈上
2.4路由设计
框架路由实际上就是为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方法
多处理函数：方便添加中间件
青铜：map[string]handlers
黄金：前缀匹配树
如何匹配HTTP方法？
外层：Map：根据method进行初步函数
如何实现添加多处理函数？
在每个节点上使用一个list存储handler
1.明确需求，2.业界调研，3.方案权衡，4.方案评审，5.确定开发
2.5协议层设计
抽象出合适的接口
1.不要将上下文存储在结构类型中；相反，应该将上下文显式传递给每个它需要的函数，上下文应该是第一步参数
2.需要在连接上读写数据
2.6网络层设计
NIO：注册一个监听器，当监听器监听到我们有足够的数据后，我们再去进行一个唤醒，唤醒我们的func，read就能读到足够的数据，就不会卡在这里，流程就不会阻塞
