前端常见问题:https和http的区别

2,409 阅读11分钟

最近看了牛客的好多帖子,发现无论是社招还是校招,几轮技术面试下来都会考这个问题,同时这个问题也可以引申出很多的细小的知识点,下面咱们就好好的聊一聊这个知识点

HTTP 简介


我们先来看万恶的概论定义:

HTTP 协议是 Hyper Text Transfer Protocol(超文本传输协议)的缩写,是用于从万维网
(WWW:World Wide Web )服务器传输超文本到本地浏览器的传送协议。

HTTP 是一个基于 TCP/IP 通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)。

HTTP 是一个属于应用层的面向对象的协议,由于其简捷、快速的方式,适用于分布式超
媒体信息系统。它于 1990 年提出,经过几年的使用与发展,得到不断地完善和扩展。目
前在 WWW 中使用的是 HTTP/1.0 的第六版,HTTP/1.1 的规范化工作正在进行之中,而且
HTTP-NG(Next Generation of HTTP)的建议已经提出。

HTTP 协议工作于客户端-服务端架构为上。浏览器作为 HTTP 客户端通过 URL 向 HTTP 服务
端即 WEB 服务器发送所有请求。Web 服务器根据接收到的请求后,向客户端发送响应信
息。

好了,以上就是又令人头疼的概念定义,不要死记硬背,下面我们可以简要的分析一下HTTP的特点。

HTTP特点

这一个问题在上一个帖子已经概括一遍了,我们可以来简单回顾一下:

  • 灵活可扩展,主要体现在两个方面。一个是语义上的自由,只规定了基本格式,比如空格分隔单词,换行分隔字段,其他的各个部分都没有严格的语法限制。另一个是传输形式的多样性,不仅仅可以传输文本,还能传输图片、视频等任意数据,非常方便。

  • 可靠传输。HTTP 基于 TCP/IP协议,因此把这一特性继承了下来。

  • 请求-应答。可以概况为一发一收,有来有回。这个请求方和应答方不单单指客户端和服务器之间,如果某台服务器作为代理来连接后端的服务端,那么这台服务器也会扮演请求方的角色。

  • 无状态。每次 http 请求都是独立、无关的,默认不需要保留通信过程的上下文状态信息。

  • (另附一点)支持B/S和C/S模式。

HTTP的弊端

当我们往服务器发送比较隐私的数据(比如说你的银行卡,身份证)时,如果使用 http 进行通信。那么安全性将得不到保障。 

首先数据在传输的过程中,数据可能被中间人抓包拿到,那么数据就会被中间人窃取。 其次数据被中间人拿到后,中间人可能对数据进行修改或者替换,然后发往服务器。

 最后服务器收到数据后,也无法确定数据有没有被修改或替换,当然,如果服务器也无法 判断数据就真的是来源于客户端。

简单来说,可以概括为三个弊端:

  1. 无法保证消息的保密性

  2. 无法保证消息的完整性和准确性

  3. 无法保证消息来源的可靠性

然后,HTTPS就由此应运而生,下面让我们来看看HTTPS。

HTTPS了解一哈

HTTPS是以安全 为目标的 HTTP 通道,简单讲是 HTTP 的安全版。

即 HTTP 下加入 SSL 层,HTTPS 的安全基础是 SSL,因此加密的详细内容就需要 SSL。 现已被广泛用于万维网上安全敏感的通讯,例如交易支付方面。 HTTPS 通过非对称加密算法可以使得我们传的明文信息,无法通过逆推得出明文。

接下来 我们来看看在具体的工作流程是怎么样的?

我们可以将通信双方理解为 客户端 和 服务端。然后经历以下几个阶段。
  • 首先客户端申请HTTPS通信。
  • 服务器响应并响应客户端传递证书。
  • 客户端验证证书,获取公钥,生成对称加密密钥,用公钥加密后传给服务器。
  • 服务器接收到消息,用私钥解密,拿出对称密钥,并通知客户端,SSL通道建立完成,https通信也建立完成。
  • 共享密钥交换成功,https通信建立后,客户端和服务器利用共享密钥加密通信。
  • 最后客户端断开连接。

通过以上可以看出,https建立到断开可以分为6个阶段,但是其中还包含12个过程,下面我们可以对这12个过程做一个简单得刨析。

  1. 客户端 — Hello:客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密匙长度等)。

  2. .服务器 — Hello:服务器可进行 SSL 通信时,会以 Server Hello 报文作为应答。和客户端一样,在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容时从接收到的客户端加密组件内筛选出来的。

  3. 服务器 — 发证书:服务器发送证书报文。报文中包含公开密匙证书。

  4. .服务器 — 我说完了:最后服务器发送 Server Hello Done 报文通知客户端,最初阶段的 SSL 握手协商部分结束。 

  5. 客户端 — 发送秘钥:SSL 第一次握手结束之后,客户端以 Client Key Exchange 报文作 为回应。报文包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报 文已用步骤 3 中的公开密匙进行加密。 

  6. 客户端 — 就用这个秘钥了:该报文会提示服务器,在此报文之后的通信会采用Premaster secret 密匙加密。 

  7. 客户端 — 我说完了:该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功,要以服务器是否能够正确解密该报文作为判定标准。

  8. 服务器 — 发送 Change Cipher Spec 报文(我正在接收秘钥)。

  9. 服务器 — 发送 Finished 报文(我收完秘钥了)。

  10. 客户端 — 开始发送正文:服务器端发送 HTTP 请求,发送相关内容。

  11. 服务器 — 开始接收正文:客户端接收 HTTP 请求,并处理相关内容。

  12. .客户端 — 断开链接:最后由客户端断开连接。断开连接时,发送 close_notify 报文。上图做了一些省略,这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。

