k's Learn Notes

密码学入门 了解即可

密码学的处理队里对象是数字和字符串。

  • 散列：一种数据一旦转换成其他形式将无法恢复的加密技术，不可逆。（md5，hash）
  • 加密：
    • 对称加密（AES, DES, 3DES）
    • 非对称加密（RSA）
    • 密钥交换算法

证书签发机构（CA）

CA: 大家都信任的第三方，用来做身份认证。签发数字证书。

一般的证书都是三级;第一级是根证书签发机构(CA), 第二级是二级签发机构,到最后才是证书; 根证书是内置到操作系统和浏览器里面的;

CA 的工作流程：

  1. 服务器 example.com 将从 CA 请求 TLS 证书，例如 Digicert。
  2. Digicert 将为 examples 创建证书，证书包含必要的数据，例如服务器名称，服务器公钥等。
  3. Digicert 将创建证书的哈希值（散列），并使用自己的私钥对其进行加密。
  4. 浏览器和操作系统自带 Digicert 等权威机构的公钥。
  5. 当浏览器接收到签名证书时，他将使用证书的公钥从签名生成哈希值，它还将使用证书中指定的散列算法生出证书的散列，如果两个哈希值相等，则认为签名验证成功并且是可信的。
  6. 现在浏览器可以使用证书中指定的 example.com 的公钥继续进行身份验证过程。

在这里，我们可以将 Digicert 称为 Root CA

服务器创建连接之后，是在 tcp 连接后，才能拿到证书。

SSL/TLS 协议

  1. TLS, 传输层安全协议，现在常用的，是由 SSL 协议衍生出来的。
  2. SSL, 安全套接层协议
  3. 在应用层与传输层的中间。

HTTPS 协议的安全性是有 SSL 协议实现的。

TLS 现在广泛使用 1.2 版本， 包含了 4 个核心子协议。

  • 握手协议
  • 密钥配置切换协议
  • 应用数据协议
  • 报警协议
  1. TLS 适用于对称密钥
  2. 对称密钥可以通过安全密钥交换算法共享（如：中间人攻击, A -> B -> C ）
  3. 如果请求被截获，密钥可能会被欺骗
  4. 使用数字签名进行身份验证
  5. 证书颁发机构和信任链

HTTPS 协议、SSL 协议、TLS 协议、握手协议的关系

  1. HTTPS 协议基于 SSL 协议，也就是带加密的 http 协议
  2. SSL 协议是一种记录协议，扩展性良好，可以很方便的添加子协议
  3. 握手协议是 SSL 协议的一个子协议
  4. TLS 是 SSL 的接班人

HTTPS 协议分析

TLS 握手步骤：

  1. ClientHello: 客户端发起连接，跟服务器进行协议的协商，将客户端所支持 SSL/TLS 最高版本号和算法结合发送给服务器；
  2. ServerHello: 服务器收到客户端后，选定双方都能支持的协议和算法。
  3. SendCertificate（可选）: 服务器将服务器的证书发送给客户端。 -> 在之前打开过网页，已验证过证书了，缓存内有，就不会再继续发送证书给客户端了。
  4. RequestCertificate（可选）:如果选择双向验证，服务器要向客户端请求客户端证书。
  5. ServerHelloDone: 服务器通知客户端协商结果。
  6. ResponseCertificate(可选): 如果选择双向验证，客户端要向服务器发送客户端证书。（有了第四步，一定会有第六步）
  7. ClientKeyExchange: 客户端使用服务器的公钥（证书里面的），对客户端公钥和密钥种子（密钥交换的随机数）进行加密，再发送给服务器。
  8. CertificateVerify(可选): 如果选择双向验证，客户端用本地私钥生成数字签名，发送给服务器，让服务器通过收到的客户端的公钥进行身份验证。
  9. CreateSecretKey: 通讯双方基于密钥种子等信息生成通讯密钥。

---- 上面都是明文加密 -----

  1. ChangeCipherSpec：客户端通知服务器已将通讯方式切换到加密模式
  2. Finished: 客户端做好加密通讯的准备
  3. ChangeCipherSpec： 服务器通知客户端已将通讯方式切换到加密模式
  4. Finished：服务器做好加密通讯的准备

---- 互相通知 -----

  1. Encrypted/DecryptedData：双方使用客户端密钥，通过对称加密算法对通讯内容进行加密
  2. CloseConnection： 通讯结束后，任何一方发出断开 SSL 连接的消息。

看图说话

