HTTP 与 HTTPS 协议
一 TTP和HTTPS发展历史
1.1 什么是 HTTP？
全称是Hypertext Transfer Protocol Vertion(超文本传输协议)，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。
发展历史
image.png
多路复用：通过单一的HTTP/2连接请求发起多重的请求-响应消息，多个请求stream共享一个TCP连接，实现多留并行而不是依赖建立多个TCP连接。
1.2 什么是HTTPS？
HTTPS的全称是Secure Hypertext Transfer Protocol（安全超文本传输协议），《图解HTTP》这本书中曾提过HTTPS是身披SSL外壳的HTTP。HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。
它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的 安全版。 它是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作，并返回网络上传送回的结果。HTTPS实际上应用了Netscape的安 全套接字层（SSL）作为HTTP应用层的子层。（HTTPS使用端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信。）SSL使 用40 位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X.509数字认证，如果需要的话用户可以确认发送者是谁。
二 HTTP VS HTTPS
2.1 HTTP特点：
-
无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，比如访问一个网站需要反复进行登录操作
-
无连接：HTTP/1.1之前，由于无状态特点，每次请求需要通过TCP三次握手四次挥手，和服务器重新建立连接。比如某个客户机在短时间多次请求同一个资源，服务器并不能区别是否已经响应过用户的请求，所以每次需要重新响应请求，需要耗费不必要的时间和流量。
-
基于请求和响应：基本的特性，由客户端发起请求，服务端响应
-
简单快速、灵活
-
通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性
结果分析：HTTP协议传输数据以明文形式显示
2.2 HTTPS特点：
基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护
-
内容加密：采用混合加密技术，中间者无法直接查看明文内容
-
验证身份：通过证书认证客户端访问的是自己的服务器
-
保护数据完整性：防止传输的内容被中间人冒充或者篡改
混合加密：结合非对称加密和对称加密技术。客户端使用对称加密生成密钥对传输数据进行加密，然后使用非对称加密的公钥再对秘钥进行加密，所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘密秘钥，因此即使被黑客截取，由于没有私钥，无法获取到加密明文的秘钥，便无法获取到明文数据。
数字摘要：通过单向hash函数对原文进行哈希，将需加密的明文“摘要”成一串固定长度(如128bit)的密文，不同的明文摘要成的密文其结果总是不相同，同样的明文其摘要必定一致，并且即使知道了摘要也不能反推出明文。
数字签名技术：数字签名建立在公钥加密体制基础上，是公钥加密技术的另一类应用。它把公钥加密技术和数字摘要结合起来，形成了实用的数字签名技术。
- 收方能够证实发送方的真实身份；
- 发送方事后不能否认所发送过的报文；
- 收方或非法者不能伪造、篡改报文。
2.3 HTTPS解决的问题：
1. 信任主机的问题
采用https 的server 必须从CA 申请一个用于证明服务器用途类型的证书. 改证书只有用于对应的server 的时候，客户度才信任次主机。所以目前所有的银行系统网站，关键部分应用都是https 的，客户通过信任该证书，从而信任了该主机，其实这样做效率很低，但是银行更侧重安全。这一点对我们没有任何意义，我们的server 采用的证书不管自己issue 还是从公众的地方issue，客户端都是自己人，所以我们也就肯定信任该server。
2. 通讯过程中的数据的泄密和被窜改
- 2.1 一般意义上的https, 就是 server 有一个证书.
- a.主要目的是保证server 就是他声称的server. 这个跟第一点一样.
- b.服务端和客户端之间的所有通讯，都是加密的.
- i.具体讲，是客户端产生一个对称的密钥，通过server 的证书来交换密钥，一般意义上的握手过程。
- ii.加下来所有的信息往来就都是加密的，第三方即使截获，也没有任何意义，因为他没有密钥，当然窜改也就没有什么意义了。
- 2.2 少许对客户端有要求的情况下，会要求客户端也必须有一个证书。
- a.这里客户端证书，其实就类似表示个人信息的时候，除了用户名/密码， 还有一个CA 认证过的身份，个人证书一般来说上别人无法模拟的，所有这样能够更深的确认自己的身份。
- b.目前少数个人银行的专业版是这种做法，具体证书可能是拿U盘作为一个备份的载体。
2.4 HTTPS和HTTP的区别：
https协议需要到ca申请证书，一般免费证书很少，需要交费。
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式用的端口也不一样，前者是80，后者是443。
http的连接很简单，是无状态的。
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
三 HTTP 通信传输
客户端输入URL回车，DNS解析域名得到服务器的IP地址，服务器在80端口监听客户端请求，端口通过TCP/IP协议（可以通过Socket实现）建立连接。HTTP属于TCP/IP模型中的运用层协议，所以通信的过程其实是对应数据的入栈和出栈。
image
报文从运用层传送到运输层，运输层通过TCP三次握手和服务器建立连接，四次挥手释放连接。
image
为什么需要三次握手呢？为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
比如：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段，但是server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求，于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了，由于client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据，但server却以为新的运输连接已经建立，并一直等待client发来数据。所以没有采用“三次握手”，这种情况下server的很多资源就白白浪费掉了。
image
为什么需要四次挥手呢？
TCP是全双工模式，当client发出FIN报文段时，只是表示client已经没有数据要发送了，client告诉server，它的数据已经全部发送完毕了；但是，这个时候client还是可以接受来server的数据；当server返回ACK报文段时，表示它已经知道client没有数据发送了，但是server还是可以发送数据到client的；当server也发送了FIN报文段时，这个时候就表示server也没有数据要发送了，就会告诉client，我也没有数据要发送了，如果收到client确认报文段，之后彼此就会愉快的中断这次TCP连接。
五 HTTPS实现原理
5b503d10e4b0edb750e0d4f8.png
-
client向server发送请求https://baidu.com，然后连接到server的443端口。
-
服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。
-
传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。
- 客户端解析证书
这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（秘钥）。然后用证书对该随机值进行加密。
- 传送加密信息
这部分传送的是用证书加密后的秘钥，目的就是让服务端得到这个秘钥，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
- 服务段加密信息
服务端用私钥解密秘密秘钥，得到了客户端传过来的私钥，然后把内容通过该值进行对称加密。
- 传输加密后的信息
这部分信息是服务端用私钥加密后的信息，可以在客户端被还原。
- 客户端解密信息
客户端用之前生成的私钥解密服务端传过来的信息，于是获取了解密后的内容。
六 运用与总结
6.1 安全性考虑：
HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用
SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行
中间人攻击（MITM攻击）是指，黑客拦截并篡改网络中的通信数据。又分为被动MITM和主动MITM，被动MITM只窃取通信数据而不修改，而主动MITM不但能窃取数据，还会篡改通信数据。最常见的中间人攻击常常发生在公共wifi或者公共路由上。
6.2 成本考虑：
-
SSL证书需要购买申请，功能越强大的证书费用越高
-
SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。
-
根据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电。
-
HTTPS连接缓存不如HTTP高效，流量成本高。
-
HTTPS连接服务器端资源占用高很多，支持访客多的网站需要投入更大的成本。
-
HTTPS协议握手阶段比较费时，对网站的响应速度有影响，影响用户体验。比较好的方式是采用分而治之，类似12306网站的主页使用HTTP协议，有关于用户信息等方面使用HTTPS。
6.3 HTTPS 对访问速度的影响
在介绍速度优化策略之前，先来看下 HTTPS 对速度有什么影响。影响主要来自两方面：
-
协议交互所增加的网络 RTT(round trip time)。
-
加解密相关的计算耗时。
6.3.1 网络耗时增加
- HTTP 首个请求的网络耗时
用户只需要完成 TCP 三次握手建立 TCP 连接就能够直接发送 HTTP 请求获取应用层数据，此外在整个访问过程中也没有需要消耗计算资源的地方。
HTTP 耗时 = TCP 握手
- HTTPS 首次请求需要的网络耗时
HTTPS耗时 = TCP 握手 + SSL 握手
HTTPS 首次请求需要的网络耗时解释如下：
- 1 三次握手建立 TCP 连接。耗时一个 RTT。
- 2 使用 HTTP 发起 GET 请求，服务端返回 302 跳转到 https://www.baidu.com。需要一个 RTT 以及 302 跳转延时。
- a) 大部分情况下用户不会手动输入 https://www.baidu.com 来访问 HTTPS，服务端只能返回 302 强制浏览器跳转到 https。
- b) 浏览器处理 302 跳转也需要耗时。
- 3 三次握手重新建立 TCP 连接。耗时一个 RTT。
- a) 302 跳转到 HTTPS 服务器之后，由于端口和服务器不同，需要重新完成三次握手，建立 TCP 连接。
- 4 TLS 完全握手阶段一。耗时至少一个 RTT。
- a) 这个阶段主要是完成加密套件的协商和证书的身份认证。
- b) 服务端和浏览器会协商出相同的密钥交换算法、对称加密算法、内容一致性校验算法、证书签名算法、椭圆曲线（非 ECC 算法不需要）等。
- c) 浏览器获取到证书后需要校验证书的有效性，比如是否过期，是否撤销。
- 5 解析 CA 站点的 DNS。耗时一个 RTT。
- a) 浏览器获取到证书后，有可能需要发起 OCSP 或者 CRL 请求，查询证书状态。
- b) 浏览器首先获取证书里的 CA 域名。
- c) 如果没有命中缓存，浏览器需要解析 CA 域名的 DNS。
- 6 三次握手建立 CA 站点的 TCP 连接。耗时一个 RTT。
- a) DNS 解析到 IP 后，需要完成三次握手建立 TCP 连接。
- 7 发起 OCSP 请求，获取响应。耗时一个 RTT。
- 8 完全握手阶段二，耗时一个 RTT 及计算时间。
- a) 完全握手阶段二主要是密钥协商。
- 9 完全握手结束后，浏览器和服务器之间进行应用层（也就是 HTTP）数据传输。
当然不是每个请求都需要增加 7 个 RTT 才能完成 HTTPS 首次请求交互。大概只有不到 0.01% 的请求才有可能需要经历上述步骤，它们需要满足如下条件：
- 必须是首次请求。即建立 TCP 连接后发起的第一个请求，该连接上的后续请求都不需要再发生上述行为。
- 必须要发生完全握手，而正常情况下 80% 的请求能实现简化握手。
- 浏览器需要开启 OCSP 或者 CRL 功能。Chrome 默认关闭了 ocsp 功能，firefox 和 IE 都默认开启。
- 浏览器没有命中 OCSP 缓存。Ocsp 一般的更新周期是 7 天，firefox 的查询周期也是 7 天，也就说是 7 天中才会发生一次 ocsp 的查询。
- 浏览器没有命中 CA 站点的 DNS 缓存。只有没命中 DNS 缓存的情况下才会解析 CA 的 DNS。
6.3.2 计算耗时增加
前面只是简单描述了 HTTPS 关键路径上必须消耗的纯网络耗时，没有包括非常消耗 CPU 资源的计算耗时，事实上计算耗时也不小（30ms 以上）。
-
1.浏览器计算耗时
- a) RSA 证书签名校验，浏览器需要解密签名，计算证书哈希值。如果有多个证书链，浏览器需要校验多个证书。
- b) RSA 密钥交换时，需要使用证书公钥加密 premaster。耗时比较小，但如果手机性能比较差，可能也需要 1ms 的时间。
- c) ECC 密钥交换时，需要计算椭圆曲线的公私钥。
- d) ECC 密钥交换时，需要使用证书公钥解密获取服务端发过来的 ECC 公钥。
- e) ECC 密钥交换时，需要根据服务端公钥计算 master key。
- f) 应用层数据对称加解密。
- g) 应用层数据一致性校验。
-
2.服务端计算耗时
- a) RSA 密钥交换时需要使用证书私钥解密 premaster。这个过程非常消耗性能。
- b) ECC 密钥交换时，需要计算椭圆曲线的公私钥。
- c) ECC 密钥交换时，需要使用证书私钥加密 ECC 的公钥。
- d) ECC 密钥交换时，需要根据浏览器公钥计算共享的 master key。
- e) 应用层数据对称加解密。
- f) 应用层数据一致性校验。
由于客户端的 CPU 和操作系统种类比较多，所以计算耗时不能一概而论。手机端的 HTTPS 计算会比较消耗性能，单纯计算增加的延迟至少在 50ms 以上。PC 端也会增加至少 10ms 以上的计算延迟。
服务器的性能一般比较强，但由于 RSA 证书私钥长度远大于客户端，所以服务端的计算延迟也会在 5ms 以上。
七 HTTP与HTTPS优缺点
7.1 HTTPS的优点：
安全性方面
在目前的技术背景下，HTTPS是现行架构下最安全的解决方案，主要有以下几个好处
- 使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器;
- HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
- HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
7.2 HTTPS的缺点：
技术方面
- 相同网络环境下，HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电。此外，HTTPS协议还会影响缓存，增加数据开销和功耗。
- HTTPS协议的安全是有范围的，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。
- 3.最关键的，SSL 证书的信用链体系并不安全。特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。
成本方面
- SSL的专业证书需要购买，功能越强大的证书费用越高。个人网站、小网站可以选择入门级免费证书。
- SSL 证书通常需要绑定 固定IP，为服务器增加固定IP会增加一定费用;
- HTTPS 连接服务器端资源占用高较高多，相同负载下会增加带宽和服务器投入成本;
既然HTTPS有这么多缺点，那是不是就不该做呢，当然不是的，随着技术的发展很多缺点是可以优化和弥补的。
比如：打开速度问题完全可以通过CDN加速解决，很多IDC也在着手推出免费证书和一站式HTTPS搭建服务，HTTPS成本在未来将会大大缩小!
八 我们到底要不要做HTTPS?
正方观点
- 1、HTTPS具有更好的加密性能，避免用户信息泄露;
- 2、HTTPS复杂的传输方式，降低网站被劫持的风险;
- 3、搜索引擎已经全面支持HTTPS抓取、收录，并且会优先展示HTTPS结果;
- 4、从安全角度来说个人觉得要做HTTPS，不过HTTPS可以采用登录后展示;
- 5、HTTPS绿锁表示可以提升用户对网站信任程度;
- 6、基础成本可控，证书及服务器已经有了成型的支持方案;
- 7、网站加载速度可以通过cdn等方式进行弥补，但是安全不能忽略;
- 8、HTTPS是网络的发展趋势，早晚都要做;
- 9、可以有效防止山寨、镜像网站;
反方观点
- 1、HTTPS会降低用户访问速度，增加网站服务器的计算资源消耗;
- 2、目前搜索引擎只是收录了小部分HTTPS内容，应该保持观望制度;
- 3、HTTPS需要申请加密协议，增加了运营成本;
- 4、百度目前对HTTPS的优先展现效果不明显，谷歌较为明显;
- 5、技术门槛较高，无从下手;
- 6、目前站点不涉及私密信息，无需HTTPS;
- 7、兼容性有待提升，如robots不支持/联盟广告不支持等;
- 8、HTTPS网站的安全程度有限，该被黑还是被黑;
- 9、HTTPS维护比较麻烦，在搜索引擎支持HTTP的情况，没必要做HTTPS;
九 拓展
9.1 HTTPS性能损耗
前文讨论了HTTPS原理与优势：身份验证、信息加密与完整性校验等，且未对TCP和HTTP协议做任何修改。但通过增加新协议以实现更安全的通信必然需要付出代价，HTTPS协议的性能损耗主要体现如下：
- 1 增加延时
分析前面的握手过程，一次完整的握手至少需要两端依次来回两次通信，至少增加延时2* RTT，利用会话缓存从而复用连接，延时也至少1* RTT*。
- 2 消耗较多的CPU资源
除数据传输之外，HTTPS通信主要包括对对称加解密、非对称加解密(服务器主要采用私钥解密数据);压测 TS8 机型的单核 CPU：对称加密算法AES-CBC-256 吞吐量 600Mbps，非对称 RSA 私钥解密200次/s。不考虑其它软件层面的开销，10G 网卡为对称加密需要消耗 CPU 约17核，24核CPU最多接入 HTTPS 连接 4800;
静态节点当前10G 网卡的 TS8 机型的 HTTP 单机接入能力约为10w/s，如果将所有的HTTP连接变为HTTPS连接，则明显RSA的解密最先成为瓶颈。因此，RSA的解密能力是当前困扰HTTPS接入的主要难题。
9.2 HTTPS接入优化
- CDN接入
HTTPS 增加的延时主要是传输延时 RTT，RTT 的特点是节点越近延时越小，CDN 天然离用户最近，因此选择使用 CDN 作为 HTTPS 接入的入口，将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法，极大减少 HTTPS 带来的延时。
- 会话缓存
虽然前文提到 HTTPS 即使采用会话缓存也要至少1*RTT的延时，但是至少延时已经减少为原来的一半，明显的延时优化;同时，基于会话缓存建立的 HTTPS 连接不需要服务器使用RSA私钥解密获取 Pre-master 信息，可以省去CPU 的消耗。如果业务访问连接集中，缓存命中率高，则HTTPS的接入能力讲明显提升。当前TRP平台的缓存命中率高峰时期大于30%，10k/s的接入资源实际可以承载13k/的接入，收效非常可观。
- 硬件加速
为接入服务器安装专用的SSL硬件加速卡，作用类似 GPU，释放 CPU，能够具有更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡可以提供35k的解密能力，相当于175核 CPU，至少相当于7台24核的服务器，考虑到接入服务器其它程序的开销，一张硬件卡可以实现接近10台服务器的接入能力。
- 远程解密
本地接入消耗过多的 CPU 资源，浪费了网卡和硬盘等资源，考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器，如此则可以充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当，实现机器资源复用，也可以是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。
- SPDY/HTTP2
前面的方法分别从减少传输延时和单机负载的方法提高 HTTPS 接入性能，但是方法都基于不改变 HTTP 协议的基础上提出的优化方法，SPDY/HTTP2 利用 TLS/SSL 带来的优势，通过修改协议的方法来提升 HTTPS 的性能，提高下载速度等。
本文参考如下文章
