这是我参与「第三届青训营 -后端场」笔记创作活动的第3篇笔记
声明,仅仅为个人观点，无法保证正确性，如果错误欢迎指出。欢迎交流讨论。
类似于RPC框架，HTTP框架也是为了解放生产力而实现的。这也就意味着需要降低用户的心智负担，让用户用起来省心。为了实现这个目标，一个经典的参考是TCP/IP网络协议栈的分层设计。 由此 HTTP 一般有四层：
- 应用层
- 中间件
- 路由
- 编解码
应用层一般认为是具体到业务逻辑的相关内容，直接处理请求响应之类的，以Gin或者Iris之类的框架而言，他就是所谓的HandleFunc，当然实际上还可以继续细分，但是那就不HTTP框架考虑的地方了。
中间件，名字怪怪的，最初是指汤姆猫（bushi 之类的软件，至于为什么在go的http框架中这样称呼，个人猜测应该是历史原因。总而言之，在这里是类似的东西，并且有所谓的洋葱模型，也可以认为是AOP的体现。 具体到实现一般就是实现一个处理链顺序调用。 不过有些时候并不是需要像AOP，反而只是阻止后续运行，这可以通过异常处理实现。
路由层，由于历史原因，HTTP提供了远远超过RPC的接口定义方式，这导致HTTP的请求行可能奇奇怪怪。而且由于历史原因，HTTP还会提供模糊匹配功能。比如下面这些
/a/{b}/c/{d}
/{a}/b
......
所以一般都会需要使用支持模糊匹配的前缀树来实现。如果是实现了前缀匹配那么只需要把它关联到具体的处理逻辑就可以了。
最后是所谓的编解码，实际上就是具体到网络协议了。 同样是由于各种各样的历史原因，HTTP 最初是明文的，甚至不支持pipeline技术。而到今天不断地优化，到HTTP3（虽然还只是RFC）不止是想压缩数据编码甚至将使用UDP代替TCP。 注意到这部分仅仅是对数据的处理，对于大多数情况下这应该都不会影响实际的业务逻辑，因此这应该是和其他部分耦合最低的部分了。
