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

HTTP的修炼

终端 前端路由 页面 状态管理，API接口层

HTTP请求

请求解析 后端路由 业务逻辑 数据库

HTTP协议

• HTTP协议什么

  • 第一个版本是HTTP0.9，1991
  • 超文本传输协议（Hypertext Transfer Protocol）

• 为什么需要协议

  • 需要明确的边界 开始 结束
  • 能够携带的信息，什么消息，消息类型、

• 协议有什么

  • 请求行/状态行

    • 方法名/URL/协议版本
    • 协议版本/状态码/状态码描述

  • 请求头/响应头

  • 请求体/响应体

• 请求流程

  • 业务层
  • 服务治理层，中间层
  • 路由层
  • 协议编码层
  • 传输层

• 不足与展望

  • HTTP1

    • 队头阻塞
    • 传输效率低
    • 明文传输不安全

  • HTTP2

    • 多路复用
    • 头部压缩
    • 二进制协议 解释起来更加高效

  • QUIC

    • 基于UDP实现
    • 减少队头阻塞
    • 加密减少握手次数
    • 支持快速启动

HTTP框架的实现

• 分层设计

  • 专注性 扩展性 复用性

• 高内聚 低耦合 易复用 高扩展性

• 应用层 中间件 路由 协议层 网络层 transport

• 应用层设计

  • 提供合理的API
  • 可理解性 ctx.Body(),ctx.GetBody()
  • 简单性
  • 冗余行
  • 兼容行
  • 可测性
  • 可见性

• 中间件层

  • 配合Handler实现一个完整的请求处理声明周期

  • 拥有预处理逻辑和后处理逻辑

  • 可以注册中间件

  • 对上层模块用户逻辑模块易用

  • 洋葱模型

    • 核心逻辑与通用逻辑分离

  • 中间件设计

    • 路由上可以注册Middleware，同时也可以满足请求级别有效，只需要将Middlware设计为业务和Handler相同即可

• 路由设计

  • 框架路由实际上就是为了URL匹配对应的处理函数

    • 静态路由 /a/b/c、
    • 参数路由 /a:id/c
    • 路由修复
    • 冲突路由以及优先级
    • 匹配HTTP方法
    • 多处理函数 方便添加中间件
    • 前缀匹配树

    • 网络层设计

      • 网络模式

    针对网络库的优化

    • go net

      • 存下全部Header

      • 减少系统调用的次数

      • 能够复用内存

      • 能够多次读

        netpool

        存下全部Header

        拷贝出完整的Body

        中大包 性能高，时延

      针对协议的优化

      找到Header Line 边界 ：\r\n

      先找到\n再看它前一个是不是\r

      SIMD 一组指令对数据进行变形操作

      自动使用simd进行加速操作

      编解码速度

      针对协议相关的Headers快速解析

      • 通过Header key首字母快速筛选掉完全不可能的key
      • 解析对应value到独立字段
      • 使用byte slice管理对应header存储 方便复用

    取 超高的转换效率 比net.http提高40倍

    舍 额外的内存开销 变更困难

热点资源池优化

取 减少了内存分配 提高了内存复用 降低了GC压力 性能提升

舍 额外的Reset逻辑 请求内有效 问题定位难度增加

追求性能 追求易用 减少误用