http与https协议的区别与联系之科大爱情故事

  http是超文本传输协议,信息是明文传输,https 则是具有安全性的ssl加密传输协议 

目录

一、总序

https==http+对称加密+非对称加密+CA证书，在第三章与第四章，我们将通过一段爱情故事，来讲述他们最重要的区别和联系

HTTPS(全称：Hypertext Transfer Protocol over Secure Socket Layer)，是以安全为目标的HTTP通道，简单讲是HTTP的安全版。

它是在HTTP（应用层）下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

它是一个URI scheme(抽象标识符体系)，句法类同http:体系。用于安全的HTTP数据传输。

https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层(在HTTP与TCP之间)。这个系统的最初研发由网景公司进行，提供了身份验证与加密通讯方法，现在它被广泛用于万维网上安全敏感的通讯。

二、http协议

http优点 ————简单、灵活、易于扩展

初次接触 HTTP 的人都会认为，HTTP 协议是很“简单”的，基本的报文格式就是“header+body”，头部信息也是简单的文本格式，用的也都是常见的英文单词，即使不去看 RFC 文档，只靠猜也能猜出个“八九不离十”。

“简单”蕴含了进化和扩展的可能性，所谓“少即是多”，“把简单的系统变复杂”，要比“把复杂的系统变简单”容易得多。

所以，在“简单”这个最基本的设计理念之下，HTTP 协议又多出了“灵活和易于扩展”的优点。

“灵活和易于扩展”实际上是一体的，它们互为表里、相互促进，因为“灵活”所以才会“易于扩展”，而“易于扩展”又反过来让 HTTP 更加灵活，拥有更强的表现能力。

HTTP 协议里的请求方法、URI、状态码、原因短语、头字段等每一个核心组成要素都没有被“写死”，允许开发者任意定制、扩充或解释，给予了浏览器和服务器最大程度的信任和自由，也正好符合了互联网“自由与平等”的精神——缺什么功能自己加个字段或者错误码什么的补上就是了。

“请勿跟踪”所使用的头字段 DNT（Do Not Track）就是一个很好的例子。它最早由 Mozilla 提出，用来保护用户隐私，防止网站监测追踪用户的偏好。不过可惜的是 DNT 从推出至今有差不多七八年的历史，但很多网站仍然选择“无视”DNT。虽然 DNT 基本失败了，但这也正说明 HTTP 协议是“灵活自由的”，不会受单方面势力的压制。

“灵活、易于扩展”的特性还表现在 HTTP 对“可靠传输”的定义上，它不限制具体的下层协议，不仅可以使用 TCP、UNIX Domain Socket，还可以使用 SSL/TLS，甚至是基于 UDP 的 QUIC，下层可以随意变化，而上层的语义则始终保持稳定。

http缺点
1）明文。传输没有加密，信息容易被别人获取
2）不安全。不能证明是你，容易受到中间人攻击

https的出现本质上就是为了解决这两个问题，其解决方法大致为：对称加密+非对称加密+CA证书

三、对称加密与非对称加密

1、对称加密
最近，居住在科大南校的小明和科大北校的小樱最近谈恋爱了，他们是使用QQ来聊天（我们把这简单的假设为http协议），每天都会发送大量信息，由于寝室比较小，他们害怕消息被室友发现。于是小明去堕落街买了两个密码本，送给了小樱。这样他们就使用暗语在qq上面聊天。小明QQ发送了个6312425，小樱查找密码表后，对应的明文是5201314。就这样他们再也不怕被室友发现了，每天都聊到凌晨五点半。

春去秋来、、、、、
小樱当上了学生会主席，在美丽月湖旁的立德楼106办公，手下管理着108名大将。

自从小樱成为了学生会主席后，每天都要安排大量的工作给下面各部门去执行。有一次由于某位部长的QQ没有关，被别人看见了，学生会策划的学生CP计划被泄密了，大量的学生信息被暴露出来，引起了不好的学生反响。

于是小樱想起了信息加密，她叫来小明，让他去堕落街买密码本，小明兴高采烈的去了商店。商店老板一看来大买家，开着马拉力，将108*2本密码本送到了小樱手上。小明把108本不同的密码本分发给了学生会的不同人。

自从小樱使用了密文后，再也没有发生泄密事件了。但小樱这时发现了个问题，就是每当要联络不同的人时，都需要小明去那108本中找到对应的密码本，把小明忙的满头大汗。小明虽然每天都乐呵呵的，觉得这是锻炼身体，但小樱过意不去，于是要求小明发明一种轻松但是安全的加密方式。

小明翻遍全网、去了七大洲、四大洋，还去了火星取经，把能找到的信息都翻到了，终于发明了一种简单方法————非对称加密

2、非对称加密
它的具体做法是，我们每个人都使用小明发明的工具，生成一对孪生的密钥——公钥和私钥。消息通过公钥加密后，只有对应的私钥才能解密；通过私钥加密后，也只有对应的公钥才能解密。我们需要把自己的公钥放到自己的QQ主页。

