HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS 在HTTP 的基础下加入SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。 所以，如果想说HTTPS，那么就要先说一下SSL/TLS，因为https是在ssl/tls基础上构架起来的。

一、背景

ssl/tls的历时几乎和互联网历史一样长，SSL（Secure Scokets Layer）叫做安全套接层，TLS(Transport Layer Security)叫做传输层安全协议。

1994年，网景公司设计了SSL1.0

1995年，SSL2.0发布，但是漏洞严重。

1996年，SSL3.0发布，开始大规模应用。

1999年，互联网开始标准化SSL，发布TLS1.0。

2006年，TLS发布1.1版本，叫做TLS1.1。

2008年。TLS发布TLS1.2版本。

就是说，TLS和SSL是一种东西的不同时代的叫法，现在习惯上称呼为“SSL/TLS”协议。SSL/TLS他为什么是安全的的，他安全传输的原理是什么。其实说白了，就是加密，传输加密内容。既然说到加密，就要从加密的算法开始说起。

二、加密

1、对称加密

其业务如下图，其原理就是：客户端和服务端使用同一个秘钥对传输内容加密/解密。在互联网传输中，其关键技术就是如何传送秘钥，因为密钥明文的传输，如果被劫持，那么加密都没啥用了。当然也有别的问题，比如如何存储秘钥，网页浏览器肯定不行，内容都是明文的公开的，app客户端也有一定的风险。

在互联网传中遗留了两个问题：a、如何安全的传送秘钥，b，如何安全的存储秘钥。

2、双向非对称加密

客户端和服务端都为自己准备一对公私秘钥（PubA与PriA，PubB与PriB），公钥是通过私钥计算出来的，单反过来不行，感兴趣的可以百度具体的数学算法。客户端、服务器把自己的公钥公开出去，私钥自己保留。这样客户端知道了服务器的公钥，服务器知道了客户端的公钥。在这个过程中，存在着验签和签名，加密和解密两个过程。验签和签名是为了防止串改，加密和解密是为了防止第三方拦截。如图：

在互联网传输中，其关键技术就是如何传送双方的公钥，还是和对称加密一样，如何传输依旧是大问题。

3、单项非对称加密以及TLS/SSL的原型

其实在互联网中，网站都是公开的，一般情况服务端没办法去验证每个客户端的合法性，只有客户端可以检验网站的合法性。比如各种类似淘宝、百度的钓鱼网站，真正的淘宝或百度服务端没办法也没必要去验证用户访问的是不是自己。在这种情况下，客户端并不需要公钥私钥对。其情形就类似于下图：

对于单向非对称加密，只有客户端到服务器是单向传输加密的，服务器传输回来却是明文，那么，如何保证安全呢？

答案：如果PubB是安全的的，我们只需要使用“单项非对称加密”+“对称加密”就可以解决传输信息安全问题。“单项非对称加密”用来传送对称加密的秘钥，正常通信后，使用对称加密进行信息交流。具体详情请继续往下看！所以，核心问题还是同之前两个加密方式一样，如何保证PubB的安全传递。

三、TLS/SSL的原型

假如，PubB传送给客户端是安全的。

在“假如安全”的条件下，PubB一定是安全传送给客户端的，那么PubB加密过的数据也是安全的。好了，PubB安全的发送给客户端后，如果客户端使用PubB加密一个“对称加密的秘钥”，发给服务端，此时服务端收到的“对称加密秘钥”也就是安全的。这样，客户端就可以和服务端使用“对称加密”进行传输交流了，对吧？这就是SSL/TLS的原型。如下图：

看到了把，假如PubB是安全的，我们并不需要十分复杂的双向非对称加密，我们只需要“单项非对称加密”+“对称加密”就能够完成安全传输了。那么问题来了，如何解决公钥传输安全的问题呢？请继续看。

 四、数字证书与证书认证中心实现了SSL/TLS

上个模块的第一句话就是“假如，PubB传送给客户端是安全的。”，所以我们需要来想个办法，证明客户端收到的公钥是服务器的公钥，并且这个公钥没有被别人串改。为了解决这个问题，引入了一个中间机构CA，CA类似现实中的“公证处”，从技术上讲，就是一个服务器。CA有一对公钥和私钥，公钥全网都知道。

数字证书认证其流程大致如下：

服务器把自己的公钥+个人信息发送给CA，CA给服务器办法一个数字证书（CA的私钥+服务器信息+服务器公钥计算的），服务器以后吧自己的证书保存在自己的服务器中。这个证书类似于现实中的身份证，当客户端请求服务器，服务器就把证书发给客户端，客户端用CA的公钥验签证书，如果合格合法没被串改，就提取其中的服务器公钥和服务器信息。如果验签不通过，则证明证书不合法，间接证明服务器公钥不合法。

小提示：我电脑是高分屏，截的图到网上就有点模糊

这就是整个SSL和TLS，如果我现在问你，客户端和服务器进行“SSL/TLS”模式的通信，前期至少“握手”几次？其实就是4次。为什么是四次？服务器申请证书不算吗？不算，因为服务器只是在网站部署的时候，申请一次证书，以后就不需要在申请了。具体流程如下图：

那么HTTPS几次握手啊？7次。HTTPS=TCP+SSL/TLS。大家都知道TCP有三次握手，加上SSL/TLS的四次，所以一共7次，或者说3.5个RTT（round trip time）。

但是，这其中有一个问题，就是谁来验证“CA”的真假与合法性，CA万一是假的咋办？答案是：给CA颁发证书。谁给CA颁发证书？答案是上一级CA...无限的找上级级颁发证书，想想都感觉不可思议。所以啊，咱们引入了“根证书”。这个“根证书”是有根证书服务器颁发的，是权威，是不需要验证的。就像谁去证明“公证处”合法？是政-府，谁去验证政-府合法？不需要验证！证书链验证如下图：

五、TCP为什么可靠？

1、为什么可靠

a、为什么不丢包？

答案：ACK机制，超时就重发。

b、如何不重复？

答案：客户端发送seq=x,服务端回复ACK=x+1。表示：小于等于x的我都收到了。如果序号小于等于x，就直接丢弃。

注：seq=x表示消息顺序为第x条，ACK=x+1。表示：小于等于x的我都收到了。

c、如何保证不错乱？

答案：假如共1~7个包发送给服务器，123先来，然后567也来了，4没来。那么就回复ACK=3+1,表示前三个已经收到，请发下一个（第四个）。服务器在不超时的情况下，会把567三个包也会被临时存放起来，一直等第四个包。超时后，服务器把567丢弃掉，等待客户端重发4567四个包。

2、链接和断开

a、三次握手是什么？

b、四次挥手是什么？