本期内容介绍：
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
官网：www.cloudwego.io
