https是http + ssl/tls的组合，主要是为了解决http明文传输不安全的问题(其实就是给内容加密了)。在了解https之前，默认大家都知道http，所以这里只先了解下ssl/tls是啥
ssl全称 secure sockets layer 是最初的用来解决http明文不安全的协议，tls全称 transport layer security 是标准化后的ssl，两者其实差不多，tls就是高版本的ssl而已，其实ssl和tls不仅仅加密http很多其他基于tcp协议的协议也可以使用ssl/tls加密，比如
然后再了解下加密解密，加密一般分为非对称加密和对称加密，非对称加密指的是加解密所需要的密钥不同，对成加密指的是加解密用同一个密钥(比如压缩软件的解压密码)。在性能上非对称加密要比对称加密差很多。
如何对http内容进行加密是https的关键
单纯的使用对称加密，浏览器和服务之间需要交换密钥，被人拿到密钥就GG了。
所以现在一般都是非对称加密和对称加密的混合方式，使用非对称加密加密对称加密的密钥。具体流程如下
- 服务端使用非对称加密生成两个密钥公钥 私钥，其中公钥用于加密传输数据，私钥用于解密传输数据
- 服务端将私钥保留，公钥发送给浏览器
- 浏览器先生成一个对称加密的密钥， 然后使用服务器发送过来的公钥加密客户端密钥 ，将加密后的客户端密钥 发送给服务端
- 服务端使用私钥 解密 获得浏览器生成的对称密钥。至此，双方可以愉快的通信了。
但是这里有个问题，服务端和客户端无法确定互相的身份，这就可以使用中间人攻击(其实就是让服务器认为攻击者就是浏览器，然后与攻击者进行了密钥的交换，同时攻击者伪造成服务器与浏览器进行通信)来截获服务端和客户端的信息(事实上，我们的代理工具都是使用中间人攻击来进行的https代理)
为了弥补这一缺点，浏览器会有身份认证机制，就是CA 证书。购买的CA会有几个文件，其中一个包含公钥（只是包含，文件中还会有证书机构的签名信息），就是非对称加密中负责加密的密钥，一个包含私钥，就是负责解密的密钥.
所以基于CA的https handshake长这样～
- 浏览器访问服务端，服务端将包含公钥的证书发给浏览器
- 浏览器验证证书（一般是通过系统的根证书来判别，在windows 里面通过运行界面打开certmgr.msc 就能看到现在系统信任的证书。mac里面貌似是key chain），验证如果不通过浏览器就会有此链接不安全的提示。
- ca如果没有问题，生成对称加密的密钥，使用ca中的公钥加密然后发送给服务端
- 服务端收到私钥，然后通过ca中的密钥解密，至此双方密钥交换成功可以安全发送数据
大致如下所示
image.png
注意这里其实还有一部分，获取客户端的公钥，这是在某些场景下需要客户端认证，比如有些网站有保密需要，需要对用户进行认证，所以这里也有一步可选的客户端认
这里可以稍微了解下证书的信任机制
信任链.jpg
密钥交换算法
终于到了解决这次发现的问题的关键点：https代理启动后，代理的cpu使用率飙升的原因。
首先我们了解下一个概念：前向保密/完美正向加密。这个算法具体就是可以生成一个临时的私钥进行对成加密的密钥交换。这是为了防范服务端的私钥被人破解，因为临时私钥即使被破解了，也只能获得一次会话的内容。目前最常用的两种前向保密算法有两种，DHE、ECDHE。不用了解具体算法是啥，我们的重点是，这个算法很耗性能！
好的，这个时候跑到nodejs的文档我们可以看到，nodejs的默认加密算法选用的是GCM+ECDHE|DHE+AES128，原文如下
The default cipher suite included within Node.js has been carefully selected to reflect current security best practices and risk mitigation. Changing the default cipher suite can have a significant impact on the security of an application. The
--tls-cipher-listswitch andciphersoption should by used only if absolutely necessary.
The default cipher suite prefers GCM ciphers for Chrome's 'modern cryptography' setting and also prefers ECDHE and DHE ciphers for perfect forward secrecy, while offering some backward compatibility.
128 bit AES is preferred over 192 and 256 bit AES in light of specific attacks affecting larger AES key sizes
所以这造成了 nodejs的tls.createSecureContext 方法会消耗大量的cpu去做加密计算。具体做法是，改变nodejs 的默认加密算法，从看到的文章来看，ciphers设置为"AES256-GCM-SHA384" 可以省去所有的基于DH 的前向保密算法的性能消耗，大约能快个40%+。
These ciphers can be changed to be less compute intensive. This is done in the https (or agent) options. For example:
var agent = new https.Agent({
"key": key,
"cert": cert,
"ciphers": "AES256-GCM-SHA384"
});
The key here is exclusion of the expensive Diffie-Hellman algorithms (i.e. DH, EDH, ECDH). With something like that, we can see a dramatic change in the sample:
（还没有时间去尝试就是了）具体这个协议是否可用，其实还是得使用tls.getCiphers()看是否支持，当然如果上述协议不支持，我们其实只需要从tls.getCiphers()中找一个最不吃cpu的加密协议就可以了。（虽然这可能也很困难）
参考：
网友评论