TLS

简单理解TLS握手:

  1. 客户端发送 一个客户端生成的随机数(Client random)、协议版本号、所支持加密方法给服务端

  2. 服务端确认双方的加密方法，并给出服务端里的数字证书公钥和服务端生成随机数(Server random)

  3. 客户端确认证书有效，生成一个新的随机数(Premaster secret), 并使用数字证书的公钥，加密这个随机数，发送给服务端

  4. 服务端使用数字证书私钥解密客户端发过来的随机数

这样双方就知道了约定的加密方法了，生成对称密钥(Session Key)，然后接下来的对话就用 Session Key 进行。

HTTP2 协议分析

  1. HTTP/2 没有改动 HTTP 的应用语义。HTTP 方法、状态码、URL 和报头字段等核心概念一如往常。
  2. HTTP/2 修改了数据格式化，以及在客户端与服务器间的传输方式。
  3. HTTP/2 引入了新的二进制分帧层。

特点

  1. 使用二进制格式传输，更高效，紧凑
  2. 对报头压缩，降低开销
  3. 多路复用，一个网络连接实现并行请求
  4. 服务器主动推送，减少请求的延迟
  5. 默认使用加密

二进制分帧层

  1. HTTP/1.x： 以换行符作为纯文本的分隔符
  2. HTTP/2.0: 将所有传输的信息分割为消息和帧，并采用而二进制格式对它们进行编码。HTTP2 报头封一个帧，它叫 Header 帧。内容封一个帧，Data 帧。

客户端和服务器会替我们完成必要的分帧工作。

多路复用

在 http/1.x 中，如果客户端想要发起多个并行请求以提升性能，则必须使用多个 TCP 连接。这种模型也会导致队首阻塞，从而造成底层 TCP 连接的效率地下。

将 HTTP 消息分解成独立的帧，交错发送，在服务器端重新组装是 HTTP/2.0 最重要的一项增强。这个机制会在整个网络技术战中引发一系列的连锁反应，从而带来巨大的性能提升。

  1. 并行交错地发送多个请求，请求之间互不影响；
  2. 并行交错地发送多个响应，响应之间互不干扰；
  3. 使用一个连接并行发送多个请求和响应；
  4. 不必再为绕过 HTTP/1.x 限制而做很多工作；
  5. 消除不必需要的延迟和提高现有网络容量的利用率，从而减少页面的加载时间；

TIP

google、firefox 浏览器同域名请求的最大并发数为：6
safari 最大并发数为：4 每个浏览器都不同

服务器推送

服务器可以主动推送给客户端，一对多、一对一推送。换句话说，除了对最初的请求响应外，服务器还可以向客户端推送额外资源，而无需客户端明确的请求。

HTTP/2 打破了严格的请求响应语义，支持一对多和服务器发起的推送工作流；

推送资源可以进行以下处理：

  1. 有客户端缓存
  2. 在不同页面之间重用推送（在同个域下）
  3. 与其他资源一起复用
  4. 有服务器设定优先级
  5. 被客户端拒绝

伪头字段

伪头部字段是 http2 内置的几个特殊的以”:”开始的 key，用于替代 HTTP/1.x 中请求行/响应行中的信息，比如请求方法，响应状态码等。

头部压缩，请求一发送了所有的头部字段，第二个请求则只需要发送差异数据，这样可以减少冗余数据，降低开销。

  • :method 请求方法
  • :scheme 协议版本
  • :authority 域
  • :path 路径
  • :status 状态码

TIP

HTTP1.1 和 2 怎么切换：访问一个网站时，服务器主动发起升级协议的协商。客户端会向发送 1.1 的请求，服务器会发送协议升级协商的响应给客户端，客户端接收到了响应后，会自行决定是否需要升级。

了解 HTTP3

HTTP3 是个新玩意，谷歌搞出来的。

不向前兼容，运行在 QUIC 之上的 HTTP 协议被称为 HTTP/3。（HTTP-over-QUIC）

QUIC(Quick UDP Internet Connection)协议基于 UDP。

特点

  1. 减少了握手延迟
  2. 多路复用，并且没有 TCP 的阻塞问题
  3. 连接迁移（主要是在客户端内），当由 WIFI 切换到 4G 时，连接不会被断开
  • HTTP 标准里面没有 HTTP3 这个东西，目前还没有得到标准组织的承认
  • HTTP3 与 HTTP1.1 和 HTTP2 没有直接关系，也不是 http2 的扩展
  • HTTP3 将会是一个全新的 web 协议
  • HTTP3 目前处于制定和测试阶段

