Https协议
虽然作为一个后端程序员，但是网络通信相关的知识也要了解一些。这篇来总结下Https协议，顺便复习下Http协议。
1. Http协议
HTTP协议全称Hyper Text Transfer Protocol，翻译过来就是超文本传输协议，位于TCP/IP四层模型当中的应用层。
HTTP协议通过请求/响应的方式，在客户端和服务端之间进行通信。
但是HTTP协议有一个致命的缺点：不够安全。HTTP协议的信息传输完全以明文方式。由于传输信息是明文，这个信息有可能被某个中间人恶意截获甚至篡改，这种行为叫做中间人攻击。
首先可以对明文信息进行加密，事先约定一种对称加密方式，并且约定一个随机生成的**。后续的通信中，信息发送方都使用**对信息加密，而信息接收方通过同样的**对信息解密。虽然我们在后续的通信中对明文进行了加密，但是第一次约定加密方式和**的通信仍然是明文，如果第一次通信就已经被拦截了，那么**就会泄露给中间人，中间人仍然可以解密后续所有的通信内容。而且如果服务器端对所有的客户端通信都使用同样的对称加密算法，无异于没有加密。
我们可以进一步使用非对称加密，为**的传输做一层额外的保护。非对称加密的一组秘钥对中，包含一个公钥和一个私钥。明文既可以用公钥加密，用私钥解密；也可以用私钥加密，用公钥解密。但是私钥加密后的密文，只要是公钥，都可以解密，而公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人
- 在客户端和服务端建立通信的时候，服务端首先把自己的公钥Key1发给客户端；
- 客户端收到公钥以后，生成一个用于对称加密的**Key2，并且用刚才接收的公钥Key1对Key2进行加密，发送给服务端
- 服务端利用自己非对称加密的私钥，解密客户端发送过来的利用Key1加了密的Key2，获得了Key2的内容。从此以后，客户端和服务端开始用加了密的Key2进行通信，在通信过程中，即使中间人在一开始就截获了公钥Key1，由于不知道私钥是什么，也无从解密。
但是中间人虽然不知道服务端的私钥是什么，但是在截获了服务端的公钥Key1之后，却可以自己另外生成一对公钥私钥，把自己的公钥Key3发送给客户端。客户端不知道公钥被换过，以为Key3就是服务端的公钥。于是按照先前的流程，用Key3加密了自己生成的对称加***Key2，发送给服务端。这一次通信再次被中间人截获，中间人先用自己的私钥解开了Key3的加密，获得Key2，然后再用当初服务端发来的Key1重新加密，再发给服务端。这样一来，客户端和服务端后续的通信尽管用Key2做了对称加密，但是中间人已经掌握了Key2，所以可以轻松进行解密。
2. Https核心思想
HTTPS同时需要对称加密算法和非对称加密算法，为了解决Http通信不安全的问题，这时候，有必要引入第三方：一个权威的证书颁发机构（CA）来解决。证书包含如下信息：
这里做了简化，只列出了一些关键信息。流程如下：
- 服务端首先把自己的公钥Key1发给证书颁发机构，向证书颁发机构申请证书。
- 证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密Key1，并且通过服务端网址等信息生成一个证书签名，中间人无法修改，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给了服务端。
- 当客户端向服务端请求通信的时候，服务端不再直接返回自己的公钥，而是把自己申请的证书返回给客户端。
- 客户端收到证书以后，要做的第一件事情是验证证书的真伪。需要说明的是，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以客户端只需要知道是哪个机构颁布的证书，就可以从本地找到对应的机构公钥，解密出证书签名。接下来，客户端按照同样的签名规则，自己也生成一个证书签名，如果两个签名一致，说明证书是有效的。验证成功后，客户端就可以放心地再次利用机构公钥，解密出服务端公钥Key1。
- 像之前一样，客户端生成自己的对称加***Key2，并且用服务端公钥Key1加密Key2，发送给服务端。
- 最后，服务端用自己的私钥解开加密，得到对称加***Key2。于是客户端和服务端开始用加了密的Key2进行通信。
Https在Http协议基础上增加了SSL安全层，上面的一系列认证流程就是在SSL层中完成的。
注：TLS协议，是SSL 3.0协议的升级版，和SSL协议的大体原理是相同的。