HTTP框架修炼之路|青训营笔记

81 阅读2分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的的第4篇笔记

怕什么真理无穷,进一步有进一步的欢喜

HTTP框架修炼

为什么需要协议

  • 明确的边界:什么时候开始,什么时间结束。不能一直接收或者是一直发送
  • 能够携带的信息:是什么消息,消息的类型是什么

POST方法的请求、响应报文

Screen Shot 2022-05-28 at 11.08.16 AM.png

请求报文格式:

  • 首先是请求行:方法 /url 协议版本
  • 头部:按照键值对的方式进行请求
  • 空行
  • 如果是GET的话,下面就没有数据了,POST就有content数据

响应报文格式:

  • 响应头:版本 状态码 状态码对应信息
  • 响应首部:按照键值对的方式
  • 空行
  • content

请求流程

Screen Shot 2022-05-28 at 11.17.06 AM.png

  • 业务层面:处理业务逻辑
  • 中间件层面:依赖于路由层,可以记录Client处理的时间然后根据一些处理的时间或者是处理的状态进行总体上的控制
  • 编码、解码层面:个人猜测可能就是进行加密🔐处理的层面
  • 传输层就是依赖于TCP进行传输

HTTP版本之间的不足与展望

Screen Shot 2022-05-28 at 11.21.58 AM.png

分层设计

就是将一整个部分分为不同层次进行处理,特定的层次只需要处理对应层次的事情就行,其他层次的内容可以当作是封装好的东西直接使用就可以

  • 专注性、拓展性、复用性

盖尔定律: 一个切实可行的复杂系统势必是从一个切实可行的简单系统发展而来的。从头开始设计的复杂系统根本不切实可行,无法修修补补让它切实可行。你必须由一个切实可行的简单系统重新开始。

2.2应用层次设计

设计合理的api:

  • 可理解性:api的调用要很明确才可以
  • 简单性:如果说方法是深入的但是高频的,可以封装一下高频的
  • 冗余性:不要冗余实现结构
  • 兼容性:多版本兼容
  • 可测试性:一定要可以进行测试
  • 可见性:不能让用户随便搞搞就能找到底层

中间件设计:

Screen Shot 2022-05-28 at 11.44.57 AM.png

有了中间件我们就可以不必要在调用接口的时候进行打印了,直接调用中间件的处理函数就可以了

HTTP优化

针对网络库的优化

  • 能够存下全部的Header
  • 减少系统调用的次数
  • 复用内存
  • 能够多次读取

热点资源的池化

  • 比如说在C++中的数据库连接池
  • 线程池等