TCP 与 UDP

特点

UDP:

  1. 无连接，不需要握手，节省三次握手的时间。
  2. 不依靠链路，不依赖 HTTP 包序号，不按顺序传输，所以不会队首堵塞。
  3. 有单播、多播、广播功能，也就是不止支持一对一，多对一，多对一的方式。
  4. 面向报文，应用层交下来的报文，既不合并也不拆分，而是保留这些报文的边界。
  5. 不可靠性，由于是通行建立在无连接上，所以想发就可以发。
  6. 头部开销小，传输数据报文时是很高效的。

TCP：

  1. 按包顺序发送，接收也是按顺序接收。没有收到的包就会一直等待。
  2. 需要连接，三次握手，四次挥手；
  3. 面向字节流；
  4. 仅支持单播，每个 TCP 连接只有两个断点，只能点对点的数据传输；
  5. 可靠传输。TCP 为了保证报文传输的可靠，给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。
  6. 拥塞控制：当网络出现拥塞的时候，TCP 能够减小向网络注入数据的速率和数量，缓解拥塞。
  7. 全双工通行: TCP 允许通信双方的应用程序在任何时候都能发送请求，因为 TCP 连接两端都设有缓存，用来临时存放双向通信的数据。当然，TCP 可以允许发送一个数据段，也可以缓存一段时间以便一次发送更多的数据段（最大的数据段大小取决与 MSS【最大报文长度】）

对比

UDPTCP
是否连接无连接面向连接
是否可靠不可靠传输，不使用流量控制和拥塞控制可靠传输，使用流量控制和拥塞控制
连接对象个数支持一对一，一对多， 多对一和多对多交互通信仅支持一对一通行
传输方式面向报文面向字节流
首部开销首部开销小，仅 8 字节首部最小 20 字节，最大 60 字节
使用场景实施应用（IP 电话、视频会议、直播等）要求可靠传输的应用，如文件传输

总结：

  1. TCP 向上层提供面向连接的可靠服务，UDP 向上层提供无连接不可靠服务；
  2. 虽然 UDP 没有 TCP 传输来的准确，但是也可以在很多实时性要求高的地方有所作为；
  3. 对数据准确性要求高的，速度可以相对较慢的，可以选择 TCP；

队首阻塞

HTTP/1.1 和 HTTP/2 都存在队首阻塞(Head of line blocking)的问题。

HTTP/1.1 中，一个 TCP 连接同时传输 10 个请求，其中第 1、2、3 个请求已被服务器接收，若第 4 个请求丢失，那么后面的 5 ～ 10 个请求都会被堵塞，接收方会要求请求方重新发包。由于接收方无法知道包是否在传输过程中丢失，只有超时了，才会让发送方重新发送。在第 4 个请求未接收到时，不会处理第 5 个请求，所以造成阻塞。

而 UDP 是通过给包编号，发的时候不管顺序，接收的时候也不管顺序，等到组装的时候发现包丢失了，就会立马让发送方再重新发送，所以减少了等待时间。

HTTP/2 的多路复用虽然可以解决“请求”这个粒度的 阻塞，但是 HTTP/2 的基础 TCP 协议本身也存在队首阻塞的问题。
由于 HTTP/2 必须使用 HTTPS，而 HTTPS 使用的 TLS 协议也存在队首堵塞。

队首堵塞会导致 HTTP/2 在更容易丢包的弱网情况下比 HTTP/1.1 更慢。

另一优势是在移动端中，在 WIFI 和移动网络切换过程中，如果是 TCP 连接的时候，必须要先断开连接，因为切换成移动网络时，IP 已经更改，那就需要重新进行 TCP 连接，再发送。 而 QUIC 不同，在切换网络之前发送了 2 个包，服务器接收到了 2 个，此时组装的时候发现少包了，可以立刻找客户端要求重新发送包。不需要连接，所以减少了等待时间。

QUIC 解决队首堵塞的办法

QUIC 基于 UDP， UDP 数据包在服务器接收没有处理顺序，即使中间丢失了一个包，也不会被阻塞整条连接，其他资源的请求资源会被正常处理。

再加上 UDP 是无连接，不需要三次握手。

QUIC 的传输单元是 Packet， 加密单元也是 Packet，整个加密、解密、传输都基于 Packet，这样就可以避免队首堵塞。

Last Updated:
Contributors: kk