同时,应用层发送数据时会附加一种叫做 MAC(Message Authentication Code)的报文摘要。MAC 能够查知报文是否遭到篡改,从而保证报文的完整性。

HTTPS的理论原理

https 采用了一些加解密,数字证书,数字签名的技术来实现。下面先介绍一下这些技术的基本概念。

对称加密与非对称加密

1.对称加密(共享密匙加密):客户端和服务器公用一个密匙用来对消息加解密,这种方式称为对称加密。客户端和服务器约定好一个加密的密匙。客户端在发消息前用该密匙对 消息加密,发送给服务器后,服务器再用该密匙进行解密拿到消息。

可以看个图来简单了解一哈。

上图中M代表明文,C指密钥,N指密文。

对称加密的优点

  • 对称加密解决了 http 中消息保密性的问题。

对称加密的缺点

  • 对称加密虽然保证了消息保密性,但是因为客户端和服务器共享一个密匙,这样就使得密匙特别容易泄露。

  • 因为密匙泄露风险较高,所以很难保证消息来源的可靠性、消息的完整性和准确性。

通过以上可以看出,对称加密秘钥泄露风险很高,秘钥固定,导致很容易被破解,那么有没有更好的方式去进行加密传输,比如说每次用的秘钥都不相同,每次解密的秘钥也都不相同,或者其他的情况来增加安全性呢?

非对称加密

既然对称加密中,密匙那么容易泄露,那么我们可以采用一种非对称加密的方式来解决。 

采用非对称加密时,客户端和服务端均拥有一个公有密匙和一个私有密匙。公有密匙可以对外暴露,而私有密匙只有自己可见。 

使用公有密匙加密的消息,只有对应的私有密匙才能解开。反过来,使用私有密匙加密的消息,只有公有密匙才能解开。这样客户端在发送消息前,先用服务器的公匙对消息进行加密,服务器收到后再用自己的私匙进行解密。 

图示加密过程:

M指明文,D为公钥,E指私钥,N代表密文。

在服务器这一次生成公钥 D 以及私钥 E,私钥自己留存。然后将公钥 D 进行对外 公开,想与服务器端通信的客户端用公钥 D 进行加密发送给具有私钥 E 的服务器,服务器 用私钥 E 就可以进行密文解密,最终拿到明文。 

至于刚才提到的加密算法,比较出名的就是RSA公钥加密算法,他的加密过程就不做太多剖析,想了解更多的可以按照以下连接,自行理解。

blog.csdn.net/u014044812/…

数字证书与数字签名


为了解决非对称加密中公匙来源的不安全性。我们可以使用数字证书和数字签名来解决。

数字证书的申请

在现实中,有一些专门的权威机构用来颁发数字证书,我们称这些机构为认证中心(CA)。

服务器可以向这些 CA 来申请数字证书。

申请的过程大致是: 

  • 自己本地先生成一对密匙,然后拿着自己的公匙以及其他信息(比如说企业名称啊什么的)去 CA 申请数字证书。 
  • CA 在拿到这些信息后,会选择一种单向 Hash 算法(比如说常见的 MD5)对这些信息进行加密,加密之后的东西我们称之为摘要。 
  • 单向 Hash 算法有一种特点就是单向不可逆的,只要原始内容有一点变化,加密后的数据都将会是千差万别(当然也有很小的可能性会重复,有兴趣的小伙伴鸽巢原理了解一下),这样就防止了信息被篡改。 
  • 生成摘要后还不算完,CA 还会用自己的私匙对摘要进行加密,摘要加密后的数据我们称之为数字签名。 
  • 最后,CA 将会把我们的申请信息(包含服务器的公匙)和数字签名整合在一起,由此而生成数字证书。然后 CA 将数字证书传递给我们。

数字证书怎么起作用 

服务器在获取到数字证书后,服务器会将数字证书发送给客户端,客户端就需要用 CA 的 公匙解密数字证书并验证数字证书的合法性。那我们如何能拿到 CA 的公匙呢?我们的电 脑和浏览器中已经内置了一部分权威机构的根证书,这些根证书中包含了 CA 的公匙。

之所以是根证书,是因为现实生活中,认证中心是分层级的,也就是说有顶级认证中心, 也有下面的各个子级的认证中心,是一个树状结构,计算机中内置的是最顶级机构的根证书,不过不用担心,根证书的公匙在子级也是适用的。 

客户端用 CA 的公匙解密数字证书,如果解密成功则说明证书来源于合法的认证机构。解密成功后,客户端就拿到了摘要。

此时,客户端会按照和 CA 一样的 Hash 算法将申请信息生成一份摘要,并和解密出来的那份做对比,如果相同则说明内容完整,没有被篡改。最后,客户端安全的从证书中拿到服务器的公匙就可以和服务器进行安全的非对称加密通信了。服务器想获得客户端的公匙也可以通过相同方式。