一、前言：
先来观察这两张图，第一张访问域名 http://www.12306.cn，谷歌浏览器提示不安全链接，第二张是 https://kyfw.12306.cn/otn/regist/init，浏览器显示安全，为什么会这样子呢？2017 年 1 月发布的 Chrome 56 浏览器开始把收集密码或信用卡数据的 HTTP 页面标记为“不安全”，若用户使用 2017 年 10 月推出的 Chrome 62，带有输入数据的 HTTP 页面和所有以无痕模式浏览的 HTTP 页面都会被标记为“不安全”，此外，苹果公司强制所有 iOS App 在 2017 年 1 月 1 日前使用 HTTPS 加密。
二、HTTP 和 HTTPS 发展历史
什么是 HTTP?
超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于 TCP/IP 协议传输数据，互联网上应用最为广泛的一种网络协议，所有的 WWW 文件都必须遵守这个标准。设计 HTTP 的初衷是为了提供一种发布和接收 HTML 页面的方法。
发展历史：
版本 产生时间 内容 发展现状
HTTP/0.9 1991 年 不涉及数据包传输，规定客户端和服务器之间通信格式，只能 GET 请求 没有作为正式的标准
HTTP/1.0 1996 年 传输内容格式不限制，增加 PUT、PATCH、HEAD、 OPTIONS、DELETE 命令 正式作为标准
HTTP/1.1 1997 年 持久连接(长连接)、节约带宽、HOST 域、管道机制、分块传输编码 2015 年前使用最广泛
HTTP/2 2015 年 多路复用、服务器推送、头信息压缩、二进制协议等 逐渐覆盖市场
这个 Akamai 公司建立的一个官方的演示，使用 HTTP/1.1 和 HTTP/2 同时请求 379 张图片，观察请求的时间，明显看出 HTTP/2 性能占优势。
多路复用：通过单一的 HTTP/2 连接请求发起多重的请求-响应消息，多个请求 stream 共享一个 TCP 连接，实现多留并行而不是依赖建立多个 TCP 连接。
HTTP 报文格式
什么是 HTTPS？
《图解 HTTP》这本书中曾提过 HTTPS 是身披 SSL 外壳的 HTTP。HTTPS 是一种通过计算机网络进行安全通信的传输协议，经由 HTTP 进行通信，利用 SSL/TLS 建立全信道，加密数据包。HTTPS 使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。
PS:TLS 是传输层加密协议，前身是 SSL 协议，由网景公司 1995 年发布，有时候两者不区分。
参考连接：
1.https://kamranahmed.info/blog/2016/08/13/http-in-depth/
2.https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
3.https://tools.ietf.org/html/rfc1945
4.https://http2.github.io/http2-spec/
5.https://www.zhihu.com/question/34074946
三、HTTP VS HTTPS
HTTP 特点：
无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，比如访问一个网站需要反复进行登录操作
无连接：HTTP/1.1 之前，由于无状态特点，每次请求需要通过 TCP 三次握手四次挥手，和服务器重新建立连接。比如某个客户机在短时间多次请求同一个资源，服务器并不能区别是否已经响应过用户的请求，所以每次需要重新响应请求，需要耗费不必要的时间和流量。
基于请求和响应：基本的特性，由客户端发起请求，服务端响应
简单快速、灵活
通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性
下面通过一个简单的抓包实验观察使用 HTTP 请求传输的数据：
结果分析：HTTP 协议传输数据以明文形式显示
针对无状态的一些解决策略：
场景：逛电商商场用户需要使用的时间比较长，需要对用户一段时间的 HTTP 通信状态进行保存，比如执行一次登陆操作，在 30 分钟内所有的请求都不需要再次登陆。
通过 Cookie/Session 技术
HTTP/1.1 持久连接（HTTP keep-alive）方法，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态，在请求首部字段中的 Connection: keep-alive 即为表明使用了持久连接
HTTPS 特点：
基于 HTTP 协议，通过 SSL 或 TLS 提供加密处理数据、验证对方身份以及数据完整性保护
通过抓包可以看到数据不是明文传输，而且 HTTPS 有如下特点：
内容加密：采用混合加密技术，中间者无法直接查看明文内容
验证身份：通过证书认证客户端访问的是自己的服务器
保护数据完整性：防止传输的内容被中间人冒充或者篡改
**混合加密：**结合非对称加密和对称加密技术。客户端使用对称加密生成密钥对传输数据进行加密，然后使用非对称加密的公钥再对秘钥进行加密，所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘密秘钥，因此即使被黑客截取，由于没有私钥，无法获取到加密明文的秘钥，便无法获取到明文数据。
**数字摘要：**通过单向 hash 函数对原文进行哈希，将需加密的明文“摘要”成一串固定长度(如 128bit)的密文，不同的明文摘要成的密文其结果总是不相同，同样的明文其摘要必定一致，并且即使知道了摘要也不能反推出明文。
**数字签名技术：**数字签名建立在公钥加密体制基础上，是公钥加密技术的另一类应用。它把公钥加密技术和数字摘要结合起来，形成了实用的数字签名技术。
收方能够证实发送方的真实身份；
发送方事后不能否认所发送过的报文；
收方或非法者不能伪造、篡改报文。
非对称加密过程需要用到公钥进行加密，那么公钥从何而来？其实公钥就被包含在数字证书中，数字证书通常来说是由受信任的数字证书颁发机构 CA，在验证服务器身份后颁发，证书中包含了一个密钥对（公钥和私钥）和所有者识别信息。数字证书被放到服务端，具有服务器身份验证和数据传输加密功能。
四、HTTP 通信传输
客户端输入 URL 回车，DNS 解析域名得到服务器的 IP 地址，服务器在 80 端口监听客户端请求，端口通过 TCP/IP 协议（可以通过 Socket 实现）建立连接。HTTP 属于 TCP/IP 模型中的运用层协议，所以通信的过程其实是对应数据的入栈和出栈。
报文从运用层传送到运输层，运输层通过 TCP 三次握手和服务器建立连接，四次挥手释放连接。
为什么需要三次握手呢？为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
比如：client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段，但是 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求，于是就向 client 发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要 server 发出确认，新的连接就建立了，由于 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据，但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。所以没有采用“三次握手”，这种情况下 server 的很多资源就白白浪费掉了。
为什么需要四次挥手呢？TCP 是全双工模式，当 client 发出 FIN 报文段时，只是表示 client 已经没有数据要发送了，client 告诉 server，它的数据已经全部发送完毕了；但是，这个时候 client 还是可以接受来 server 的数据；当 server 返回 ACK 报文段时，表示它已经知道 client 没有数据发送了，但是 server 还是可以发送数据到 client 的；当 server 也发送了 FIN 报文段时，这个时候就表示 server 也没有数据要发送了，就会告诉 client，我也没有数据要发送了，如果收到 client 确认报文段，之后彼此就会愉快的中断这次 TCP 连接。
五、HTTPS 实现原理
SSL 建立连接过程
client 向 server 发送请求 https://baidu.com，然后连接到 server 的 443 端口，发送的信息主要是随机值 1 和客户端支持的加密算法。
server 接收到信息之后给予 client 响应握手信息，包括随机值 2 和匹配好的协商加密算法，这个加密算法一定是 client 发送给 server 加密算法的子集。
随即 server 给 client 发送第二个响应报文是数字证书。服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。传送证书，这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。
客户端解析证书，这部分工作是由客户端的 TLS 来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（预主秘钥）。
客户端认证证书通过之后，接下来是通过随机值 1、随机值 2 和预主秘钥组装会话秘钥。然后通过证书的公钥加密会话秘钥。
传送加密信息，这部分传送的是用证书加密后的会话秘钥，目的就是让服务端使用秘钥解密得到随机值 1、随机值 2 和预主秘钥。
服务端解密得到随机值 1、随机值 2 和预主秘钥，然后组装会话秘钥，跟客户端会话秘钥相同。
客户端通过会话秘钥加密一条消息发送给服务端，主要验证服务端是否正常接受客户端加密的消息。
同样服务端也会通过会话秘钥加密一条消息回传给客户端，如果客户端能够正常接受的话表明 SSL 层连接建立完成了。
问题：
1.怎么保证保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥呢？
2.证书如何安全传输，被掉包了怎么办？
数字证书内容
包括了加密后服务器的公钥、权威机构的信息、服务器域名，还有经过 CA 私钥签名之后的证书内容（经过先通过 Hash 函数计算得到证书数字摘要，然后用权威机构私钥加密数字摘要得到数字签名)，签名计算方法以及证书对应的域名。
验证证书安全性过程
当客户端收到这个证书之后，使用本地配置的权威机构的公钥对证书进行解密得到服务端的公钥和证书的数字签名，数字签名经过 CA 公钥解密得到证书信息摘要。
然后证书签名的方法计算一下当前证书的信息摘要，与收到的信息摘要作对比，如果一样，表示证书一定是服务器下发的，没有被中间人篡改过。因为中间人虽然有权威机构的公钥，能够解析证书内容并篡改，但是篡改完成之后中间人需要将证书重新加密，但是中间人没有权威机构的私钥，无法加密，强行加密只会导致客户端无法解密，如果中间人强行乱修改证书，就会导致证书内容和证书签名不匹配。
那第三方攻击者能否让自己的证书显示出来的信息也是服务端呢？（伪装服务端一样的配置）显然这个是不行的，因为当第三方攻击者去 CA 那边寻求认证的时候 CA 会要求其提供例如域名的 whois 信息、域名管理邮箱等证明你是服务端域名的拥有者，而第三方攻击者是无法提供这些信息所以他就是无法骗 CA 他拥有属于服务端的域名。
六、运用与总结
安全性考虑：
HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用
SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行
中间人攻击（MITM 攻击）是指，黑客拦截并篡改网络中的通信数据。又分为被动 MITM 和主动 MITM，被动 MITM 只窃取通信数据而不修改，而主动 MITM 不但能窃取数据，还会篡改通信数据。最常见的中间人攻击常常发生在公共 wifi 或者公共路由上。
成本考虑：
SSL 证书需要购买申请，功能越强大的证书费用越高
SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗（SSL 有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows XP 就不支持这个扩展，考虑到 XP 的装机量，这个特性几乎没用）。
根据 ACM CoNEXT 数据显示，使用 HTTPS 协议会使页面的加载时间延长近 50%，增加 10% 到 20% 的耗电。
HTTPS 连接缓存不如 HTTP 高效，流量成本高。
HTTPS 连接服务器端资源占用高很多，支持访客多的网站需要投入更大的成本。
HTTPS 协议握手阶段比较费时，对网站的响应速度有影响，影响用户体验。比较好的方式是采用分而治之，类似 12306 网站的主页使用 HTTP 协议，有关于用户信息等方面使用 HTTPS。
————————————————
版权声明：本文为 CSDN 博主「会飞的狗~」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/xiaoming100001/java/article/details/81109617
🐶 你走，我不送你。你来，风雨无阻，我去接你。