Johnny's blog

HTTPS

HTTP 的缺点

HTTP 在通信过程中会面临以下三种安全问题：

  • 通信使用明文（不加密），内容可能会被窃听。
  • 不验证通信方的身份，可能会遭遇伪装。
  • 无法验证报文的完整性，可能已经被篡改。

HTTPS

HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。

HTTPS = HTTP + 加密 + 认证 + 摘要

2.1 HTTPS 是身披 SSL （安全套接层）外壳的 HTTP

SSL和TLS(安全传输层协议)都是加密协议。

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL 和 TLS 协议代替而已。

通常，HTTP 直接和 TCP 通信。当使用 SSL 的时候，就先和 SSL 通信，再由 SSL 和 TCP 通信了。所以简而言之，HTTPS 就是身披 SSL 外壳的 HTTP 协议。

2.2 相互交换密钥的公开密钥加密技术

HTTPS 为什么同时要有对称加密和非对称加密两种加密方式？ 对称加密的密钥 => SK
1). 首先一定要明确HTTPS既有对称加密，又有非对称加密。
2).由于对称加密性能高速度快，因此在传输数据时（也就是对话内容）采用对称加密。
3).但是对称加密的密钥SK，既没办法预先设置（密钥不可能只有一把，服务器端维护大量密钥也不具备可行性），因此只能选择在对话前通过网络协商出一把新的SK。
4). 为了确保SK的传输安全，使用非对称加密来协商SK。

HTTPS 对称加密的密钥 SK 如何产生和传输？
通过第一个问题，我们知道了 HTTPS 分为2 个过程：
1.协商对称加密密钥 SK 的非对称加密阶段，称为TLS 握手阶段。
2.使用 SK 对数据（对话内容）进行对称加密的阶段，称为数据通信阶段。

过程 1TLS 握手阶段：协商密钥 SK。
基于非对称加密算法
基于专用密钥交换算法，常见有 DH、ECDH 等
基于共享的 secret，常见有 PSK，SRP 等
过程 2数据通信阶段：发送端首先用密钥 SK 对通信内容进行对称加密，接着通过网络传输出去；对端收到数据后，用 SK 先将数据解密，于是就得到了通信内容
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

2.2.1 共享密钥加密的困境

加密和解密使用同一个密钥的方式称为共享密钥加密（Common key crypto system），也被叫做对称密钥加密。

采用共享密钥加密方式加密时，需要将密钥一起发送给通信方，所以有需要考虑密钥传输的安全性，需要设法安全地保管密钥，这便是共享密钥加密方式的困扰。

2.2.2 使用两把密钥加密的公开密钥加密方式

公开密钥加密方式很好的解决了共享密钥加密方式的困扰。

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能被其他任何人知道，而公开密钥则可以任意传播，任何人都可以拿到。

使用公开密钥加密方式（非对称加密），发送密文的一方使用公钥进行加密处理，而接收方拿到被加密后的信息之后再使用自己的私钥进行解密。利用这种方式进行传输，就不需要发送密钥，也就不用担心密钥被攻击者拿走了。

2.2.3 HTTPS 采用混合加密机制

HTTPS 采用共享密钥加密方式和公开密钥加密方式混用的加密方式。

HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

如果密钥可以被安全传输，则 HTTPS 会考虑采用共享密钥加密方式，否则将采用公开密钥加密方式。这是因为公开密钥加密方式的速度比共享密钥加密方式要慢。HTTPS 充分地利用了两者的优点，将多种方法组合起来用于通信。在使用公开密钥加密方式交换密钥之后，之后的信息传输使用共享密钥加密方式。

2.3 证明公开密钥正确性的证书

数字证书用于主体身份验证。 数字证书=主体信息+数字签名。

因为无法证明公开密钥本身就是真的公开密钥，由CA(数字证书认证机构)颁发公开密钥证书。

下面讲解一下数字证书认证机构的业务流程：

  1. 服务器的运营人员会向数字机构提出公开密钥申请。
  2. CA 在认证申请者的身份信息之后，会对已申请的公开密钥进行数字签名。
  3. 然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书之后绑定在一起。
  4. 服务器会将这份 CA 颁发的公钥证书发送给客户端，以进行公钥加密方式通信，公钥证书也可叫做数字证书或者直接称为证书。

接到证书的客户端可使用 CA 的公钥对证书的数字签名进行认证，一旦验证通过，客户端便可确认两件事：

  • 认证服务器公钥的机构是真实有效的 CA 机构
  • 服务器的公钥是值得信任的

于是这就达到了确认公钥真实有效性的目的。

HTTPS的握手过程

