（全文太长，太懒不想看，-_-b那就直接拉到底部看总结）
层级层名常用协议
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物理层物理线路、光纤、无线电
注意：我们可能会经常看到“HTTP的三次握手”这个说法，其实这种说法不准确，HTTP是没有什么三次握手的，这个其实指的就是TCP的三次握手。
一、TCP的三次握手（不想了解，可跳过）
TCP通过三次握手，建立连接
第一次：客户端发送一个唯一的数据包(SYNJ)给服务器，请求建立连接
第二次：服务器收到客户端的请求后，生成一个SYNJ的回应包(ackJ+1)和一个新的数据包（SYNK），发给客户端
“喂，能听到我说话吗”
“我能听到，你能听到我吗”
“能听到”
...
注意，这里“能听到”包含了“听到”和“听懂”的两层意思。想象一下，你用中文，对方给你回了一个你听不懂的俄文，这个通话也就没有必要进行下去了。
二、TCP的四次挥手（不想了解，可跳过）
TCP协议是一个全双工协议（可以同时进行收发），通过四次挥手关闭连接。
简单理解：
第一步：客户端发送FIN（M）报文给服务器，告诉对方，“我的数据发完了”。
第二步：服务器收到FIN（M）报文后，回给客户端一个ack（M+1）报文，告诉客户端，“好，我知道了”。
第三步：服务器发一个FIN（N）报文给客户端，告诉对方，“我的数据也发完了”。
第四步：客户端回应ack（N+1）,告诉服务器，“好，我知道了”，至此，连接结束。
A:我说完了
B:哦
B想了一下，也没什么要说的
B:我也说完了
A:好
三、HTTPS单向验证
TCP连接建立好后，对于HTTP而言，服务器就可以发数据给客户端。但是对于HTTPS，它还要运行SSL/TLS协议，SSL/TLS协议分两层，第一层是记录协议，主要用于传输数据的加密压缩；第二层是握手协议，它建立在第一层协议之上，主要用于数据传输前的双方身份认证、协商加密算法、交换密钥。
HTTPS验证过程就是SSL握手协议的交互过程。“HTTPS验证”这个说法其实不准确的，应该是“SSL验证”，这两种说法网上都能看到。
我们先从简单点的单向验证开始解释：
第一步：客户端发起ClientHello
1）客户端支持的SSL/TLS协议版本列表
2）支持的对称加密算法列表
3）客户端生成的随机数A
第二步：服务端回应SeverHello
服务器收到请求后，回应客户端，回应的内容主要有：
1）SSL/TLS版本。服务器会在客户端支持的协议和服务器自己支持的协议中，选择双方都支持的SSL/TLS的最高版本，作为双方使用的SSL/TLS版本。如果客户端的SSL/TLS版本服务器都不支持，则不允许访问
2）与1类似，选择双方都支持的最安全的加密算法。
3）从服务器密钥库中取出的证书
4）服务器端生成的随机数B
第三步：客户端回应
客户端收到后，检查证书是否合法，主要检查下面4点：
1、检查证书是否过期
2、检查证书是否已经被吊销。
有CRL和OCSP两种检查方法。CRL即证书吊销列表，证书的属性里面会有一个CRL分发点属性，如下图所示（CSDN的证书），这个属性会包含了一个url地址，证书的签发机构会将被吊销的证书列表展现在这个url地址中；OCSP是在线证书状态检查协议，客户端直接向证书签发机构发起查询请求以确认该证书是否有效。
3、证书是否可信。
客户端会有一个信任库，里面保存了该客户端信任的CA（证书签发机构）的证书，如果收到的证书签发机构不在信任库中，则客户端会提示用户证书不可信。
若客户端是浏览器，各个浏览器都会内置一些可信任的证书签发机构列表，在浏览器的设置中可以看到。
如果不在信任表中，则浏览器会出现类似下面的警告页面，提示你不安全。（当然，你可以选择继续访问）
若客户端是程序，例如Java中，需要程序配置信任库文件，以判断证书是否可信，如果没设置，则默认使用jdk自带的证书库（jre\lib\security\cacerts,默认密码changeit）。如果证书或签发机构的证书不在信任库中，则认为不安全，程序会报错。（你可以在程序中设置信任所有证书，不过这样并不安全）。
4、检查收到的证书中的域名与请求的域名是否一致。
若客户端是程序，这一项可配置不检查。若为浏览器，则会出现警告，用户也可以跳过。
证书验证通过后，客户端使用特定的方法又生成一个随机数c，这个随机数有专门的名称“pre-masterkey”。接着，客户端会用证书的公钥对“pre-masterkey”加密，然后发给服务器。
第四步，服务器的最后回应
服务器使用密钥库中的私钥解密后，得到这个随机数c。此时，服务端和客户端都拿到了随机数a、b、c，双方通过这3个随机数使用相同的DH密钥交换算法计算得到了相同的对称加密的密钥。这个密钥就作为后续数据传输时对称加密使用的密钥。
服务器回应客户端，握手结束，可以采用对称加密传输数据了。
这里注意几点：
1、整个验证过程，折腾了半天，其实是为了安全地得到一个双方约定的对称加密密钥，当然，过程中也涉及一些身份认证过程。既然刚开始时，客户端已经拿到了证书，里面包含了非对称加密的公钥，为什么不直接使用非对称加密方案呢，这是因为非对称加密计算量大、比较耗时，而对称加密耗时少。
2、对称加密的密钥只在这次连接中断前有效，从而保证数据传输安全。
4、什么是信任库和密钥库。信任库前面已经说了，它是用来存放客户端信任的CA的证书。在程序交互中，需要确保你访问的服务器的证书在你的信任库里面。密钥库是用来存放服务器的私钥和证书。
5、中间人攻击问题。前面过程说明中，有一点，客户端是验证有问题的时候，是可以选择继续的。对浏览器而言，用户可以选择继续访问；对程序而言，有些系统为了处理简单，会选择信任所有证书，这样就给中间人攻击提供了漏洞。
中间人攻击时，它想办法拦截到客户端与服务器之间的通信。在客户端向服务器发信息时，中间人首先伪装成客户端，向真正的服务器发消息，获得真正的证书，接着伪装成服务器将自己的伪证书发给客户端。服务器向客户端发消息时，中间人伪装成客户端，接收消息，然后再伪装成服务器向客户端发消息。最后验证过程完成后，客户端的真实对称密钥被中间人拿到，而真正的服务器拿到的是中间人提供的伪密钥。后续数据传输过程中的数据就会被中间人窃取。
四、HTTPS双向验证
单向验证过程中，客户端会验证自己访问的服务器，服务器对来访的客户端身份不做任何限制。如果服务器需要限制客户端的身份，则可以选择开启服务端验证，这就是双向验证。从这个过程中我们不难发现，使用单向验证还是双向验证，是服务器决定的。
一般而言，我们的服务器都是对所有客户端开放的，所以服务器默认都是使用单向验证。如果你使用的是Tomcat服务器，在配置文件server.xml中，配置Connector节点的clientAuth属性即可。若为true，则使用双向验证，若为false，则使用单向验证。如果你的服务，只允许特定的客户端访问，那就需要使用双向验证了。
双向验证基本过程与单向验证相同，不同在于：
1）第二步服务器第一次回应客户端的SeverHello消息中，会要求客户端提供“客户端的证书”
2）第三步客户端验证完服务器证书后的回应内容中，会增加两个信息：
1、客户端的证书
2、客户端证书验证消息（CertificateVerifymessage）：客户端将之前所有收到的和发送的消息组合起来，并用hash算法得到一个hash值，然后用客户端密钥库的私钥对这个hash进行签名，这个签名就是CertificateVerifymessage
3）服务器收到客户端证书后：
a）确认这个证书是否在自己的信任库中（当然也会校验是否过期等信息），如果验证不通过则会拒绝连接；
b）用客户端证书中的公钥去验证收到的证书验证消息中的签名。这一步的作用是为了确认证书确实是客户端的。
所以，在双向验证中，客户端需要用到密钥库，保存自己的私钥和证书，并且证书需要提前发给服务器，由服务器放到它的信任库中。
五、总结一下：
1、单向验证中，如果是你客户端，你需要拿到服务器的证书，并放到你的信任库中；如果是服务端，你要生成私钥和证书，并将这两个放到你的密钥库中，并且将证书发给所有客户端。
2、双向验证中，如果你是客户端，你要生成客户端的私钥和证书，将它们放到密钥库中，并将证书发给服务端，同时，在信任库中导入服务端的证书。如果你是服务端，除了在密钥库中保存服务器的私钥和证书，还要在信任库中导入客户端的证书。
3、再次强调，使用单向验证还是双向验证，是服务器决定的。
SSL握手：1.客户单发送hello，这个hello里面有：我是IE浏览器，我支持什么算法des等，SSL/TLS协议版本，随机数A。2.server回hello包，选择一个算法des（加密数据使用），server回证书（证书有server的公钥），随机数B3.客户端验证证书，随机数C，用公钥加密，发送证书。4.服务器验证证书，服务端用私钥解密得到C,客户端和服务端都有abc3个随机数了。使用abc3个随机数生成数据对称加密密钥。现在密钥和加密算法都选择好了，模式变更，后面的数据都开始加密。
随机数是在第一个请求就开始传输了，非对称加密（客户端用证书公钥加密随机数C服务端用证书私钥解密随机数C）。数据加密要密钥和加密算法对称加密。
客户端模式变更：就是之前没有加密，后面的数据包都要加密了，你去解密。服务端模式变更：就是之前没有加密，后面的数据包都要加密了，你去解密。