目录
一、URL（🌟🌟🌟🌟🌟）
URL 是统一资源定位符。是互联网资源位置的标识方式。是 URI 的一种。我们通常会基于 http 规范通过指定的 url 访问网络中的资源。
URI 语法：protocol://hostname:port/directory/filename?name=value#anchor
| URI 成员 | 含义 |
|---|---|
| protocol | 访问资源使用的协议，如：http、https、ftp、telnet 等。 |
| hostname | 服务器的主机名称，IP 地址。 |
| port | 访问的端口号，默认为80。 |
| directory | 访问资源的目录名称。 |
| filename | 访问的资源名称。 |
| ?name=value | 访问资源时的参数和参数值。 |
| #anchor | 访问当前资源的锚点。 |
二、HTTP
HTTP (Hypertext transfer protocol) 是超文本传输协议。是网络中计算机与计算机之间通过网络进行数据出传输的一种规范。
HTTP 请求的内容通称为"资源"。”资源“这一概念非常宽泛，它可以是一份文档，一张图片，或所有其他你能够想到的格式。每个资源都由一个 (URI) 来进行标识。
HTTP 最早是在 1991 年发布的，1996 年发布 1.0 版，1997 年是 1.1 版，2015 年发布了 2.0 版，2018 年发布了 3.0 版。随着版本的升级，其特性也在不断的增强，但到目前为止 HTTP/1.1 这个版本依旧是应用最广泛版本。
1、常用的 HTTP 请求方式（🌟🌟🌟🌟🌟）
| HTTP 请求方式 | 描述 |
|---|---|
| GET | 表示请求服务端资源。 |
| HEAD | 请求服务端资源，但没有响应体。 |
| POST | 在服务端创建资源。 |
| PUT | 更新服务端目标资源。 |
| PATCH | 用于对资源应用部分修改。 |
| DELETE | 删除服务端指定的资源。 |
| CONNECT | 建立到由目标资源的隧道。 |
| OPTIONS | 描述目标资源的通信选项。 |
| TRACE | 消息环回测试。 |
2、HTTP 响应状态码（🌟🌟🌟🌟🌟）
- 1xx：表示请求已接收，继续处理。
- 2xx：表示请求已被服务端成功处理。
- 3xx：表示请求需更进一步的操作。
- 4xx：客户端请求不正确。
- 5xx：服务器处理请求时错误。
常见状态码分析：
| 状态码 | 描述 |
|---|---|
| 200 | OK。请求响应成功。 |
| 302 | 临时重定向。 |
| 304 | 服务内容没有变化。 |
| 400 | 当前请求无法被服务器理解。 |
| 401 | 当前请求需要用户验证。 |
| 403 | 客户端无权访问资源。 |
| 404 | 请求资源不存在。 |
| 405 | 请求方式不被允许。 |
| 406 | 无法解析服务端返回的数据。 |
| 408 | 请求超时。 |
| 413 | 请求实体太大。 |
| 415 | 不支持的媒体类型。 |
| 500 | 服务器发生不可预见错误。 |
| 503 | 服务暂时不可用。 |
| 504 | 网关请求超时。 |
3、HTTP 消息
HTTP 消息可以分为：
- 请求消息：http 请求消息是基于 http 协议发送请求时携带的请求数据。
- http 请求消息由以下四部分构成：请求行、请求头、空行 和 请求消息体。
- 响应消息：http 响应消息是基于 http 协议发送请求后返回的数据。
- http 响应消息由以下四部分构成：响应状态行、响应头、空行 和 响应消息体。
无论是请求消息，还是响应消息，都可以将其分成三部分：消息头、空行 和 消息体。
（1-1）、请求行
请求行是请求消息头中的第一行。
语法结构：request-method-name request-URI HTTP-version
- request-method-name：表示请求方式（如：GET、POST）。
- request-URI：表示请求统一资源标识（不含主机部分）。
- HTTP-version：表示HTTP协议版本（如：HTTP/1.1）。
请求行案例分析：
GET /test.html HTTP/1.1
HEAD /query.html HTTP/1.0
POST /index.html HTTP/1.1
（1-2）、请求头
请求头由一些键值(key/value)对构成，一个key还可以对应多个值。
语法结构：request-header-name: request-header-value1, request-header-value2, ...
例如：
Host: www.xyz.com
Connection: Keep-Alive
Accept: image/gif, image/jpeg, */*
Accept-Language: us-en, fr, cn
常见报头如下表所示：
| 报头名称 | 含义 |
|---|---|
| User-Agent | 用户代理。允许将客户端信息告诉服务器。 |
| Host | 请求资源的主机和端口号，可从URL中获取。 |
| Accept | 允许客户端接受哪些类型的信息。如image/gif, text/html ，/(所有类型)。 |
| Accept-Language | 客户端可以接受的语言类型。 |
| Accept-Encoding | 指定可接受的内容压缩编码类型。 |
| Accept-Charset | 指定客户端接受的字符集。 |
| Cookie | 传输到服务器端的COOKIE数据。 |
| Connection | 连接类型。 |
| Cache-Control | 控制缓存。 |
| Referer | 可以记录访问的来源，统计访问量。 |
（1-3）、请求消息体
请求正文信息，比方说发送post请求时，可以将客户端要提交的表单部分内容放在这里传递到服务端。
请求消息体的综合案例：
POST /user HTTP/1.1
Host: www.xy.com
Accept: image/gif, image/jpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
(blank line)
id=10&name=tony
（2-1）、响应状态行
响应行是响应消息头中的第一行。
语法结构：HTTP-version status-code reason-phrase
- HTTP-version：为协议版本。
- status-code：为响应状态码。
- reason-phrase：为响应描述。
响应状态行案例：
HTTP/1.1 200 OK
HTTP/1.0 404 Not Found
HTTP/1.1 403 Forbidden
（2-2）、响应头
响应头用于告诉浏览器，应当怎样处理响应数据。
语法也是键值对结构：response-header-name: response-header-value1, response-header-value2, ...
响应头案例：
Content-Type: text/html
Content-Length: 35
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
部分响应头部含义如下：
| 响应报头 | 含义 |
|---|---|
| Date | 告诉浏览器，请求页面的时间 |
| Server | 服务器软件信息 |
| Content-Length | 回送数据的字节数 |
| Content-Type | 回送内容的类型 |
| Expires | 表示存在时间，允许客户端在这个给时间之前不检查（发请求） |
| Cache-Control | 缓存控制 |
| X-Powered-By | 版权信息（程序支持） |
| Keep-Alive | 连接类型 |
| Location | 响应报头域用于重定向到一个新的位置 |
| Refresh | 页面刷新时间 |
| Last-modified | 指定服务器上保存内容的最后修订时间 |
（2-3）、响应消息体
响应正文信息，服务端一般会将要响应到客户端的正文信息放在这里，然后传递到客户端。
响应消息体的综合案例：
HTTP/1.1 200 OK
Date: Sun, 18 Oct 2009 08:56:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Sat, 20 Nov xxxx
ETag: "a5-2c-3e94b66c2e680"
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/html
X-Pad: avoid browser bug
(blank line)
<html><body><h1>It works!</h1></body></html>
三、HTTP 1、2、3
HTTP 的最初版本是 HTTP 0.9，因为需求简单，所以和服务器之间的通信过程也相对简单。
1、HTTP 1.0
HTTP 1.0 引入了请求头和响应头，主要是为了支持多种类型的文件下载。
HTTP 1.0 每进行一次 HTTP 通信，都需要经历建立 TCP 连接、传输 HTTP 数据 和 断开 TCP 连接三个阶段。
HTTP 1.0 还提供了 Cache 机制、用户代理、状态码等基础信息。
HTTP 1.0 的缺陷：每个 HTTP 通信都要建立一个 TCP 连接，这种一对一的模式会增加大量无谓的开销。
2、HTTP 1.1
HTTP 1.1 通过增加 持久连接 的方法来解决 HTTP 1.0 一个 HTTP 通信对一个 TCP 链接造成的无谓的开销大的问题。
HTTP 1.1 中是默认是开启持久连接的。浏览器默认允许同一个域名下可以同时建立 6 个 TCP 持久连接。在一个TCP连接上可以传输多个 HTTP 请求，只要浏览器或者服务器没有明确断开连接，那么该 TCP 连接会一直保持。若不想采用持久连接，可以在 HTTP 请求头中加上 Connection: close（默认为Connection:keep-alive）。
HTTP 1.1 还引入了Cookie、虚拟主机的支持、对动态内容的支持等特性。
HTTP 1.1 的缺陷：对带宽的利用率不高。
HTTP/1.1 很难将带宽用满，原因如下：
- TCP本身的机制导致：
- TCP 的慢启动。慢启动是 TCP 为了减少网络拥塞的一种策略。就像汽车启动一样，起步时会有一个提速过程。
- 多条 TCP 连接会竞争固定的带宽。
- HTTP 1.1 的机制导致：
- HTTP 1.1 队头阻塞的问题。
【拓展】队头阻塞：在 HTTP 1.1 中使用持久连接时，虽然能公用一个 TCP 管道，但是在一个管道中同一时刻只能处理一个请求，在当前的请求没有结束之前，其他的请求只能处于阻塞状态。这意味着我们不能 随意在一个管道中发送请求和接收内容。
3、HTTP 2.0
HTTP 2.0 采用 多路复用 来规避 TCP 的慢启动、TCP 连接间的竞争问题 和 队头阻塞问题。
HTTP 2.0 的思路就是：
- 用 “一个域名只使用一个 TCP ?连接来传输数据” 来解决 TCP 的慢启动问题 和 TCP 连接间的竞争问题。
- 用 “并行请求资源” 来消除队头阻塞问题。
【拓展】并行请求资源：在任何时候都可以将请求发送给服务器，而并不需要等待其他请求的完成，然后服务器也可以随时将处理好的请求资源返回给浏览器。
多路复用是通过在协议栈中添加二进制分帧层来实现的，有了二进制分帧层，赋予了 HTTP 2.0 一些额外的能力：
- 可以设置请求的优先级、
- 服务器推送、
- 头部压缩等特性。
HTTP 2.0 的缺陷：TCP 上的队头阻塞。
【拓展】虽然 HTTP 2.0 解决了 HTTP 1.1 中的队头阻塞问题，但是 HTTP 2.0 依然是基于 TCP 协议的，而 TCP 最初就是为了单连接而设计的，所以依然存在数据包级别的队头阻塞问题。在 TCP 传输过程中，由于单个数据包的丢失而造成的阻塞称为 “TCP上的队头阻塞”。
除了 TCP 队头阻塞之外，TCP 协议建立连接（握手）的过程也会带来“网络延迟”的问题。
【拓展】网络延迟又称为 RTT(Round Trip Time)。我们把从浏览器发送一个数据包到服务器，再从服务器返回数据包到浏览器的整个往返时间称为 RTT。RTT是反映网络性能的一个重要指标。
那建立 TCP 连接时，需要花费多少个 RTT 呢？
我们知道 HTTP 都使用 TCP 协议来传输的，在建立 TCP 连接的时，需要和服务器进行 3 次握手来确认连接成功，需要 1.5 个 RTT 之后才能进行数据传输。
而如果使用 HTTPS 的话，还要额外使用 TLS 协议进行 安全传输，而使用 TLS 也需要一个握手过程，TLS 有两个版本 TLS1.2 和 TLS1.3，每个版本建立连接所花的时间不同，大致是需要 1?2 个 RTT。
总之，在传输数据之前，我们需要花掉 3?4 个 RTT。如果浏览器和服务器的物理距离较远，那么 1 个 RTT 就可能需要 100 毫秒以上了，这种情况下整个握手过程需要 300?400 毫秒，这时用户就能明显地感受到“慢”了。
4、HTTP 3.0
TCP 协议的队头阻塞和建立连接延迟等缺点，碍于其难以改造，W3C 决定放弃 TCP、TLS 的包袱，基于 UDP 协议，实现了 QUIC 协议。
QUIC 协议（Quick UDP Internet Connections）：译为“快速 UDP 互联网连接”。是在 UDP 协议的基础上，实现了类似于 TCP 的多路数据流、传输可靠性等功能的协议。
HTTP 3.0 中的 QUIC 协议 有以下功能：
- 实现了类似 TCP 的流量控制、传输可靠性的功能——虽然 UDP 不提供可靠性的传输，但 QUIC 在 UDP 的基础 之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些 TCP 中存在的特性。
- 集成了 TLS 加密功能——目前 QUIC 使用的是 TLS1.3，相较于早期版本，TLS1.3 有更多的优点，其中最重要的 一点是减少了握手所花费的 RTT 个数。
- 实现了 HTTP 2.0 中的多路复用功能——和 TCP 不同，QUIC 实现了在同一物理连接上可以有多个独立的逻辑数 据流。实现了数据流的单独传输，就解决了 TCP 中队头阻塞的问题。
- 实现了快速握手功能——由于 QUIC 是基于 UDP 的，所以 QUIC 可以实现使用 0-RTT 或者 1-RTT 来建立连接， 这意味着 QUIC 可以用最快的速度来发送和接收数据，这样可以大大提升首次打开?面的速度。
HTTP 3.0 的挑战——在技术层面，HTTP 3.0 是个能够近乎完美的满足现阶段需求的协议。不过要将 HTTP 3.0 应用到实际环境中依然 面临着诸多严峻的挑战，这些挑战主要来自于以下三个方面：
- 目前，服务器和浏览器端都没有对 HTTP 3.0 提供比较完整的支持。
- 部署 HTTP 3.0 也存在着非常大的问题。因为系统内核对 UDP 的优化远远没有达到 TCP 的优化程度。
- 中间设备僵化的问题。这些设备对 UDP 的优化程度远远低于 TCP，据统计使用 QUIC 协议时，大约有 3%?7%的丢包率。
四、HTTPS
HTTPS HTTP 协议存在安全隐患。
HTTP 协议存在的安全隐患：
- 通信使用明文（不加密），内容可能被窃听。
- 无法证明报文的完整性，所以可能遭篡改。
- 不验证通信方的身份，因此有可能遭遇伪装。
HTTPS 是 HTTP 协议的安全版。它通常使用 TLS/SSL（传输层安全性协议/安全套接层）来加密客户端和服务器之间的通信 。被广泛用于网络安全中敏感的通讯，例如：交易支付方面。
HTTPS 主要作用是：
- 对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全;
- 对网站服务器进行真实身份认证。
HTTPS 的加密机制：散列函数 、对称加密和非对称加密。
【拓展】加密按对称性分为：对称密钥加密（也叫“私钥加密”） 和 非对称密钥加密（也叫“公钥加密”）。
1.私钥加密：加密和解密使用相同密钥的加密算法。这就有一定的概率导致“加密密钥和解密密钥是相同的”。没有非对称密钥加密安全。
2.公钥加密：该加密算法使用两个不同的密钥：加密密钥和解密密钥。前者公开，又称公开密钥，简称公钥。后者保密，又称私有密钥，简称私钥。
公钥加密的另一用途是“身份验证”：用私钥加密的信息，可以用公钥拷贝对其解密，接收者由此可知这条信息确实来自于拥有私钥的某人。
想了解 JS 的加密解密的方式请戳这里。
HTTPS 工作流程：
- TCP 三次握手；
- 客户端验证服务器数字证书，验证通过，继续下一步骤；（如果客户端配置了客户端验证，服务器方也可以验证客户端的身份）
- DH 算法协商对称加密算法的密钥、hash 算法的密钥；
- SSL 安全加密隧道协商完成；
- 网页以加密的方式传输，用协商好的对称加密算法和密钥加密，保证数据安全；
- 用协商好的 hash 算法进行数据完整性保护，保证数据不被篡改。
HTTPS 的优点：
- 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥。
- 数据完整性：内容传输经过完整性校验。
- 身份认证：第三方无法伪造服务端（客户端）身份。
HTTPS 的缺点：
- SSL 速度慢（相对于 HTTP）：通信慢、硬件资源消耗大导致处理速度变慢。不过目前硬件水平可基本忽略以上这两点。
- HTTPS 通信需要 CA 证书，大部分机构是收费的，不能确保数字证书认证机构的证书一定安全。
1、HTTP 与 HTTPS 的区别（🌟🌟🌟）
- HTTP 的 URL 以
http://开头，HTTPS 的 URL 以https://开头； - HTTP 不需要证书，HTTPS 需要 CA 证书；
- HTTP 是明文传输，HTTPS 加密传输；
- HTTP 和 HTTPS 都基于 TCP（以及 UDP）协议，但 HTTP 使用 TCP 协议
80 端口， HTTPS 使用 TCP 协议443 端口； - HTTP 直接和 TCP 通信，HTTPS 先和 TLS/SSL 通信再和 TCP 通信。
【参考资料】
先对HTTP规范入个门
HTTP1、HTTP2、HTTP3
HTTPS详解