SSL类似于TCP的三次握手，在HTTP链接建立之前进行四次握手，从而客户度和服务端沟通好HTTP传输时对称加密的密钥，SSL的四次握手其过程如下：

  1. 客户端请求建立SSL连接，发送支持的加密方式以及一个随机数client random给服务器；

  2. 服务器选择其中的一种加密方式，并且再加上另外一个随机数server random，和数字证书（其中有公钥），发送给客户端；

  3. 客户端确认这个数字证书是有效的，并且再生成一个新的随机数，将这个随机数用服务器发送给它的数字证书中的公钥进行加密发送给服务器；

  4. 服务器收到客户端的回复，利用自己的私钥进行解密，获得这个随机数，然后通过将前面这三个随机数以及他们协商的加密方式，计算生成一个对称密钥。

  5. 至此握手阶段完成，之后的会话他们就通过这个对称密钥进行加密传输。

HTTP2

HTTP 2.0 相比于 HTTP 1.X，可以说是大幅度提高了 web 的性能。

在 HTTP 1.X 中，为了性能考虑，我们会引入雪碧图、将小图内联、使用多个域名等等的方式。这一切都是因为浏览器限制了同一个域名下的请求数量，当页面中需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求数量时，剩余的资源需要等待其他资源请求完成后才能发起请求。

二进制分帧

帧：HTTP/2 数据通信的最小单位消息：指 HTTP/2 中逻辑上的 HTTP 消息。例如请求和响应等，消息由一个或多个帧组成。

流：存在于连接中的一个虚拟通道。流可以承载双向消息，每个流都有一个唯一的整数ID。

HTTP 2.0 中所有加强性能的核心点在于此。在之前的 HTTP 版本中，我们是通过文本的方式传输数据。在 HTTP 2.0 中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。

HTTP/2 中，同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。

多路复用

多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。

Header 压缩

在 HTTP 1.X 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。

在 HTTP 2.0 中，使用了 HPACK 压缩格式对传输的 header 进行编码，减少了 header 的大小。并在两端维护了索引表，用于记录出现过的 header ，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值。

服务端 Push

在 HTTP 2.0 中，服务端可以在客户端某个请求后，主动推送其他资源。

可以想象以下情况，某些资源客户端是一定会请求的，这时就可以采取服务端 push 的技术，提前给客户端推送必要的资源，这样就可以相对减少一点延迟时间。当然在浏览器兼容的情况下你也可以使用 prefetch 。

流的特性

并发性。一个 HTTP/2 连接上可以同时发多个帧，这一点和 HTTP/1 不同。这也是实现多路复用的基础。

自增性。流 ID 是不可重用的，而是会按顺序递增，达到上限之后又新开 TCP 连接从头开始。

双向性。客户端和服务端都可以创建流，互不干扰，双方都可以作为发送方或者接收方。

可设置优先级。可以设置数据帧的优先级，让服务端先处理重要资源，优化用户体验。

HTTP3

HTTP3的优化

http3

HTTP2的缺点

虽然 HTTP/2 解决了很多之前旧版本的问题，但是它还是存在一个巨大的问题，主要是底层支撑的 TCP 协议造成的。HTTP/2的缺点主要有以下几点：

  1. TCP 以及 TCP+TLS建立连接的延时
  2. TCP的队头阻塞并没有彻底解决

QUIC协议

QUIC 协议选择了 UDP，因为 UDP 本身没有连接的概念，不需要三次握手，优化了连接建立的握手延迟，同时在应用程序层面实现了 TCP 的可靠性，TLS 的安全性和 HTTP2 的并发性，只需要用户端和服务端的应用程序支持 QUIC 协议，完全避开了操作系统和中间设备的限制。

运行在 QUIC 之上的 HTTP 协议被称为 HTTP/3(HTTP-over-QUIC)

QUIC 协议(Quick UDP Internet Connection)基于 UDP，正是看中了 UDP 的速度与效率。同时 QUIC 也整合了 TCP、TLS 和 HTTP/2 的优点，并加以优化。

特点:

  1. 减少了握手的延迟(1-RTT 或 0-RTT)
  2. 多路复用，并且没有 TCP 的阻塞问题
  3. 连接迁移，(主要是在客户端)当由 Wifi 转移到 4G 时，连接不会被断开。

QUIC 解决队头阻塞问题的方法：

  1. QUIC 的传输单元是 Packet，加密单元也是 Packet，整个加密、传输、解密都基于 Packet，这样就能避免 TLS 的队头阻塞问题。
  2. QUIC 基于 UDP，UDP 的数据包在接收端没有处理顺序，即使中间丢失一个包，也不会阻塞整条连接，其他的资源会被正常处理。

QUIC 基于 UDP 怎么保证可靠性？

TCP 中通过三次握手，给每一份数据包添加序列，以及重试机制，保证可靠性。而 QUIC 在 UDP 的基础上，增加了一层实现 TCP 类似的功能。