【Hertz 新手小册】Day 2. 什么是 HTTP 框架
本期内容介绍：
1. 为什么需要 HTTP 协议
2. 协议里面包括什么
3. 协议的对比与展望
01 为什么需要 HTTP 协议
前言
起初尹师傅每天把自己烤羊肉串的心得体会记录到电脑上，与自己的电脑进行交流。此时记录的东西只是一些纯文本。
后来村里通网了之后，尹师傅就想把这个信息放到网上供大家进行交流和分享，这也是我们做开源的目的之一，共同促进整个社区的进步。我们把两台电脑连起来之后，在网线上传输 01 二进制流，就可以进行分享了。
再后来尹师傅也想宣传一下自己的烤肉，让更多的小伙伴来吃，但这个时候单单文本不足以满足需求了，尹师傅想放一些烤羊肉串的图片、烤羊肉串的教程等等。此时尹师傅就发愁了，文本流传输的都是明文，大家看到之后可以猜测大概的含义，那图片应该如何传输呢？对方怎么能将 0101 解码成为一张图片呢？
于是尹师傅查阅了很多资料，发现了 HTTP 并对其加以深入研究。那什么是 HTTP 呢？
HTTP 全称叫做超文本传输协议。从名字进行解读，首先它是一个传输协议，其次它的传输数据就是超文本。超文本是什么呢？就是超越文本以外的图片、视频等，这些正是尹师傅所需要的。
举个例子，只有我们按照语法造出来的句子对方才能理解，协议也是如此。我们在网络上传输的都是一些 01 数据流，需要按照一定的编码规范进行编码才能够让通信双方理解。
明确协议边界
首先，HTTP 协议需要一个明确的边界。因为协议在网络上是以二进制流的形式进行传输，我们并不知道协议何时开始以及何时结束，因此需要一个明确的边界。
协议元数据
协议元数据需要描述我们传输数据的一些信息。比如我们携带 Text 类型的数据，或者携带一些图片类型的数据等等。
数据部分
这里的数据就是真正要传输的数据，比如 Text ，除了 Text 之外，也可以放入我们的羊肉串 JPG、烤羊肉串教程 Mp4 这些数据等。
02 协议里面包括什么
举一个简单的例子，一个常见的 POST 请求在协议层究竟做了什么？（POST是一个 HTTP 的请求方法，之后会介绍到）
如图是一个已经完成编码的 HTTP1.1 协议，我们能够很清晰地看到这是一个明文协议，具有较高的可读性，而且可以大概可以猜出含义。对于我们的请求可以设想一个场景，就是你邀请一个小姐姐去烧烤，我们把这句话编成 HTTP 协议的一个报文。
请求
我们的请求是由三部分组成的，分别是请求行、请求头和请求体。
1. 请求行
请求行是由一个 HTTP 的请求方法 POST 、一个 URL 、一个协议版本的描述以及最后的一个换行符组成。
2. 请求头
第一行是请求行，紧跟着请求行的就是请求头，请求头大概描述了这个包的一些元数据，它的长度是不固定的，以两个换行符表明协议结束。
请求头这里分为协议相关的请求头和业务相关的请求头。如图我们的请求头部分，第一个请求头写的是 who ，表明是谁邀请了这个小姐姐。这里设定邀请人为 Xiaoming，因此当这个请求传送给小姐姐的时候，她就明白了这是来自 Xiaoming 的一个请求。
第二个请求头 Content-Type 表明数据要按照怎样的格式进行解析。这里 text/plain 说明是按照纯文本格式进行解析。
请求头中有一个非常关键的字段 Content-Length，它描述了我们下一部分的请求体的长度。如果 Content-Length 标注有误，比如 Content-Length 标注过短，小姐姐就无法理解请求的含义；如果 Content-Length 标注过长，小姐姐会以为请求没有说完，因此可能会一直等待下半部分。
3. 请求体
请求体就是数据部分。如图所示，“How about we go to a barbecue this weekend？” 就是请求体。
完成编码后，小姐姐按照编码规范进行解码就可以获得请求的具体含义。下面是小姐姐的回复，看上去是和请求非常相似的，这就是与请求所对应的响应。
响应
响应是由响应行、响应头和响应体组成的。
1. 响应行
响应行和请求行非常类似，但是也有一些略微的区别。首先，它是以一个 HTTP 协议版本开头的，不需要再放一个 HTTP 方法；其次，区别在于状态码，如图所示是一个 200 OK 的状态码，后面也会具体介绍一下不同状态码对应的不同含义。
2. 响应头
响应头描述了响应的元数据。图中的 Server 是 CloudWeGo 开源的 HTTP 框架 Hertz，Date 是做出响应的时间。
3. 响应体
这里的响应体就是“Wow!! I've been wanting wo go for a long time”。同样地，响应头里也有一个非常关键的字段 Content-Length , 这个和请求头里的 Content-Length 意义是一样的，都是描述这个数据的具体长度。
总结
请求和响应其实都是由请求行、状态行以及请求头、响应头和最后的请求体、响应体这三部分组成。请求行和状态行是固定的一行，请求头和响应头的行数不固定，以两个换行符作为结束，之后就是请求体和响应体。
- 请求行是由三部分： HTTP 方法名、URL和协议版本组成。
常见的方法名比如：GET是 HTTP 0.9 （HTTP 协议的第一个版本是从 0.9 开始的）当中唯一的一个方法； HTTP 1.0 扩充了 HEAD 和 POST ；HTTP 1.1 又陆续进行了扩充。最后的 PATCH 其实是在 HTTP 1.1 之后进行的一个扩充，但是因为它使用的比较广泛，所以也列在了这里。
不同的方法名其实是有一些不同的语义的，比如 GET 是获取， POST 是上传， PUT 是更新， DELETE 是删除等等。
- 状态行也是有类似的三个部分：协议版本、状态码、和状态码描述。
协议版本现在用的最广泛的就是 H1 协议。状态码在上述例子当中小姐姐回到的是一个 200 的状态码，200 就是我们最想见到的一个状态码，表明我们的请求是成功的。同时这个状态码也是比较少见的，因为定义成功之后，网页可能不会给大家就展示一个 200，而是会把里面的内容展示出来，相反大家可能经常会见到 4 开头的错误，比如 404 not found 表示所在资源没有找到。
- 请求头和响应头都分为两种：协议约定和业务相关。
“协议约定”类中，在上述例子提到了一个非常重要的字段 Content-Length；
“业务相关”类中，比如刚刚提到的 Who，即“是谁发送的这个请求呢”，是 Xiaoming。
03 三种常见协议的对比与展望
H1 协议：
- 基于 TCP 传输存在一些问题，比如队头阻塞，就比如我前面的包没有到，反而后面的包先到的话，这里就会一直阻塞，等待前面的包到达。
- 传输效率低。这体现在以下两个方面：第一，它是一个 Ping-Pong 的模型，如果没有把 response 返回的话，连接是不能够进行复用的；第二，头部冗余字段比较多，像刚才邀请小姐姐去吃烧烤例子中，可以看到很短的一句话，但是上面的头部字段其实是非常多的。
- 明文传输不安全。对需要隐藏的信息不能起到加密作用。
H2 协议，相对 H1 做了一些优化：
- 多路复用。针对 H1 的传输效率低， H2 采用多路复用的方式，即在一条连接上可以传输很多的请求，通过 stream ID 进行区分，而不用等待 response 返回。
- 头部压缩，相同的头部无需再传。
- 二进制协议。代替了 H1 的明文协议。
但是 H2 依旧是基于 TCP 进行的实现，并没有解决队头阻塞问题。
QUIC 协议：
- 基于 UDP 实现的，不是基于 TCP 实现的，因此从根本上解决了队头阻塞的问题。
- QUIC 的加密，可以减少一些握手次数。H1 是明文传输，大家觉得不安全，又衍生出了 TLS 协议。但是像 TLS 1.2 协议的第一次建立连接需要 7 次握手，因此传输的时延是非常高的。
- 支持快速恢复和启动。
这三种协议的适用场景有所不同，具体如下：
H1 协议是现在应用最为广泛的协议，也是非常好用的一个协议。从诞生至今已经近 30 年，足以体现它的生命力。但是它确实存在传输效率低的问题，主要体现在浏览器端的传输。因为像 server 的话，如果认为建一条连接不够，就可以多建几条连接。但是浏览器的最大连接数是固定的，不能建立很多的连接。这个时候如果要传输很多的资源，比如网站上传几百几千张图片的话，后面的请求就需要排队，此时时延非常高。
因此在浏览器这种场景需要传输大量资源的话，还是比较推荐 H2 协议，这也是 H2 用得比较多的一个地方。除了浏览器之外，还有一些比如对连接数要求非常敏感的其他场景。
QUIC 协议主要应用场景在于解决一些弱网的问题，提高弱网环境下上传的成功率。
相关信息
官方 GitHub：github.com/cloudwego/h…
官方文档：www.cloudwego.io/zh/docs/her…
项目地址
GitHub：github.com/cloudwego
