puppeteer知识汇总

HTTPS 是在 HTTP 上建立 SSL 加密层，并对传输数据进行加密，是 HTTP 协议的安全版。现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。
HTTPS使用的是TSL协议（SSL是TSL协议的一种）。

HTTPS 的功能

• 内容加密，对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全;
  • 非对称密钥加密：传输公钥时可能被截获并掉包，解决方案：使用第三方机构颁发的证书加密公钥（根据服务器地址等多个信息生成，无法被第三方伪造），浏览器收到后使用证书机构颁发的公钥进行解密（前提是浏览器要信任同一个证书颁发机构）解密结果与用证书生成的规则再生成一个签名对比一致就是真证书；
  • 对称密钥加密：中间人随意截获。
• 身份认证，对网站服务器进行真实身份认证。
  • 数字证书
• 数据完整性

我们经常会在 Web 的登录页面和购物结算界面等使用 HTTPS 通信。使用 HTTPS 通信时，不再用http://，而是改用https://。另外，当浏览器访问 HTTPS 通信有效的 Web 网站时，浏览器的地址栏内会出现一个带锁的标记。对 HTTPS 的显示方式会因浏览器的不同而有所改变。

对称加密

发送方和接收方需要持有同一把密钥，发送消息和接收消息均使用该密钥。相对于非对称加密，对称加密具有更高的加解密速度，但双方都需要事先知道密钥，密钥在传输过程中可能会被窃取，因此安全性没有非对称加密高。

非对称加密

接收方在发送消息前需要事先生成公钥和私钥，然后将公钥发送给发送方。发送放收到公钥后，将待发送数据用公钥加密，发送给接收方。接收到收到数据后，用私钥解密。
在这个过程中，公钥负责加密，私钥负责解密，数据在传输过程中即使被截获，攻击者由于没有私钥，因此也无法破解。
非对称加密算法的加解密速度低于对称加密算法，但是安全性更高。

几个名词要理清

• RSA：非对称加密
• AES：对称加密 生成一个随机字符串 key 只有客户端和服务端有 他们两个通过这个 key 对数据加密和传输跟解密 这一个统称对称加密
• CA：权威认证机构 服务器在建站的时候 去 CA 认证机构认证 得到对应的数字签名 相当于身份证号 客户端每次安装浏览器的时候 都会下载最新的 CA 列表 这个列表有对应的数字签名和服务器 IP 一一对应的列表 这就是为什么我们自己搭建的 localhost 没法发 https 的原因 因为没法进行 CA 认证
• 数字证书：包含了数字签名跟 RSA 公钥
• 数字签名：保证数字证书一定是服务器传给客户端的 相当于服务器的身份证 ID
• 对称密钥： 对数据进行加密的 key
• 非对称密钥： （k1， k2） k1 加密的数据 只有 k2 能解开 k1 位非对称公钥 k2 为非对称私钥
• 非对称公钥：RSA 公钥 k1 加密的数据 只有 k2 能解开
• 非对称私钥：RSA 私钥 k1 加密的数据 只有 k2 能解开

RSA 是一种广泛使用的非对称加密算法，严格来说并不等同于非对称加密，同样的对称加密算法除了 AES ，还有 DES，3DES 等等。

为什么需要 HTTPS

在 HTTP 协议中有可能存在信息窃取或身份伪装等安全问题。使用 HTTPS 通信机制可以有效地防止这些问题。

HTTP 协议存在的哪些问题

1、通信使用明文（不加密）——内容可能被窃听

由于 HTTP 本身不具备加密的功能，所以也无法做到对通信整体（使用 HTTP 协议通信的请求和响应的内容）进行加密。即，HTTP 报文使用明文（指未经过加密的报文）方式发送。
HTTP 明文协议的缺陷是导致数据泄露、数据篡改、流量劫持、钓鱼攻击等安全问题的重要原因。HTTP 协议无法加密数据，所有通信数据都在网络中明文“裸奔”。通过网络的嗅探设备及一些技术手段，就可还原 HTTP 报文内容。

2、无法证明报文的完整性——可能遭篡改

所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。由于 HTTP 协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。
换句话说，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。

3、不验证通信方的身份——有可能遭遇伪装

HTTP 协议中的请求和响应不会对通信方进行确认。在 HTTP 协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没有被 Web 服务器设定限制访问的前提下）
HTTP 协议无法验证通信方身份，任何人都可以伪造虚假服务器欺骗用户，实现“钓鱼欺诈”，用户无法察觉。

