这是我参与「第三届青训营 -后端场」笔记创作活动的的第 4 篇笔记 ～ 前后端之间通过http请求达成通信，这是一个前后端分离的流程图
1 再谈http协议
协议内容
demo：选择方法名、输入URL和请求路径
功能实现的代码：路由注册到server上，选择对应的方法。然后实现回复ok的业务逻辑。
业务层：使用提供的api完成业务逻辑（邀请看电影）
完成业务逻辑后，会进入服务治理的逻辑（熔断、限流）
服务治理层依赖于中间件层
中间件层对请求有先处理逻辑和后处理逻辑，与请求级别绑定
例如计时：进入业务层之前，记录一下当前的时间；业务层执行完毕后再记录执行完毕的时间，即可得到业务逻辑的耗时
对于客户端而言，之后进入协议的编解码，编译协议后，通过传输层传输给客户端
客户端会多一个路由层，根URI选择对应的执行的handler（比如选择邀请哪个小姐姐）
2 http框架的设计与实践
因为分层设计，我们可以不用关心tcp重传、0101怎么通过路由器一步一步地到达对端、网络堵塞、物理设备等。
有了分层设计，我们只需使用下一层给上一层的接口，专注特定层的开发
分层架构让我们更容易做横向拓展
复用性强
2.2应用层设计
不要试图在文档中说明，很多用户不看文档
2.3中间件设计
中间件预处理-业务逻辑-中间件后处理-将完整响应返回给客户
因为用户真正希望执行的是业务逻辑，那我们可以主动帮用户调用之后的中间件
go net是由用户管理的buffer，这两个接口都是传入buffer进行读写，本身不管理buffer
3 性能修炼之道
在标准库上面封装一层buffer，绑定一块缓冲区
由于大部分包都是在4k以下，可以绑定4k左右的缓冲区，对内存压力也不大
再设计一个接口接口，首先需要一个读的时候指针不动、下次还能在这里读Peek
还需要让读指针移动：Discard接口
回收这块内存，希望下一次还能复用之前的空间：Release接口
由于减少锁的竞争，采用了链表的设计方式
找到http协议的边界才能判断是完整的
取：对协议的核心字段进行加速；用byteslice而不是map来存储header，从而高效管理内存、方便复用；把这些kv解析到特定的成员变量里，保证是第一时间取到
舍：对于普通的header没有特殊处理，需要在使用的时候才知道是否存在对应的key；map本身的内存管理由自己的算法维护，没办法用byteslice这样的方式
http header的解析对框架很不友好，所以在设计接口的时候，要避免超大header的情况
4 企业实践
框架建设，企业正在做的努力【性能为王，但是有的不好用，业务同学很容易出错，有时也只能让步性能】
