转载自：https://mp.weixin.qq.com/s/UiGEzXoCn3F66NRz_T9crA 原创： 涛哥 6月9日
层级层名 常用协议
7应用层HTTP/HTTPS、FTP、Socket、Telnet、SSH、SMTP、POP3、DHCP、DNS、NFS、SNMP
6表示层XDR、LPP
5会话层SSL/TLS、LDAP/DAP、RPC
4传输层TCP、UDP
3网络层IP、OSPF、ICMP、
2数据链路层以太网、令牌环、PPP、PPTP、L2TP、ARP、ATMP
1物理层物理线路、光纤、无线电
客户端执行https请求时，需要由TCP协议建立和释放连接。这就涉及TCP协议的三次握手和四次挥手。
注意：我们可能会经常看到“HTTP的三次握手”这个说法，其实这种说法不准确，HTTP是没有什么三次握手的，这个其实指的就是TCP的三次握手。
一、TCP的三次握手
TCP通过三次握手，建立连接
第一次：客户端发送一个唯一的数据包(SYNJ)给服务器，请求建立连接
第二次：服务器收到客户端的请求后，生成一个SYN J的回应包(ack J+1)和一个新的数据包（SYN K），发给客户端
第三次：客户端收到服务器返回的两个包后，针对服务器的SYN K包生成一个回应包（ack K+1）,并发送给服务器。至此，完成3步握手。这个过程，类似我们在信号不好的时候打电话的过程：
“喂，能听到我说话吗”
“我能听到，你能听到我吗”
“能听到”
...
注意，这里“能听到”包含了“听到”和“听懂”的两层意思。想象一下，你用中文，对方给你回了一个你听不懂的俄文，这个通话也就没有必要进行下去了。
二、TCP的四次挥手
TCP协议是一个全双工协议（可以同时进行收发），通过四次挥手关闭连接。
简单理解：
第一步：客户端发送FIN（M）报文给服务器，告诉对方，“我的数据发完了”。
第二步：服务器收到FIN（M）报文后，回给客户端一个ack（M+1）报文，告诉客户端，“好，我知道了”。
第三步：服务器发一个FIN（N）报文给客户端，告诉对方，“我的数据也发完了”。
第四步：客户端回应ack（N+1）,告诉服务器，“好，我知道了”，至此，连接结束。
这个过程类似两个人打完电话的结束过程。
A:我说完了
B:哦
B想了一下，也没什么要说的
B:我也说完了
A:好
通话结束，双方挂电话
HTTPS的设计
- 最开始状态
-
背景
最开始状态 - 目的: A发给B的hello消息包，即使被中间人拦截到了，也无法得知消息的内容
-
最简单的方式: 对称加密
对称加密
但是，在WWW环境下，我们的Web服务器的通信模型没有这么简单：
大家都知道了
这个有啥问题?
协商过程没有加密
-
非对称加密
特点:
私钥加密后的密文，只要是公钥，都可以解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人
公钥和私钥
所以HTTPS的第一层是使用非对称加密算法进行对称加密算法协商过程, 也就是说HTTPS同时需要对称加密算法和非对称加密算法
随机数的诞生
要达到Web服务器针对每个客户端使用不同的对称加密算法，同时，我们也不能让第三者知道这个对称加密算法是什么，怎么办？
使用随机数，就是使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一刻才确定加密算法。
- 如何得到公钥
2个方案
方案1: 服务器端将公钥发送给每一个客户端
方案2: 服务器端将公钥放到一个远程服务器，客户端可以请求得到
方案1的问题
使用第三方机构的公钥解决鸡生蛋蛋生鸡问题
我们不能直接将服务器的公钥传递给客户端，而是第三方机构使用它的私钥对我们的公钥进行加密后，再传给客户端。客户端再使用第三方机构的公钥进行解密
证书中只有服务器交给第三方机构的公钥，而且这个公钥被第三方机构的私钥加密了, 如果能解密，就说明这个公钥没有被中间人调包。因为如果中间人使用自己的私钥加密后的东西传给客户端，客户端是无法使用第三方的公钥进行解密的。
数字证书 = 服务器加密后的公钥
- 漏了一个场景
第三方机构不可能只给你一家公司制作证书，它也可能会给中间人这样有坏心思的公司发放证书。这样的，中间人就有机会对你的证书进行调包，客户端在这种情况下是无法分辨出是接收的是你的证书，还是中间人的。因为不论中间人，还是你的证书，都能使用第三方机构的公钥进行解密。像下面这样：
第三方机构向多家公司颁发证书的情况：
image.png
最终导致其它持有同一家第三方机构证书的中间人可以进行调包：
掉包
数字签名
要解决这个问题，我们首先要想清楚一个问题，辨别同一机构下不同证书的这个职责，我们应该放在哪？
只能放到客户端了。意思是，客户端在拿到证书后，自己就有能力分辨证书是否被篡改了。如何才能有这个能力呢？
我们从现实中找灵感。比如你是HR，你手上拿到候选人的学历证书，证书上写了持证人，颁发机构，颁发时间等等，同时证书上，还写有一个最重要的：证书编号！我们怎么鉴别这张证书是的真伪呢？只要拿着这个证书编号上相关机构去查，如果证书上的持证人与现实的这个候选人一致，同时证书编号也能对应上，那么就说明这个证书是真实的。
我们的客户端能不能采用这个机制呢？像这样：
可是，这个“第三方机构”到底是在哪呢？是一个远端服务？不可能吧？如果是个远端服务，整个交互都会慢了。所以，这个第三方机构的验证功能只能放在客户端的本地了。
客户端本地怎么验证证书呢
客户端本地怎么验证证书呢？答案是证书本身就已经告诉客户端怎么验证证书的真伪。
也就是证书上写着如何根据证书的内容生成证书编号。客户端拿到证书后根据证书上的方法自己生成一个证书编号，如果生成的证书编号与证书上的证书编号相同，那么说明这个证书是真实的。
同时，为避免证书编号本身又被调包，所以使用第三方的私钥进行加密。这地方有些抽象，我们来个图帮助理解：证书的制作如图所示。证书中的“编号生成方法MD5”就是告诉客户端：你使用MD5对证书的内容求值就可以得到一个证书编号。
当客户端拿到证书后，开始对证书中的内容进行验证，如果客户端计算出来的证书编号与证书中的证书编号相同，则验证通过：
但是第三方机构的公钥怎么跑到了客户端的机器中呢？世界上这么多机器。
其实呢，现实中，浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）。因为客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。
说到这里，想必大家已经知道上文所说的，证书就是HTTPS中数字证书，证书编号就是数字签名，而第三方机构就是指数字证书签发机构（CA）。
CA如何颁发数字证书给服务器端的
当我听到这个问题时，我误以为，我们的SERVER需要发网络请求到CA部门的服务器来拿这个证书。到底是我理解能力问题，还是。。
其实，问题应该是CA如何颁发给我们的网站管理员，而我们的管理员又如何将这个数字证书放到我们的服务器上。
上面一大堆工作都是为了让客户端与服务器端安全地协商出一个对称加密算法。这就是HTTPS中的SSL/TLS协议主要干的活。剩下的就是通信时双方使用这个对称加密算法进行加密解密。
能不能用一句话总结HTTPS？答案是不能，因为HTTPS本身实在太复杂。但是我还是尝试使用一段话来总结HTTPS:HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。