当小樱需要去联系科技部部长小科时，只需要找到小科的主页的公钥，将要发送的信息通过小科的公钥加密发送过去，小科收到后，通过自己的私钥解密，就能完成工作、、、、、、

此种方法好处，省去了送密码本。当学生会新增加人员时，都只需要使用小明发明的工具，把生成的公钥放在QQ主页，就能加密联系了。

由于小明的此项发明大幅减少了交流成本，小樱奖励了小明一朵赏樱亭的樱花，小明乐的合不拢嘴、、、。

但，渐渐的问题来了，使用小明的此种方法，虽然安全了，但由于算法过于复杂，导致每次加密、解密可能画上几秒钟，有时可能得等更久，小樱虽然没有责怪小明，但小明看见很多人背后议论小樱，小明心里面很不是滋味，于是扛起一箱方便面进入了实验室，开始了新一轮优化工作。
、、、、、、、

小明首先对工具进行了重构，使用C语言后，发现效果不明显。于是又花了一周，使用汇编语言书写，但还是没有达到时间数量级下降的效果。又优化了算法，时间复杂度与空间复杂度都降到了最佳还是效果不明显，这让小明很郁闷。晚上去后街买了一根烤面筋，吃完后，灵感瞬间到来。

既然对称加密好处就是运算速度快，缺点是密码本需要线下传递；非对称加密好处是运算速度慢，但没有密码本传递。那如果我们都取其好处，岂不是乐哉。

于是新一代加密工具被开发出来了——第一次交流使用非对称加密，里面传输的是对称加密的密码（也就是上面我们说的密码本），后续交流使用对称加密的方式进行。

小樱非常开心，给小明点了一杯奶茶，小明开心的一夜没有睡着。

四、CA证书

由于对称加密与非对称加密效果很好，小明与小樱的交流方式也改为了这种。有一天，小明收到小红的
消息，解密后显示，小樱出去和闺蜜逛街，手头有点紧，需要往个银行卡里面打点钱。小明二话不说，马上到逸夫楼一楼的银行里面，给小樱打了一个小目标。第二天，和小樱见面时，才发现被骗子骗了。

原来群里面，有人冒充小樱，把自己的备注名改为和小樱一样的，但公钥确不是小樱的，于是引发了公钥危机，即我需要联系的那个人，人和公钥是否都是正确的呢

这里我们有个公正中心——CA
1）CA是证书的签发机构，它是公钥基础设施（Public Key Infrastructure，PKI）的核心。CA是负责签发证书、认证证书、管理已颁发证书的机关。
2）CA 拥有一个证书（内含公钥和私钥）。网上的公众用户通过验证 CA 的签字从而信任 CA ，任何人都可以得到 CA 的证书（含公钥），用以验证它所签发的证书。
3）如果用户想得到一份属于自己的证书，他应先向 CA 提出申请。在 CA 判明申请者的身份后，便为他分配一个公钥，并且 CA 将该公钥与申请者的身份信息绑在一起，并为之签字后，便形成证书发给申请者。
4）如果一个用户想鉴别另一个证书的真伪，他就用 CA 的公钥对那个证书上的签字进行验证，一旦验证通过，该证书就被认为是有效的。证书实际是由证书签证机关（CA）签发的对用户的公钥的认证。

又来了一个问题，如何保证这个CA中心是无误的呢（哈哈哈，我们仿佛陷入了一个鸡生蛋、蛋生鸡的死循环）。其实这里我们是通过递归树，层层往上证明，在我们的操作系统和浏览器里面内置了根证书的，就能最终证明。

最后问题完美的解决了，但小明与小樱的故事到这里还没有结束，后期文章会继续、、、、、、

五、SSL安全协议

SSL的原理就是上面小明与小樱的故事

SSL记录协议（Record Protocol）为SSL连接提供两种服务。
（1）保密性：利用握手协议所定义的共享密钥对SSL净荷（Payload）加密。
（2）完整性：利用握手协议所定义的共享的MAC密钥来生成报文的鉴别码（MAC）。

SSL的工作过程如下。
（1）发送方的工作过程为：
从上层接受要发送的数据（包括各种消息和数据）；
对信息进行分段，分成若干记录；
使用指定的压缩算法进行数据压缩（可选）；
使用指定的MAC算法生成MAC；
使用指定的加密算法进行数据加密；
添加SSL记录协议的头，发送数据。
（2）接收方的工作过程为：
接收数据，从SSL记录协议的头中获取相关信息；
使用指定的解密算法解密数据；
使用指定的MAC算法校验MAC；
使用压缩算法对数据解压缩（在需要进行）；
将记录进行数据重组；
将数据发送给高层。
SSL记录协议处理的最后一个步骤是附加一个SSL记录协议的头，以便构成一个SSL记录。SSL记录协议头中包含了SSL记录协议的若干控制信息。