HTTPS 协议优势

反观 HTTPS 协议，它比 HTTP 协议相比多了以下优势（下文会详细介绍）:

• 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥
• 数据完整性：内容传输经过完整性校验
• 身份认证：第三方无法伪造服务端（客户端）身份

## HTTPS如何解决HTTP上述问题? HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL和TLS协议代替而已。
通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。简言之，**所谓HTTPS，其实就是身披SSL协议这层外壳的HTTP**。
 ### 1、解决内容可能被窃听的问题——加密 #### 方法1.对称加密 这种方式加密和解密同用一个密钥。加密和解密都会用到密钥。**没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了**。
以对称加密方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落人攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。 #### 方法2.非对称加密 公开密钥加密使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。顾名思义，**私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得**。
使用公开密钥加密方式，发送密文的一方使用**对方的公开密钥**进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。
非对称加密的特点是信息传输一对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信。
这种方式有以下缺点：

• 公钥是公开的，所以针对私钥加密的信息，黑客截获后可以使用公钥进行解密，获取其中的内容；
• 公钥并不包含服务器的信息，使用非对称加密算法无法确保服务器身份的合法性，存在中间人攻击的风险，服务器发送给客户端的公钥可能在传送过程中被中间人截获并篡改；
• 使用非对称加密在数据加密解密过程需要消耗一定时间，降低了数据传输效率；
  

方法 3.对称加密+非对称加密(HTTPS 采用这种方式)

使用对称密钥的好处是解密的效率比较快，使用非对称密钥的好处是可以使得传输的内容不能被破解，因为就算你拦截到了数据，但是没有对应的私钥，也是不能破解内容的。就比如说你抢到了一个保险柜，但是没有保险柜的钥匙也不能打开保险柜。那我们就将对称加密与非对称加密结合起来,充分利用两者各自的优势，在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。
具体做法是：发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，然后对方用自己的私钥解密拿到“对称的密钥”，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。所以，HTTPS 采用对称加密和非对称加密两者并用的混合加密机制。

2、解决报文可能遭篡改问题——数字签名

网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？—-校验数字签名。
数字签名有两种功效：

• 能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
• 数字签名能确定消息的完整性,证明数据是否未被篡改过。

数字签名如何生成:

接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用 HASH 函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
假设消息传递在 Kobe，James 两人之间发生。James 将消息连同数字签名一起发送给 Kobe，Kobe 接收到消息后，通过校验数字签名，就可以验证接收到的消息就是 James 发送的。当然，这个过程的前提是 Kobe 知道 James 的公钥。问题的关键的是，和消息本身一样，公钥不能在不安全的网络中直接发送给 Kobe,或者说拿到的公钥如何证明是 James 的。
此时就需要引入了证书颁发机构（Certificate Authority，简称 CA），CA 数量并不多，Kobe 客户端内置了所有受信任 CA 的证书。CA 对 James 的公钥（和其他信息）数字签名后生成证书。

3、解决通信方身份可能被伪装的问题——数字证书

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。

我们来介绍一下数字证书认证机构的业务流程：

• 服务器的运营人员向第三方机构 CA 提交公钥、组织信息、个人信息(域名)等信息并申请认证;
• CA 通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
• 如信息审核通过，CA 会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。 其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名;
• 客户端 Client 向服务器 Server 发出请求时，Server 返回证书文件;
• 客户端 Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。
• 客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任 CA 的证书信息(包含公钥)，如果 CA 不被信任，则找不到对应 CA 的证书，证书也会被判定非法。

HTTPS 工作流程

1.Client 发起一个 HTTPS（比如[https://juejin.im/user/5a9a9cdcf265da238b7d771c](https://juejin.im/user/5a9a9cdcf265da238b7d771c)）的请求，根据 RFC2818 的规定，Client 知道需要连接 Server 的 443（默认）端口。
2.Server 把事先配置好的公钥证书（public key certificate）返回给客户端。
3.Client 验证公钥证书：比如是否在有效期内，证书的用途是不是匹配 Client 请求的站点，是不是在 CRL 吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的 Root 证书或者 Client 内置的 Root 证书）。如果验证通过则继续，不通过则显示警告信息。
4.Client 使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给 Server。
5.Server 使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client 和 Server 双方都持有了相同的对称密钥。
6.Server 使用对称密钥加密“明文内容 A”，发送给 Client。
7.Client 使用对称密钥解密响应的密文，得到“明文内容 A”。
8.Client 再次发起 HTTPS 的请求，使用对称密钥加密请求的“明文内容 B”，然后 Server 使用对称密钥解密密文，得到“明文内容 B”。

HTTPS 工作原理

HTTPS 在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL 协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品，TLS/SSL 中使用了非对称加密，对称加密以及 HASH 算法。握手过程的简单描述如下：

• 浏览器将自己支持的一套加密规则发送给网站。
• 网站从中选出一组加密算法与 HASH 算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
• 获得网站证书之后浏览器要做以下工作：
  • a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
  • 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
  • 使用约定好的 HASH 计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。
• 4.网站接收浏览器发来的数据之后要做以下的操作：
  • a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证 HASH 是否与浏览器发来的一致。
  • b) 使用密码加密一段握手消息，发送给浏览器。
