HTTP、HTTPS和HTTP2的简单了解
HTTP的概述
HTTP 超文本传输协议： 其位于 TCP/IP 体系结构中的应用层协议，是万维网数据通信的基础。
<协议>://<域名>:<端口号>/<路径> 复制代码
一般一个地址的URL构成形式就如http://fanyi.baidu.com/translate，现在常用的协议就是HTTP，如无设置端口号，则默认端口号为80。
HTTP/1.1
目前被使用被广泛的版本，一般没有特殊标明的都指 HTTP/1.1
HTTP 连接的建立过程
通过 域名系统 (Domain Name System 简称DNS) 将域名转换成 IP 地址。
通过三次握手建立 TCP/IP 的连接
发起HTTP请求
目标服务器获取请求并且处理
目标服务器往浏览器发送HTTP相应
浏览器解析并且渲染页面
TCP的三次握手
TCP（Transmission Control Protocol 传输控制协议）是属于网络分层中的传输层，提供一种面向连接的、可靠的字节流服务。面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。
首先要了解这三次握手就要先了解一些TCP报文段和标志位
TCP报文结构
序号 Seq: 占32位，用于标识TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
确认号：Ack，占32位，只有
ACK标志位为1时，确认字段才有效， Ack = Seq + 1标志位：一共有6个
URG：紧急指针有效
ACK：确认序号有效
PSH：接收方应该尽快将这个报文交给应用层
RST：重置连接
SYN：发起一个新连接
FIN：释放一个连接
需要注意的是：
不要将 确认号Ack 和标志位的 ACK确认序号 两者搞混
确认方的Ack = 发起方的seq + 1
在熟悉完TCP的一些简单报文和标志位之后，再来看TCP的三次握手。
TCP的三次握手，即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以来确认连接的建立。
客户端向服务端发送一个TCP报文，首部内的SYN标志位置为1，并且随机一个初始的序号（一般为0）放到报文序号字段中。即Seq = 0,SYN = 1（SYN = 1 时，不能携带数据，并且要消耗一个序号）Client进入SYN_SENT状态，等待Server确认。
服务器接收到报文后，并且为该TCP报文连接分配缓存和变量。然后向客户端发送允许连接的ACK报文段。该报文段首部包括四个信息：即SYN = 1；ACK = 1；确认号字段（Ack）= 客户端序号(Seq) + 1；随机选择自己的序号（一般为0）Seq = 0。Server进入SYN_RCVD状态。
收到服务器的 TCP 响应报文段后，客户端也要为该 TCP 连接分配缓存和变量，并向服务器发送一个 ACK 报文段。该报文段的内容为：确认号字段（Ack） = 服务端的序号 + 1，用来确认对服务器运行连接的报文段进行相应，因为连接已经建立，所以SYN = 0，最后一个阶段报文段可以携带客户到服务端数据。并且以后的每一个报文段，SYN 都置为 0。
TCP的四次挥手
所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：
由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。
Client发送一个FIN的标志，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
Server收到FIN后，发送一个ACK给Client，确认号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
TCP 为什么是四次挥手，而不是三次？
这是因为服务端在 LISTEN 状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。
可以理解为：
A向B发送FIN报文时，仅仅能代表A不再发送报文，但是仍可以接受报文。
B或者还有数据发送，因此需要先发送 ACK 报文给 A，确认号（Ack = seq + 1）。告知 A “我知道你想断开连接的请求了”。这样 A 便不会因为没有收到应答而继续发送断开连接的请求（即 FIN 报文）
B再处理完数据后，就会向A发送一个FIN报文，然后进入 LAST_ACK 阶段（超时等待）。
A 向 B 发送 ACK 报文，双方都断开连接。
HTTP报文格式
HTTP报文是由请求行、首部和实体主体组成，他们之间由CRLF（回车换行符）隔开
注意：实体包括首部（也成为实体首部）和实体主体
开始行（也可称为请求行）和首部是由 ASCII 文本组成的，实体主体是可选的，可以为空也可以是任意二进制数据。
请求报文和响应报文的格式基本相同。
请求报文格式：
<method> <request-URL> <version> <headers> <entity-body> 复制代码
响应报文
<version> <status> <reason-phrase> <headers> <entity-body> 复制代码
一个 HTTP 请求示例：
POST /tenant/material-center/hd/getQuestion HTTP/1.1 Host: api.testing.jniu.com Connection: keep-alive Content-Length: 212 Accept: application/json, text/plain, X-TraceId: 93704a4d259322f0b57510fbe05ac7ad sessionId: 36d1cc12956f5cdf77efd38f10657545 User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1 Content-Type: application/json; charset=UTF-8 Origin: http://localhost:3000 Sec-Fetch-Site: cross-site Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: http://localhost:3000/jniu-ng-agent/testTool/toC/detail Accept-Encoding: gzip, deflate, br Accept-Language: zh-CN,zh;q=0.9 复制代码
一个响应示例
HTTP/1.1 200 OK Server: openresty Date: Thu, 28 Oct 2021 08:39:18 GMT Content-Type: application/json;charset=UTF-8 Content-Length: 552 Connection: keep-alive Access-Control-Allow-Origin: * Content-Encoding: gzip Vary: Accept-Encoding Vary: Origin Vary: Access-Control-Request-Method Vary: Access-Control-Request-Headers X-Frame-Options: Deny 复制代码
方法：
| 方法 | 描述 |
|---|---|
| GET | 从服务器获取一份文档 |
| HEAD | 只从服务器获取文档的头部 |
| POST | 向服务器发送需要处理的数据 |
| PUT | 将请求的数据部分存储在服务器上 |
| TRACE | 对可能经过代理服务器传送到服务器上去的报文进行追踪 |
| OPTIONS | 决定可以在服务器上执行哪些方法 |
| DELETE | 从服务器上删除一份文档 |
状态码
| 整体范围 | 已定义范围 | 分类 |
|---|---|---|
| 100~199 | 100~101 | 信息提示 |
| 200~299 | 200~206 | 成功 |
| 300~399 | 300~305 | 重定向 |
| 400~499 | 400~415 | 客户端错误 |
| 500~599 | 500~505 | 服务器错误 |
首部
首部和方法共同决定了客户端和服务端能做什么事。
首部分类：
通用首部，可以出现在请求或响应报文中。
请求头部，提供更多的请求相关的信息。
响应头部，提供更多的响应相关的信息。
实体首部，描述主体的长度和内容，或者资源本身。
扩展首部，规范字没有定义的新首部。
通用头部
有些首部提供了与报文相关的最基本信息，它们被称为通用首部。以下是一些常见的通用首部：
请求头部
请求首部是只在请求报文中有意义的首部，用于说明请求的详情。以下是一些常见的请求首部：
响应头部
响应首部让服务器为客户端提供了一些额外的信息。
实体头部
实体首部提供了有关实体及其内容的大量信息，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。
性能优化
1. 减少HTTP请求
每发起一个 HTTP 请求，都得经历三次握手建立 TCP 连接，如果连接只用来交换少量数据，这个过程就会严重降低 HTTP 性能。所以我们可以将多个小文件合成一个大文件，从而减少 HTTP 请求次数。 其实由于持久连接（重用 TCP 连接，以消除连接及关闭时延；HTTP/1.1 默认开启持久连接）的存在，每个新请求不一定都需要建立一个新的 TCP 连接。但是，浏览器处理完一个 HTTP 请求才能发起下一个，所以在 TCP 连接数没达到浏览器规定的上限时，还是会建立新的 TCP 连接。从这点来看，减少 HTTP 请求仍然是有必要的。
2. 静态资源使用 CDN
内容分发网络（CDN）是一组分布在多个不同地理位置的 Web 服务器。我们都知道，当服务器离用户越远时，延迟越高。CDN 就是为了解决这一问题，在多个位置部署服务器，让用户离服务器更近，从而缩短请求时间。
3.善用缓存
为了避免用户每次访问网站都得请求文件，我们可以通过添加 Expires 头来控制这一行为。Expires 设置了一个时间，只要在这个时间之前，浏览器都不会请求文件，而是直接使用缓存。
不过这样会产生一个问题，当文件更新了怎么办？怎么通知浏览器重新请求文件？
可以通过更新页面中引用的资源链接地址，让浏览器主动放弃缓存，加载新资源。
具体做法是把资源地址 URL 的修改与文件内容关联起来，也就是说，只有文件内容变化，才会导致相应 URL 的变更，从而实现文件级别的精确缓存控制。什么东西与文件内容相关呢？我们会很自然的联想到利用数据摘要要算法对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。
4.压缩文件
压缩文件可以减少文件下载时间，让用户体验性更好。
gzip 是目前最流行和最有效的压缩方法。可以通过向 HTTP 请求头中的 Accept-Encoding 头添加 gzip 标识来开启这一功能。当然，服务器也得支持这一功能。 举个例子，我用 Vue 开发的项目构建后生成的 app.js 文件大小为 1.4MB，使用 gzip 压缩后只有 573KB，体积减少了将近 60%。
5.通过 max-age 和 no-cache 实现文件精确缓存
通用消息头部 Cache-Control 其中有两个选项：
max-age: 设置缓存存储的最大周期，超过这个时间缓存被认为过期(单位秒)。在这个时间前，浏览器读取文件不会发出新请求，而是直接使用缓存。no-cache: 指定 no-cache 表示客户端可以缓存资源，每次使用缓存资源前都必须重新验证其有效性。
我们可以将那些长期不变的静态资源设置一个非常长的缓存时间，例如设置成缓存一年。 然后将 index.html 文件设置成 no-cache 这样每次访问网站时，浏览器都会询问 index.html 是否有更新，如果没有，就使用旧的 index.html文件。如果有更新，就读取新的index.html文件。当加载新的index.html时，也会去加载里面新的 URL 资源。 例如 index.html 原来引用了 a.js 和 b.js，现在更新了变成 a.js 和 c.js。那就只会加载 c.js 文件。
HTTPS
HTTPS 是最流行的 HTTP 安全形式，由网景公司首创，所有主要的浏览器和服务器都支持此协议。 使用 HTTPS 时，所有的 HTTP 请求和响应数据在发送之前，都要进行加密。加密可以使用 SSL 或 TLS。
SSL/TLS 协议作用在 HTTP 协议之下，对于上层应用来说，原来的发送/接收数据流程不变，这就很好地兼容了老的 HTTP 协议。由于 SSL/TLS 差别不大，下面统一使用 SSL。
HTTP2详解，暂时还未理解，暂时先不写。
HTTP/2
HTTP/2 是 HTTP/1.x 的扩展，而非替代。所以 HTTP 的语义不变，提供的功能不变，HTTP 方法、状态码、URL 和首部字段等这些核心概念也不变。之所以要递增一个大版本到 2.0，主要是因为它改变了客户端与服务器之间交换数据的方式。HTTP 2.0 增加了新的二进制分帧数据层，而这一层并不兼容之前的 HTTP 1.x 服务器及客户端——是谓 2.0。
HTTP/2 连接建立过程
现在的主流浏览器 HTTP/2 的实现都是基于 SSL/TLS 的，也就是说使用 HTTP/2 的网站都是 HTTPS 协议的，所以本文只讨论基于 SSL/TLS 的 HTTP/2 连接建立过程。 基于 SSL/TLS 的 HTTP/2 连接建立过程和 HTTPS 差不多。在 SSL/TLS 握手协商过程中，客户端在 ClientHello 消息中设置 ALPN（应用层协议协商）扩展来表明期望使用 HTTP/2 协议，服务器用同样的方式回复。通过这种方式，HTTP/2 在 SSL/TLS 握手协商过程中就建立起来了。
现在的主流浏览器 HTTP/2 的实现都是基于 SSL/TLS 的，也就是说使用 HTTP/2 的网站都是 HTTPS 协议的，所以本文只讨论基于 SSL/TLS 的 HTTP/2 连接建立过程。 基于 SSL/TLS 的 HTTP/2 连接建立过程和 HTTPS 差不多。在 SSL/TLS 握手协商过程中，客户端在 ClientHello 消息中设置 ALPN（应用层协议协商）扩展来表明期望使用 HTTP/2 协议，服务器用同样的方式回复。通过这种方式，HTTP/2 在 SSL/TLS 握手协商过程中就建立起来了。
HTTP/1.1 的问题
1.队头阻塞
在 HTTP 请求应答过程中，如果出现了某种情况，导致响应一直未能完成，那后面所有的请求就会一直阻塞着，这种情况叫队头阻塞。
2.低效TCP利用
由于 TCP 慢启动机制，导致每个 TCP 连接在一开始的时候传输速率都不高，在处理多个请求后，才会慢慢达到“合适”的速率。对于请求数据量很小的 HTTP 请求来说，这种情况就是种灾难。
3. 臃肿的消息首部
HTTP/1.1 的首部无法压缩，再加上 cookie 的存在，经常会出现首部大小比请求数据大小还大的情况
4. 受限的优先级设置
HTTP/1.1 无法为重要的资源指定优先级，每个 HTTP 请求都是一视同仁。
二进制分帧层
HTTP/2 是基于帧的协议。采用分帧是为了将重要信息封装起来，让协议的解析方可以轻松阅读、解析并还原信息。
而 HTTP/1.1 是以文本分隔的。解析 HTTP/1.1 不需要什么高科技，但往往速度慢且容易出错。你需要不断地读入字节，直到遇到分隔符 CRLF 为止，同时还要考虑不守规矩的客户端，它只会发送 LF。
解析 HTTP/1.1 的请求或响应还会遇到以下问题：
一次只能处理一个请求或响应，完成之前不能停止解析。
无法预判解析需要多少内存。
HTTP/2 有了帧，处理协议的程序就能预先知道会收到什么，并且 HTTP/2 有表示帧长度的字段。
帧结构
+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | Type (8) | Flags (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) ... +---------------------------------------------------------------+ 复制代码
| 名称 | 长度 | 描述 |
|---|---|---|
| Length | 3字节 | 表示帧负载的长度，取值范围为 （2 的 14 次方）至 （2 的 24 次方 - 1）。（2 的 14 次方） 16384 字节是默认的最大帧大小，如果需要更大的帧，必须在 SETTINGS 帧中设置 |
| Type | 1字节 | 当前帧类型（见下表） |
| Flags | 1字节 | 具体帧类型的标识 |
| R | 1字节 | 保留位，不要设置，否则可能会带来严重的后果 |
| Stream Identifier | 31字节 | 每个流的唯一 ID |
| Frame Payload | 长度不变 | 真实的帧内容，长度是在 Length 字段中设置的 |
由于 HTTP/2 是分帧的，请求和响应都可以多路复用，有助于解决类似类似队头阻塞的问题。
帧类型
| 名称 | ID | 描述 |
|---|---|---|
| DATA | 0x0 | 传输流的核心内容 |
| HEADERS | 0x1 | 包含 HTTP 首部，和可选的优先级参数 |
| PRIORITY | 0x2 | 指示或更改流的优先级和依赖 |
| RST_STREAM | 0x3 | 允许一端停止流（通常由于错误导致的） |
| SETTINGS | 0x4 | 协商连接级参数 |
| PUSH_PROMISE | 0x5 | 提示客户端，服务器要推送些东西 |
| PING | 0x6 | 测试连接可用性和往返时延（RTT） |
| GOAWAY | 0x7 | 告诉另一端，当前的端已结束 |
| WINDOW_UPDATE | 0x8 | 协商一端将要接收多少字节（用于流量控制） |
| CONTINUATION | 0x9 | 用以扩展 HEADERS 模块 |
多路复用
在 HTTP/1.1 中，如果客户端想发送多个并行的请求，那么必须使用多个 TCP 连接。
而 HTTP/2 的二进制分帧层突破了这一限制，所有的请求和响应都在同一个 TCP 连接上发送：客户端和服务器把 HTTP 消息分解成多个帧，然后乱序发送，最后在另一端再根据流 ID 重新组合起来。
这个机制为 HTTP 带来了巨大的性能提升，因为：
可以并行交错地发送请求，请求之间互不影响；
可以并行交错地发送响应，响应之间互不干扰；
只使用一个连接即可并行发送多个请求和响应；
消除不必要的延迟，从而减少页面加载的时间；
不必再为绕过 HTTP 1.x 限制而多做很多工作；
流
HTTP/2 规范对流的定义是：HTTP/2 连接上独立的、双向的帧序列交换。如果客户端想要发出请求，它会开启一个新流，然后服务器在这个流上回复。 由于有分帧，所以多个请求和响应可以交错，而不会互相阻塞。流 ID 用来标识帧所属的流。
客户端到服务器的 HTTP/2 连接建立后，通过发送 HEADERS 帧来启动新的流。如果首部需要跨多个帧，可能还会发送 CONTINUATION 帧。该 HEADERS 帧可能来自请求或响应。 后续流启动的时候，会发送一个带有递增流 ID 的新 HEADERS 帧。
服务器推送
HTTP/2 新增的一个强大的新功能，就是服务器可以对一个客户端请求发送多个响应。换句话说，除了对最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确地请求。
首部压缩
HTTP/1.1 存在的一个问题就是臃肿的首部，HTTP/2 对这一问题进行了改进，可以对首部进行压缩。 在一个 Web 页面中，一般都会包含大量的请求，而其中有很多请求的首部往往有很多重复的部分。
性能优化
使用 HTTP/2 代替 HTTP/1.1，本身就是一种巨大的性能提升。 这小节要聊的是在 HTTP/1.1 中的某些优化手段，在 HTTP/2 中是不必要的，可以取消的。
取消合并资源：在 HTTP/1.1 中要把多个小资源合并成一个大资源，从而减少请求。而在 HTTP/2 就不需要了，因为 HTTP/2 所有的请求都可以在一个 TCP 连接发送。
取消域名拆分： 取消域名拆分的理由同上，再多的 HTTP 请求都可以在一个 TCP 连接上发送，所以不需要采取多个域名来突破浏览器 TCP 连接数限制这一规则了。
作者：轻云淡雾
链接：https://juejin.cn/post/7025800232600354829