HTTP原理初探
HTTP协议(超文本传输协议HyperText Transfer Protocol)，它是基于TCP协议的应用层传输协议，简单来说就是客户端和服务端进行数据传输的一种规则。
注意：客户端与服务器的角色不是固定的，一端充当客户端，也可能在某次请求中充当服务器。这取决与请求的发起端。HTTP协议属于应用层，建立在传输层协议TCP之上。客户端通过与服务器建立TCP连接，之后发送HTTP请求与接收HTTP响应都是通过访问Socket接口来调用TCP协议实现。
HTTP 是一种无状态 (stateless) 协议, HTTP协议本身不会对发送过的请求和相应的通信状态进行持久化处理。这样做的目的是为了保持HTTP协议的简单性，从而能够快速处理大量的事务, 提高效率。
HTTP 请求由请求行，消息报头，请求正文三部分构成，具体内容见下图：
HTTP响应也由三部分组成，包括状态行，消息报头，响应正文。
HTTP响应状态行
状态行也由三部分组成，包括HTTP协议的版本，状态码，以及对状态码的文本描述。例如：
HTTP/1.1 200 OK （CRLF）
响应报文：
从HTTP2.0到QUIC
HTTP2
HTTP2 基于 SPDY，专注于性能，最大的一个目标是在用户和网站间只用一个连接。
新增特性：
- 二进制分帧 -
HTTP2性能增强的核心 - 多路复用 - 解决串行的文件传输和连接数过多
二进制分帧
首先，HTTP2 没有改变 HTTP1 的语义，只是在应用层使用二进制分帧方式传输。因此，也引入了新的通信单位：帧、消息、流。
分帧有什么好处？服务器单位时间接收到的请求数变多，可以提高并发数。最重要的是，为多路复用提供了底层支持。
多路复用
一个域名对应一个连接，一个流代表了一个完整的请求-响应过程。帧是最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。多路复用，就是在一个 TCP 连接中可以存在多个流。
HTTP2的缺陷
TCP以及TCP+TLS建立连接的延时TCP的队头阻塞并没有彻底解决- 多路复用导致服务器压力上升
- 多路复用容易
Timeout
建连延时
TCP连接需要和服务器进行三次握手，即消耗完1.5个 RTT 之后才能进行数据传输。
TLS 连接有两个版本—— TLS1.2 和 TLS1.3，每个版本建立连接所花的时间不同，大致需要1~2个 RTT。
RTT（Round-Trip Time）: 往返时延。表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。
队头阻塞没有彻底解决
TCP 为了保证可靠传输，有一个“超时重传”机制，丢失的包必须等待重传确认。HTTP2 出现丢包时，整个 TCP 都要等待重传，那么就会阻塞该 TCP 连接中的所有请求。
RTO：英文全称是Retransmission TimeOut，即重传超时时间；
RTO是一个动态值，会根据网络的改变而改变。RTO是根据给定连接的往返时间RTT计算出来的。
接收方返回的ack是希望收到的下一组包的序列号。
多路复用导致服务器压力上升
多路复用没有限制同时请求数。请求的平均数量与往常相同，但实际会有许多请求的短暂爆发，导致瞬时 QPS 暴增。
多路复用容易 Timeout
大批量的请求同时发送，由于 HTTP2 连接内存在多个并行的流，而网络带宽和服务器资源有限，每个流的资源会被稀释，虽然它们开始时间相差更短，但却都可能超时。
QUIC
简介
Google 在推 SPDY 的时候就已经意识到了这些问题，于是就另起炉灶搞了一个基于 UDP 协议的 QUIC 协议。而这个就是 HTTP3。它真正“完美”地解决了“队头阻塞”问题。
主要特点
- 改进的拥塞控制、可靠传输
- 快速握手
- 集成了 TLS 1.3 加密
- 多路复用
- 连接迁移
改进的拥塞控制、可靠传输
从拥塞算法和可靠传输本身来看，QUIC 只是按照 TCP 协议重新实现了一遍，那么 QUIC 协议到底改进在哪些方面呢？主要有如下几点：
1. 可插拔 — 应用程序层面就能实现不同的拥塞控制算法。
一个应用程序的不同连接也能支持配置不同的拥塞控制。
应用程序不需要停机和升级就能实现拥塞控制的变更，可以针对不同业务，不同网络制式，甚至不同的 RTT，使用不同的拥塞控制算法。
关于应用层的可插拔拥塞控制模拟，可以对 socket 上的流为对象进行实验。
2. 单调递增的 Packet Number — 使用 Packet Number 代替了 TCP 的 seq。
每个 Packet Number 都严格递增，也就是说就算 Packet N 丢失了，重传的 Packet N 的 Packet Number 已经不是 N，而是一个比 N 大的值。而 TCP 重传策略存在二义性，比如客户端发送了一个请求，一个 RTO 后发起重传，而实际上服务器收到了第一次请求，并且响应已经在路上了，当客户端收到响应后，得出的 RTT 将会比真实 RTT 要小。当 Packet N 唯一之后，就可以计算出正确的 RTT。
3. 不允许 Reneging — 一个 Packet 只要被 Ack，就认为它一定被正确接收。
Reneging 的意思是，接收方有权把已经报给发送端 SACK（Selective Acknowledgment） 里的数据给丢了（如接收窗口不够而丢弃乱序的包）。
QUIC 中的 ACK 包含了与 TCP 中 SACK 等价的信息，但 QUIC 不允许任何（包括被确认接受的）数据包被丢弃。这样不仅可以简化发送端与接收端的实现难度，还可以减少发送端的内存压力。
4. 更多的 Ack 块和增加 Ack Delay 时间。
QUIC 可以同时提供 256 个 Ack Block，因此在重排序时，QUIC 相对于 TCP（使用 SACK）更有弹性，这也使得在重排序或丢失出现时，QUIC 可以在网络上保留更多的在途字节。在丢包率比较高的网络下，可以提升网络的恢复速度，减少重传量。
TCP 的 Timestamp 选项存在一个问题：发送方在发送报文时设置发送时间戳，接收方在确认该报文段时把时间戳字段值复制到确认报文时间戳，但是没有计算接收端接收到包到发送 Ack 的时间。这个时间可以简称为 Ack Delay，会导致 RTT 计算误差。现在就是把这个东西加进去计算 RTT 了。
5. 基于 stream 和 connection 级别的流量控制。
为什么需要两类流量控制呢？主要是因为 QUIC 支持多路复用。
Stream 可以认为就是一条 HTTP 请求。
Connection 可以类比一条 TCP 连接。多路复用意味着在一条 Connetion 上会同时存在多条 Stream。
QUIC 接收者会通告每个流中最多想要接收到的数据的绝对字节偏移。随着数据在特定流中的发送，接收和传送，接收者发送 WINDOW_UPDATE 帧，该帧增加该流的通告偏移量限制，允许对端在该流上发送更多的数据。
除了每个流的流控制外，QUIC 还实现连接级的流控制，以限制 QUIC 接收者愿意为连接分配的总缓冲区。连接的流控制工作方式与流的流控制一样，但传送的字节和最大的接收偏移是所有流的总和。
最重要的是，我们可以在内存不足或者上游处理性能出现问题时，通过流量控制来限制传输速率，保障服务可用性。
6.快速握手
由于 QUIC 是基于 UDP 的，所以 QUIC 可以实现 0-RTT 或者 1-RTT 来建立连接，可以大大提升首次打开页面的速度。
7. 前向纠错（FEC）
早期的 QUIC 版本存在一个丢包恢复机制，但后来由于增加带宽消耗和效果一般而废弃。FEC 中，QUIC 数据帧的数据混合原始数据和冗余数据，来确保无论到达接收端的 n 次传输内容是什么，接收端都能够恢复所有n个原始数据包。FEC 的实质就是异或。示意图：
HTTP框架设计
应用层设计
提供合理的 API
- 合理性
- 简单性
- 冗余、兼容、可测、可见
中间件设计
需求：
- 配合 Handler 实现完整请求处理的生命周期
- 预处理、后处理逻辑
- 多中间件注册
- 对上层用户模块
路由设计
-
初级：map[string]handlers
- /a/b/c、/a/b/d
- /a/:id/c、/*a||
-
高级：前缀匹配树
- /a/b/c、/a/b/d
协议层设计
- Do not store Contexts inside a struct type;instead,pass a Context explicitly to each function that needs it. The Context should be the first parameter.
- 需要在连接上读写数据
- 抽象出合适的接口