• 5.浏览器解密并计算握手消息的 HASH，如果与服务端发来的 HASH 一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。

HTTP 与 HTTPS 的区别

• HTTP 是明文传输协议，HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。

关于安全性，用最简单的比喻形容两者的关系就是卡车运货，HTTP 下的运货车是敞篷的，货物都是暴露的。而 https 则是封闭集装箱车，安全性自然提升不少。

• HTTPS 比 HTTP 更加安全，对搜索引擎更友好，利于 SEO,谷歌、百度优先索引 HTTPS 网页;
• HTTPS 需要用到 SSL 证书，而 HTTP 不用;
• HTTPS 标准端口 443，HTTP 标准端口 80;
• HTTPS 基于传输层，HTTP 基于应用层;
• HTTPS 在浏览器显示绿色安全锁，HTTP 没有显示。

HTTPS 的使用成本

HTTPS是一个大趋势

• 证书费用以及更新维护
  • 证书现在不贵，也有免费的；
• HTTPS 降低用户访问速度
  • 经过合理的优化（比如SPDY）和部署甚至可以比HTTP1.0快，不过这也是成本之一就是了；
• 消耗 CPU 资源，需要增加大量机器
  • 需要多次计算

HTTPS 对性能的影响

• 协议交互所增加的网络 RTP（往返时延）
• 加解密相关计算的耗时
  

网络耗时

HTTP只需要通过TCP的三次握手就能建立HTTP连接：
[
关于302自动跳转，这是因为，比如访问百度，我们输入网址全称而是输入baidu.com，所以会自动跳转至HTTPS，这本身也需要耗时；
并且跳转后，URI不一样了，浏览器要与服务器重新通过三次握手建立TCP连接；
之后还要进行TLS协商，比如密钥交换算法，对称加密算法，内容一致性校验算法，证书签名算法等等；浏览器获取到证书后，也需要校验证书的有效性，比如证书是否过期，是否撤销等等；
接着，浏览器首先获取证书里的CA域名如果该CA域名没有命中缓存，浏览器需要解析域名的DNS，这个DNS解析至少耗费一个RTP；
DNS解析到IP之后就要完成三次握手，建立CA站点的TCP连接，这又耗费一个RTP；
再接着浏览器发送OCSP请求，获取响应耗费一个RTP；

关于OCSP：在线证书状态协议，它是维护服务器和其他网络资源安全性的两种普遍模式之一，另外一个叫做CRL证书注销列表；当用户试图访问一个服务器的时候，在线证书状态协议发送一个对于证书状态信息的请求，服务器会回复一个有效、过期、未知的响应；协议规定了服务器和客户端应用程序通信的语法；在线证书协议给了用户到期证书一个宽限期，这样用户就可以在更新证书前的一段时间继续访问服务器，所以这里就需要发起一个对于证书状态的请求，也需要消耗一个RTP

最后就是TLS完全握手阶段2，这个阶段主要进行密钥协商，耗时一个RTP；随后进行应用层的TCP数据通信。

计算耗时

• 浏览器计算耗时；
• 服务器计算耗时。

HTTPS 常见问题

• HTTPS需要安装证书；
• 大型网站比如百度，从HTTP升级为HTTPS比较困难（不能因为升级而降低用户体验这样就本末倒置了）；
• HTTPS并不能解决所有安全问题（比如XSS攻击，木马等），只是能更加安全的传输数据。

影响 HTTP 网络请求的因素

• 带宽
• 延迟
  • 一条连接上只可发送一个请求；
  • 请求只能从客户端开始，客户端不可以接收除响应以外的指令；
  • 请求/响应头部不经压缩就发送，每次互相发送相同的头部造成的浪费很多；
  • 非强制压缩发送；