【网络面试篇】HTTP（2）（笔记）——http、https、http1.1、http2.0

HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了SSL/TLS 安全协议，使得报文能够加密传输。
HTTP 连接建立相对简单，TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

2. HTTPS 的工作原理？（https 是怎么建立连接的）

SSL/TLS 协议基本流程：

客户端向服务器索要并验证服务器的公钥。

双方协商生产「会话秘钥」。

双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是 TLS 握手阶段 。TLS的「握手阶段」涉及四次通信，使用不同的密钥交换算法，TLS 握手流程也会不一样的，现在常用的密钥交换算法有两种：RSA 算法和 ECDHE 算法。下图为 TLS 握手过程：

TLS 协议建立的详细流程：

（1）ClientHello

首先，由客户端向服务器发起加密通信请求，也就是ClientHello 请求。在这一步，客户端主要向服务器发送以下信息：

客户端支持的 TLS 协议版本，如 TLS 1.2 版本。
客户端生产的随机数（Client Random ），后面用于生成「会话秘钥」条件之一。
客户端支持的密码套件列表，如 RSA 加密算法。

（2）SeverHello

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：

确认 TLS 协议版本，如果浏览器不支持，则关闭加密通信。
服务器生产的随机数（Server Random ），也是后面用于生产「会话秘钥」条件之一。
确认的密码套件列表，如 RSA 加密算法。
服务器的数字证书。

（3）客户端回应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性 。如果证书没有问题，客户端会 从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

一个随机数（ pre-master key ）。该随机数会 被服务器公钥加密。
加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

上面第一项的随机数是整个握手阶段的第三个随机数，会发给服务端，所以这个随机数客户端和服务端都是一样的。服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key） ，接着就用双方协商的加密算法，各自生成本次通信的**「会话秘钥」**。

（4）服务器的最后回应

服务器收到客户端的第三个随机数（pre-master key）之后，通过 协商的加密算法 ，计算出本次通信的**「会话秘钥」**。然后，向客户端发送最后的信息：

加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

至此，整个 TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

综述

**客户端发送连接请求：**当客户端想要与服务器建立 HTTPS 连接时，它会发送一个连接请求到服务器的 443 端口，表明它想要使用 HTTPS 进行通信。

服务器响应： 服务器收到连接请求后，会发送一个 CA 数字证书 给客户端。这个证书包含了++服务器的公钥、证书的颁发者信息以及其他相关信息++。

客户端验证证书： 客户端接收到服务器发送的数字证书后，会 验证证书的合法性。这个过程包括验证证书的签名、证书是否过期、是否与预期域名匹配等。

生成会话密钥： 如果证书验证成功，客户端会生成一个用于该连接的 随机会话密钥（对称密钥）。这个密钥将用于加密通信数据。

用公钥加密会话密钥： 客户端使用服务器的公钥，将生成的会话密钥进行加密，并将加密后的会话密钥发送给服务器。

**服务器解密会话密钥：**服务器使用自己的私钥对客户端发送的加密会话密钥进行解密，获得会话密钥。

建立安全通信： 从此时开始，客户端和服务器都有了相同的会话密钥，他们使用 对称加密算法（如 AES）来加密和解密通信数据，保证了通信的隐私性和完整性。

3. HTTP1.0 和 HTTP1.1的区别？

（1）长连接

HTTP1.1 支持长连接，每一个 TCP 连接上可以传送多个 HTTP 请求和响应，默认开启 Connection:Keep-ALive。
HTTP1.0 默认为短连接，每次请求都需要建立一个 TCP 连接。

（2）缓存

HTTP1.0 主要使用 If-Modified-Since/Expires 来做为缓存判断的标准。
HTTP1.1 则引入了更多的缓存控制策略 例如 Entity tag / If-None-Match 等更多可供选择的缓存头来控制缓存策略。

（3）管道化

基于 HTTP1.1 的长连接，使得请求管线化成为可能。管线化使得请求能够 "并行" 传输，但是响应必须按照请求发出的顺序依次返回 ，性能在一定程度上得到了改善。（管道网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间）

（4）增加 Host 字段

使得一个服务器能够用来创建多个 web 站点。

（5）状态码

新增了 24 个错误状态响应码。

（6）带宽优化

HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。
HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content）。

4. HTTP2.0 与 HTTP1.1 的区别？

（1）二进制分帧

在应用层（HTTP/2.0）和传输层（TCP or UDP）之间增加一个二进制分帧层，从而突破 HTTP1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。

（2）多路复用（MultiPlexing）

允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息，这个强大的功能则是基于 "二进制分帧" 的特性。

（3）首部压缩

HTTP1.1 不支持 header 数据的压缩， HTTP/2.0 使用 HPACK 算法对 header 的数据进行压缩，这样数据体积小了，在网络上传输就会更快。高效的压缩算法可以很大的压缩 header，减少发送包的数量从而降低延迟。

（4）服务端推送（server push）

在 HTTP/2 中，服务器可以对客户端的一个请求发送多个响应，即 服务器可以额外的向客户端推送资源，而无需客户端明确的请求。

补充：详述 HTTP2.0 改进点

① 头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。

这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

② 二进制格式

HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）。

因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。

③ 并发传输

HTTP/1.1 的实现是基于请求-响应模型 的。++同一个连接中，HTTP 完成一个事务（请求与响应），才能处理下一个事务，也就是说在发出请求等待响应的过程中，是没办法做其他事情的++，如果响应迟迟不来，那么后续的请求是无法发送的，也造成了队头阻塞的问题。

HTTP/2 引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接。

从上图可以看到，++1 个 TCP 连接包含多个 Stream，Stream 里可以包含 1 个或多个 Message，Message 对应 HTTP/1 中的请求或响应，由 HTTP 头部和包体构成++ 。++Message 里包含一条或者多个 Frame，Frame 是 HTTP/2 最小单位，以二进制压缩格式存放 HTTP/1 中的内容（头部和包体）++。

针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream，也就是HTTP/2 可以并行交错地发送请求和响应。

如下图，服务端并行交错地发送了两个响应：Stream 1 和 Stream 3，这两个 Stream 都是跑在一个 TCP 连接上，客户端收到后，会根据相同的 Stream ID 有序组装成 HTTP 消息。

④ 服务器推送

HTTP/2 还在一定程度上改善了传统的「请求- 应答」工作模式，服务端不再是被动地响应，可以主动向客户端发送消息。

客户端和服务器双方都可以建立 Stream， Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。

如下图，Stream 1 是客户端向服务端请求的资源，属于客户端建立的 Stream，所以该 Stream 的 ID 是奇数（数字 1）；Stream 2 和 4 都是服务端主动向客户端推送的资源，属于服务端建立的 Stream，所以这两个 Stream 的 ID 是偶数（数字 2 和 4）。

再比如，客户端通过 HTTP/1.1 请求从服务器那获取到了 HTML 文件，而 HTML 可能还需要依赖 CSS 来渲染页面，这时客户端还要再发起获取 CSS 文件的请求，需要两次消息往返，如下图左边部分：

如上图右边部分，在 HTTP/2 中，客户端在访问 HTML 时，服务器可以直接主动推送 CSS 文件，減少了消息传递的次数。