HTTP协议|青训营笔记

HTTP

前后端之间通过HTTP通信 框架负责对HTTP请求解析，根据对应路由选择对应逻辑（请求解析-后端路由-业务逻辑）

1.1 HTTP协议是什么：

HTTP：超文本传输协议（Hypertext Transfer Protocol） 传输不止text还要传输图片等，所以叫超文本

1.1 为什么要协议：

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

1.2 协议里有什么：

POST /sis HTTP/1.1 <- HTTP版本描述，请求行

检测到请求行就开始传输协议了

content-length：28 说明多少个字节

包括 请求行/状态行 请求头/响应头 请求体/响应体

1.3 请求流程

业务层：业务方提供

服务治理层，中间件层：限流等的实现

路由层

协议编（解）码层

传输层

1.4 不满与展望

HTTP1：队头阻塞，传输效率低，明文传输不安全

HTTP2：多路复用，头部压缩，二进制协议

QUIC：基于UDP实现，解决队头阻塞，加密减少握手次数，支持快速启动

2.1 分层设计

分层设计可以简化设计，每个人专注各自的层，专注于特定层开发，不用在乎底层的开发，分层可以做到很高的复用，减少工作量

应用层：会对请求进行抽象，提供丰富应用的api

中间件层：对用户的预处理，后处理的逻辑

路由层：原生的路由实现

协议编（解）码层：实现协议扩展

网络层：各种逻辑

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

2.2 应用层设计

提供合理的API（可理解性、简单性、冗余性/兼容性/可测性/可见性）

2.3 中间件设计

中间件需求

配合 Handler 实现一个完整的请求处理生命周期

拥有预处理逻辑与后处理逻辑

可以注册多中间件

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

洋葱模型：

调用链：适用场景

不调用 Next:

初始化逻辑且不需要在同一调用栈

调用 Next:

后处理逻辑或需要在

同一调用栈上

2.4 路由设计

框架路由是为URL匹配对应的处理函数

路由修复：/a/b修复成/a/b/

青铜： map[string]handlers

黄金： 前缀匹配树

构建路由树

构造多棵路由树，外层map根据method筛选

用list存储handler

2.4 如何做设计

1，明确需求:考虑清楚要解决什么问题、有哪些需求

2.业界调研:业界都有哪些解决方案可供参考

3.方案权衡:思考不同方案的取舍

4.方案评审:相关同学对不同方案做评审

5.确定开发:确定最合适的方案进行开发

2.5 协议层设计

抽象出合适的接口，1. Do not store Contexts inside a struct type; instead, pass a Context explicitly to eachfunction that needs it. The Context should be the first parameter.

需要在链接上读写数据

2.6 网络层设计

BIO 打电话问我身份证，然后我去问一下，但是占线，会被卡住，需要做一个BIO，单独开一个go去处理

NIO read读到足够数据，这样就不会堵塞

go net 典型NIO 有read（） write（）两个接口 read给足够的数组，传给底层 底层没有数据就会卡接口

netpoll NIO模式，希望底层传给足够的数据，有了足够的数据才运行