HTTP
个人总结：HTTP的本质是一种协议，它规定了收、发端之间的应用层中，进行信息交换的规则
HTTP协议
超文本传输协议
超文本：由txt扩展而来的包含图片等 协议：包含传输信息的规则
协议里有什么
请求行/状态行
方法名、URL、协议版本
GET\HEAD\POST\PUT......
状体行： 协议版本、状态码、状态码描述
1xx信息类 2xx成功 3xx重定向 4xx客户端错误 5xx服务端错误
请求头/响应头 协议相关、业务相关内容 请求体/响应体
请求行：对HTTP的版本描述 元数据 {包含包里的字节数} /r 包的一部分 /r/r
回复：
依次为： 200为状态码
元数据
回复内容
个人理解：协议的作用就是让接受和发送方有一套统一的标准，就像我们常见的Ascii码一样
请求流程
业务层-服务治理层-路由层-协议编码-传输层
不足与展望
HTTP1基于tcp
- 队头阻塞：需要等待前一个完成
- 传输效率低
- 是明文传输，不安全
HTTP2 可以多路复用、头部压缩、二进制协议，解析起来更加高效
QUIC协议 解决队头阻塞、减少握手次数、支持快速启动
分层设计
可以简化系统设计，不同的人专注某一件事情，使用下一层提供的接口即可 应用层-中间件-路由层-协议层-网络层
一个切实可行的复杂系统势必是从一个切实可行的简单系统发展而来的。从头开始设计的复杂系统根本不切实可行，无法修修补补让它切实可行。你必须由一个切实可行的简单系统重新开始。
盖尔定律
应用层设计 可理解性： 一眼能够看出来想要获取什么 比如ctx.Body() 简单性： 如ctx.Request.Header.Pek(key) /ctx.GetHeader(key) 冗余性 不要出现干同样事情的接口 兼容性 可测性 可见性
- 不要试图在文档中说明，很多用户不看文档
中间件需求
配合Handler 实现一个完整的请求处理生命周期拥有预处理逻辑与后处理逻辑 可以注册多中间件 对上层模块用户逻辑模块易用
洋葱模型
我的个人思考与总结： 因为对此不是很理解，我专门查了一下，下面是我个人精简后的思考： 洋葱模型就是一种处理请求和响应的方式。像一个洋葱一样，请求从外层开始，经过一层层中间件的处理，最后到达内层进行实际的业务处理。然后，响应再一层层地返回到外层中间件，最终返回给客户端。此时每个中间件都可以选择处理两次 通过这种设计，使得我们可以灵活地添加、删除或者修改中间件，从而能够让其满足不同的业务需求。同时也可以统一处理请求和响应，提高代码的可维护性和可读性。
中间件设计
1.既然要实现预处理和后处理，那这个就很像调用了一个函数 2.路由上可以注册多Middleware， 回时也可以满足请求级别有效 只需要将Middleware设计为和业务和Handler相同即可。
适用场景：
不调用Next
初始化逻辑且不需要在同一调用栈
调用Next后处理逻辑或需要在同一调用栈上
路由设计
框架路由实际上就是为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方法 多处理函数：方便添加中间件等等
- 根据url选择不同界面
青铜：map[string]handlers 优势：运行快、简单 只对静态路由有效，参数路由则不行
黄金：前缀匹配树
个人理解：带前缀的树形结构因为可以每次排除掉更多的结果，减少了无谓的比较，因此性能相对更高
如何匹配HTTP方法
如何添加多处理函数： 在每个节点上使用一个list存储handler
如何做设计
1.明确需求：考虑清楚要解决什么问题、有哪些需求 2.业界调研：业界都有哪些解决方案可供参考 3.方案权衡：思考不同方案的取舍 4.方案评审：相关回学对不同方案做评审 5.确定开发：确定最合适的方进行开发
协议层
最核心的点：如何抽象出最合适的接口
Do not store Contexts inside a struct type；insteadpassa Context explicitly to eachiunction that needs it.The Context should be the first parameter.
需要在连接上读写数据
传输层
BIO 阻塞IO：可能会卡在读取 NIO 可以读到足够的数据 go net是典型的BIO
总结
API设计：可理解性、简单性.. 中间件设计：洋葱模型 路由设计：前缀匹配树 协议层设计：抽象出合适的接口 网络层设计：网络模型
课后思考
HTTP分层设计的好处：将复杂的问题分解成局部子问题交给程序员处理，提高了效率和复用性
缺点：降低了性能，增加了上下层的依赖
