HTTP、SSL/TLS和HTTPS协议的区别与联系（转载）
今天在请求数据的时候，服务器使用的是https请求，相对安全些，可是结果让我请求图片和资源的时候也使用https请求，我以前写的http请求根本用不了！我就感到很是的不爽！最后听公司的人说了下，最后他们决定重要信息使用https访问，可是对于资源什么的就使用http吧！html
开始没什么认识，只感受到使用https请求数据的时候，要通过安全验证，安全性很高！仔细查了一些资料，原来使用https是要分场合的，不是何时均可以用的，对此，咱们不妨先来看一下HTTP、SSL/TLS和HTTPS协议之间的区别与联系。算法
一、“HTTP”是什么？浏览器
超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为普遍的一种网络协议，全部的WWW文件都必须遵照这个标准，设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法（具体可查看马海祥博客《深刻解析互联网协议的原理》的相关介绍）。安全
1960年美国人Ted Nelson构思了一种经过计算机处理文本信息的方法，并称之为超文本（hypertext），这成为了HTTP超文本传输协议标准架构的发展根基。性能优化
简单来讲，HTTP就是一个网络协议，是专门用来帮你传输Web内容的，关于这个协议，就算你不了解，至少也据说过吧？好比你访问个人博客的主页，浏览器地址栏会出现的网址：http://www.mahaixiang.cn，大部分网站都是经过HTTP协议来传输Web页面、以及Web页面上包含的各类东东（图片、CSS 样式、JS 脚本）。服务器
二、“SSL/TLS”是什么？网络
SSL是“Secure Sockets Layer”的缩写，中文叫作“安全套接层”，它是在上世纪90年代中期，由网景公司设计的（顺便插一句，网景公司不光发明了 SSL，还发明了不少 Web 的基础设施——好比“CSS 样式表”和“JS 脚本”）。session
为啥要发明SSL这个协议捏？由于原先互联网上使用的HTTP协议是明文的，存在不少缺点——好比传输内容会被偷窥（嗅探）和篡改，发明SSL协议，就是为了解决这些问题。架构
到了1999年，SSL由于应用普遍，已经成为互联网上的事实标准，IETF就在那年把SSL标准化，标准化以后的名称改成TLS（是“Transport Layer Security”的缩写），中文叫作“传输层安全协议”。性能
不少相关的文章都把这二者并列称呼（SSL/TLS），由于这二者能够视做同一个东西的不一样阶段。
三、“HTTPS”是什么意思？
解释完 HTTP 和 SSL/TLS，如今就能够来解释 HTTPS 啦，我们一般所说的 HTTPS 协议，说白了就是“HTTP 协议”和“SSL/TLS 协议”的组合，你能够把 HTTPS 大体理解为——“HTTP over SSL”或“HTTP over TLS”（反正 SSL 和 TLS 差很少）。
HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，所以加密的详细内容就须要SSL。
它是一个URI scheme（抽象标识符体系），句法类同http:体系，用于安全的HTTP数据传输。
https:URL代表它使用了HTTP，但HTTPS存在不一样于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间），这个系统的最初研发由网景公司(Netscape)进行，并内置于其浏览器Netscape Navigator中，提供了身份验证与加密通信方法，如今它被普遍用于万维网上安全敏感的通信，例如交易支付方面。
四、谈谈“对称加密”和“非对称加密”的概念
若是咱们想搞明白“对称加密”和“非对称加密”的概念，首先，咱们就要先知道什么是“加密”和“解密”？
（1）、什么是“加密”和“解密”？
通俗而言，你能够把“加密”和“解密”理解为某种互逆的数学运算，就比如“加法和减法”互为逆运算、“乘法和除法”互为逆运算。
“加密”的过程，就是把“明文”变成“密文”的过程；反之，“解密”的过程，就是把“密文”变为“明文”，在这两个过程当中，都须要一个关键的东东——叫作“密钥”——来参与数学运算。
（2）、什么是“对称加密”？
所谓的“对称加密技术”，意思就是说：“加密”和“解密”使用相同的密钥。这个比较好理解，就比如你用 7zip 或 WinRAR 建立一个带密码（口令）的加密压缩包，当你下次要把这个压缩文件解开的时候，你须要输入一样的密码，在这个例子中，密码/口令就如同刚才说的“密钥”。
对称加密是最快速、最简单的一种加密方式，加密（encryption）与解密（decryption）用的是一样的密钥（secret key），这种方法在密码学中叫作对称加密算法，对称加密有不少种算法，因为它效率很高，因此被普遍使用在不少加密协议的核心当中。
（3）、什么是“非对称加密”？
所谓的“非对称加密技术”，意思就是说：“加密”和“解密”使用不一样的密钥，这玩意儿比较难理解，也比较难想到，当年“非对称加密”的发明，还被誉为“密码学”历史上的一次革命。
非对称加密为数据的加密与解密提供了一个很是安全的方法，它使用了一对密钥，公钥（public key）和私钥（private key），私钥只能由一方安全保管，不能外泄，而公钥则能够发给任何请求它的人，非对称加密使用这对密钥中的一个进行加密，而解密则须要另外一个密钥。
因为篇幅有限，对“非对称加密”这个话题，我就不展开了，有空的话，我会再单独写一篇文章在马海祥博客上发布。
（4）、各自有啥优缺点？
看完刚才的定义，很显然：（从功能角度而言）“非对称加密”能干的事情比“对称加密”要多，这是“非对称加密”的优势，可是“非对称加密”的实现，一般须要涉及到“复杂数学问题”，因此，“非对称加密”的性能一般要差不少（相对于“对称加密”而言）。
这二者的优缺点，也影响到了 SSL 协议的设计。
五、HTTP协议的特色
做为背景知识介绍，还须要再稍微谈一下 HTTP 协议自己的特色，HTTP自己有不少特色，考虑到篇幅有限，马海祥只谈那些和HTTPS相关的特色，想要了解更深刻的HTTP知识，可查看马海祥博客《HTTP服务的七层架构技术解析及运用》的相关介绍。
（1）、HTTP的版本和历史
现在我们用的 HTTP 协议，版本号是 1.1（也就是 HTTP 1.1），这个 1.1 版本是1995年末开始起草的（技术文档是RFC2068），并在1999年正式发布（技术文档是RFC2616）。
在 1.1 以前，还有曾经出现过两个版本“0.9 和 1.0”，其中的 HTTP 0.9 没有被普遍使用，而 HTTP 1.0 被普遍使用过。
（2）、HTTP 和 TCP 之间的关系
简单地说，TCP 协议是 HTTP 协议的基石——HTTP 协议须要依靠 TCP 协议来传输数据。
在网络分层模型中，TCP 被称为“传输层协议”，而 HTTP 被称为“应用层协议”。
有不少常见的应用层协议是以 TCP 为基础的，好比“FTP、SMTP、POP、IMAP”等。
TCP被称为“面向链接”的传输层协议，关于它的具体细节，俺就不展开了（不然篇幅又失控了），你只需知道：传输层主要有两个协议，分别是TCP和UDP，TCP比UDP更可靠，你能够把 TCP 协议想象成某个水管，发送端这头进水，接收端那头就出水，而且 TCP 协议可以确保，先发送的数据先到达（与之相反，UDP不保证这点）。
（3）、HTTP协议如何使用 TCP 链接？
HTTP对 TCP 链接的使用，分为两种方式：俗称“短链接”和“长链接”（“长链接”又称“持久链接”，叫作“Keep-Alive”或“Persistent Connection”）
假设有一个网页，里面包含好多图片，还包含好多外部的CSS文件和JS文件，在“短链接”的模式下，浏览器会先发起一个 TCP 链接，拿到该网页的 HTML 源代码（拿到 HTML 以后，这个 TCP 链接就关闭了）。而后，浏览器开始分析这个网页的源码，知道这个页面包含不少外部资源（图片、CSS、JS）。而后针对每个外部资源，再分别发起一个个 TCP 链接，把这些文件获取到本地（一样的，每抓取一个外部资源后，相应的 TCP 就断开）。
相反，若是是“长链接”的方式，浏览器也会先发起一个 TCP 链接去抓取页面，可是抓取页面以后，该 TCP 链接并不会当即关闭，而是暂时先保持着（所谓的“Keep-Alive”），而后浏览器分析 HTML 源码以后，发现有不少外部资源，就用刚才那个 TCP 链接去抓取此页面的外部资源。
在 HTTP 1.0 版本，默认使用的是“短链接”（那时候是 Web 诞生初期，网页相对简单，“短链接”的问题不大）。
到了1995年末开始制定 HTTP 1.1 草案的时候，网页已经开始变得复杂（网页内的图片、脚本愈来愈多了），这时候再用短链接的方式，效率过低下了（由于创建 TCP 链接是有“时间成本”和“CPU成本”），因此，在 HTTP 1.1 中，默认采用的是“Keep-Alive”的方式。
六、SSL/TLS协议的基本运行过程
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，而后用公钥加密信息，服务器收到密文后，用本身的私钥解密，可是这里有两个问题：
（1）、如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中，只要证书是可信的，公钥就是可信的。
（2）、公钥加密计算量太大，如何减小耗用的时间？
解决方法：每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。因为"对话密钥"是对称加密，因此运算速度很是快，而服务器公钥只用于加密"对话密钥"自己，这样就减小了加密运算的消耗时间。
所以，SSL/TLS协议的基本过程是这样的：
（1）、客户端向服务器端索要并验证公钥。
（2）、双方协商生成“对话密钥”。
（3）、双方采用“对话密钥”进行加密通讯。
上面过程的前两步，又称为“握手阶段”（handshake）。
以上图片就是“握手阶段”涉及四次通讯，须要注意的是，“握手阶段”的全部通讯都是明文的。
七、SSL、HTTP和HTTPS协议的联系
SSL是Netscape公司所提出的安全保密协议，在浏览器(如Internet Explorer、Netscape Navigator)和Web服务器(如Netscape的Netscape Enterprise Server、ColdFusion Server等等)之间构造安全通道来进行数据传输，SSL运行在TCP/IP层之上、应用层之下，为应用程序提供加密数据通道，它采用了RC四、MD5 以及RSA等加密算法，使用40位的密钥，适用于商业信息的加密。
同时，Netscape公司相应开发了HTTPS协议并内置于其浏览器中，HTTPS实际上就是SSL over HTTP，它使用默认端口443，而不是像HTTP那样使用端口80来和TCP/IP进行通讯。HTTPS协议使用SSL在发送方把原始数据进行加密，而后在接受方进行解密，加密和解密须要发送方和接受方经过交换共知的密钥来实现，所以，所传送的数据不容易被网络黑客截获和解密。
然而，加密和解密过程须要耗费系统大量的开销，严重下降机器的性能，相关测试数据代表使用HTTPS协议传输数据的工做效率只有使用HTTP协议传输的十分之一。
假如为了安全保密，将一个网站全部的Web应用都启用SSL技术来加密，并使用HTTPS协议进行传输，那么该网站的性能和效率将会大大下降，并且没有这个必要，由于通常来讲并非全部数据都要求那么高的安全保密级别，因此，咱们只需对那些涉及机密数据的交互处理使用HTTPS协议，这样就作到鱼与熊掌兼得（具体可查看马海祥博客《从SEO的角度来分析网站是否该采用HTTPS协议》的相关介绍）。
总之不须要用https的地方，就尽可能不要用。
八、HTTPS协议的需求是什么？
花了好多口水，终于把背景知识说完了，下面正式进入正题，先来讲说当初设计HTTPS是为了知足哪些需求？
不少介绍 HTTPS 的文章一上来就给你讲实现细节，对此，马海祥以为这是很差的作法，一上来就给你讲协议细节，你充其量只能知道如何作，没法理解为何，我在前一个章节讲了“背景知识”，在这个章节讲了“需求”，这就有助于你理解了。
为何要设计成这样？——这就是 WHY 型的问题。
（1）、兼容性
由于是先有 HTTP 再有 HTTPS，因此，HTTPS 的设计者确定要考虑到对原有 HTTP 的兼容性。
这里所说的兼容性包括不少方面，好比已有的 Web 应用要尽量无缝地迁移到 HTTPS；好比对浏览器厂商而言，改动要尽量小。
基于“兼容性”方面的考虑，很容易得出以下几个结论：
①、HTTPS仍是要基于 TCP 来传输
若是改成 UDP 做传输层，不管是 Web 服务端仍是浏览器客户端，都要大改，动静太大了。
②、单独使用一个新的协议，把 HTTP 协议包裹起来
所谓的“HTTP over SSL”，其实是在原有的 HTTP 数据外面加了一层 SSL 的封装，HTTP 协议原有的 GET、POST 之类的机制，基本上原封不动。
打个比方：若是原来的 HTTP 是塑料水管，容易被戳破；那么现在新设计的 HTTPS 就像是在原有的塑料水管以外，再包一层金属水管，一来，原有的塑料水管照样运行；二来，用金属加固了以后，不容易被戳破。
（2）、可扩展性
前面说了，HTTPS 至关因而“HTTP over SSL”。
若是 SSL 这个协议在“可扩展性”方面的设计足够牛逼，那么它除了能跟 HTTP 搭配，还可以跟其它的应用层协议搭配，岂不美哉？
如今看来，当初设计 SSL 的人确实比较牛，现在的 SSL/TLS 能够跟不少经常使用的应用层协议（好比：FTP、SMTP、POP、Telnet）搭配，来强化这些应用层协议的安全性。
接着刚才打的比方：若是把 SSL/TLS 视做一根用来加固的金属管，它不只能够用来加固输水的管道，还能够用来加固输煤气的管道。
（3）、保密性（防泄密）
HTTPS须要作到足够好的保密性。
说到保密性，首先要可以对抗嗅探（行话叫 Sniffer），所谓的“嗅探”，通俗而言就是监视你的网络传输流量，若是你使用明文的 HTTP 上网，那么监视者经过嗅探，就知道你在访问哪些网站的哪些页面。
嗅探是最低级的攻击手法，除了嗅探，HTTPS 还须要能对抗其它一些稍微高级的攻击手法——好比“重放攻击”（后面讲协议原理的时候，会再聊）。
（4）、完整性（防篡改）
除了“保密性”，还有一个一样重要的目标是“确保完整性”。
在发明 HTTPS 以前，因为 HTTP 是明文的，不但容易被嗅探，还容易被篡改。
举个例子：好比我们的网络运营商（ISP）都比较流氓，常常有网友抱怨说访问某网站（原本是没有广告的），居然会跳出不少中国电信的广告，为啥会这样呢？由于你的网络流量须要通过 ISP 的线路才能到达公网，若是你使用的是明文的 HTTP，ISP 很容易就能够在你访问的页面中植入广告。
因此，当初设计 HTTPS 的时候，还有一个需求是“确保 HTTP 协议的内容不被篡改”。
（5）、真实性（防假冒）
在谈到 HTTPS 的需求时，“真实性”常常被忽略，其实“真实性”的重要程度不亚于前面的“保密性”和“完整性”。
举个例子：你由于使用网银，须要访问该网银的 Web 站点，那么，你如何确保你访问的网站确实是你想访问的网站？
有些天真的同窗会说：经过看网址里面的域名，来确保，为啥说这样的同窗是“天真的”？由于 DNS 系统自己是不可靠的（尤为是在设计 SSL 的那个年代，连 DNSSEC 都还没发明），因为 DNS 的不可靠（存在“域名欺骗”和“域名劫持”），你看到的网址里面的域名未必是真实滴！
因此，HTTPS 协议必须有某种机制来确保“真实性”的需求（至于如何确保，后面会细聊）。
九、HTTPS和HTTP的区别
超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，若是攻击者截取了Web浏览器和网站服务器之间的传输报文，就能够直接读懂其中的信息，所以HTTP协议不适合传输一些敏感信息，好比信用卡号、密码等。
为了解决HTTP协议的这一缺陷，须要使用另外一种协议：安全套接字层超文本传输协议HTTPS。
为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通讯加密。
通常来讲，HTTPS和HTTP的区别主要为如下四点：
（1）、https协议须要到ca申请证书，通常免费证书不多，须要交费。
（2）、http是超文本传输协议，信息是明文传输，https则是具备安全性的ssl加密传输协议。
（3）、http和https使用的是彻底不一样的链接方式，用的端口也不同，前者是80，后者是443。
（4）、http的链接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全（具体可查看马海祥博客《HTTP与HTTPS的区别》的相关介绍）。
十、HTTPS和HTTP的性能比较
再来讲最后一个需求——性能。
原本简单的http协议，一个get一个response，因为https要还密钥和确认加密算法的须要，单握手就须要六、7个往返，任何应用中，过多的round trip确定影响性能，接下来才是具体的http协议，每一次响应或者请求，都要求客户端和服务端对会话的内容作加密/解密。
尽管对称加密/解密效率比较高，但是仍然要消耗过多的CPU，为此有专门的SSL芯片，若是CPU信能比较低的话，确定会下降性能，从而不能serve更多的请求，加密后数据量的影响，因此，才会出现那么多的安全认证提示（具体可查看马海祥博客《HTTPS对网站性能优化的影响》的相关介绍）。
通常来讲，引入HTTPS以后，不能致使性能变得太差，不然的话，谁还愿意用？
为了确保性能，SSL 的设计者至少要考虑以下几点：
（1）、如何选择加密算法（“对称”or“非对称”）？
（2）、如何兼顾 HTTP 采用的“短链接”TCP 方式？
SSL 是在1995年以前开始设计的，那时候的 HTTP 版本仍是 1.0，默认使用的是“短链接”的 TCP 方式——默认不启用 Keep-Alive。
HTTPS的关键性能影响是CPU和往返，若是CPU很强的话，性能可能就是有人讲的80%；若是cpu是瓶颈的话，有人讲原来能够server330-500个请求每秒，如今只有30-50%，所以在使用https请求数据的时候要注意看看你的项目里面是否真的须要。
马海祥博客点评：
HTTPS是为了安全性而设置的，要验证不少的信息，相对应http请求的速度确定有点慢，若是使用HTTPS的话很麻烦的，无心给服务器和客户端增长了很大的压力，因此，平时最好不要使用HTTPS，若是牵扯到我的隐私或者是其余的什么重要信息就必定要这么作了。
不少的时候你感受有点问题，可是若是不去细细发觉的话，暂时没有什么问题，可是在你后面的维护，或者出问题的时候会弄的头痛不已，为了之后的方便，仍是此刻就好好的把每一件事作好，分析好！
本文为马海祥博客原创文章，如想转载，请注明原文网址摘自于http://www.mahaixiang.cn/inte...，注明出处；不然，禁止转载；谢谢配合！