HTTP与HTTPS的区别，详细介绍

末蓝、 2022-12-11 10:29 218阅读 0赞

转载：[HTTP与HTTPS的区别，详细介绍][HTTP_HTTPS]

需要查看更多的计算机网络相关的知识？[点击这里][Link 1]

**目录**

HTTP与HTTPS介绍

HTTPS和HTTP的主要区别

客户端在使用HTTPS方式与Web服务器通信时的步骤

CA证书的申请及其使用过程

HTTPS的缺点

SSL与TLS的区别？

SSL/TLS历史

SSL/TLS协议的基本过程

HTTPS涉及的计算环节

如何优化HTTPS的速度

--------------------

## HTTP与HTTPS介绍 ##

超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全

HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

## **HTTPS****和HTTP的主要区别** ##

1、https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。

2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl/tls加密传输协议。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

## **客户端在使用HTTPS方式与Web服务器通信时的步骤** ##

（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

（3）客户端的浏览器与Web服务器开始协商SSL/TLS连接的安全等级，也就是信息加密的等级。

（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

（5）Web服务器利用自己的私钥解密出会话密钥。

（6）Web服务器利用会话密钥加密与客户端之间的通信。

![70][]

![70 1][]

尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，但他大幅增加了中间人攻击的成本

## CA证书的申请及其使用过程 ##

上面客户端使用HTTPS与服务器通信中使用到了CA认证，这里可能大家会问为什么不直接使用非对称加密的形式直接进行，首先这里先介绍下非对称加密。

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NjQyMDM2_size_16_color_FFFFFF_t_70][]

非对称加密的优点：

*  非对称加密采用公有密匙和私有密匙的方式，解决了http中消息保密性问题，而且使得私有密匙泄露的风险降低。
 *  因为公匙加密的消息只有对应的私匙才能解开，所以较大程度上保证了消息的来源性以及消息的准确性和完整性。

非对称加密的缺点：

*  非对称加密时需要使用到接收方的公匙对消息进行加密，但是公匙不是保密的，任何人都可以拿到，中间人也可以。那么中间人可以做两件事，第一件是中间人可以在客户端与服务器交换公匙的时候，将客户端的公匙替换成自己的。这样服务器拿到的公匙将不是客户端的，而是中间人的。服务器也无法判断公匙来源的正确性。第二件是中间人可以不替换公匙，但是他可以截获客户端发来的消息，然后篡改，然后用服务器的公匙加密再发往服务器，服务器将收到错误的消息。
 *  非对称加密的性能相对对称加密来说会慢上几倍甚至几百倍，比较消耗系统资源。正是因为如此，https将两种加密结合了起来。

为了应对上面非对称加密带来的问题，我们就引入了**数字证书与数字签名**

故CA认证介入我们的HTTPS连接的过程如下：

1、服务器拥有自己的私钥与公钥

2、服务器将公钥交给CA认证机构，请求给予一份数字证书

3、CA认证机构生成数字证书，并颁发给服务器

4、服务器将带有公钥信息的数字证书发给客户端

5、进入客户端生成对称密钥再进行对接的过程......

*  ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NjQyMDM2_size_16_color_FFFFFF_t_70 1][]

## **HTTPS的缺点** ##

虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；

（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

实践中建议保留http。所以我们在切换的时候可以做http和https的兼容，具体实现方式是，去掉页面链接中的http头部，这样可以自动匹配http头和https头。例如：将http://www.baidu.com改为//www.baidu.com。然后当用户从http的入口进入访问页面时，页面就是http，如果用户是从https的入口进入访问页面，页面即使https的

## **SSL****与TLS的区别？** ##

SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。

TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。

### **SSL/TLS历史** ###

*1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。  
1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。  
1996年，SSL 3.0版问世，得到大规模应用。  
1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。  
2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。  
目前，应用最广泛的是TLS 1.0，接下来是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支持。  
TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。*

### SSL/TLS协议的基本过程 ###

（1） 客户端向服务器端索要并验证公钥。  
（2） 双方协商生成"对话密钥"。  
（3） 双方采用"对话密钥"进行加密通信。  
上面过程的前两步，又称为"握手阶段"（handshake）

![https://images2015.cnblogs.com/blog/1156565/201705/1156565-20170510103645238-169942462.png][https_images2015.cnblogs.com_blog_1156565_201705_1156565-20170510103645238-169942462.png]

**1 客户端发出请求（ClientHello）**

（1） 支持的协议版本，比如TLS 1.0版。  
（2） 一个客户端生成的随机数，稍后用于生成"对话密钥"。  
（3） 支持的加密方法，比如RSA公钥加密。  
（4） 支持的压缩方法。

**2 服务器回应（SeverHello）**

（1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。  
（2） 一个服务器生成的随机数，稍后用于生成"对话密钥"。  
（3） 确认使用的加密方法，比如RSA公钥加密，此时带有公钥信息。  
（4） 服务器证书。

**3 客户端回应**

（1） **一个随机数pre-master key。该随机数用服务器公钥加密，防止被窃听。**  
（2）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。  
（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

上面客户端回应中第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，**各自生成本次会话所用的同一把"会话密钥"。**

**那么为什么一定要用三个随机数，来生成"会话密钥"呢？**

"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机数，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"

此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

**4 服务器的最后回应**

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。（客户端在第三阶段也生成这个“会话秘钥”）。然后，向客户端最后发送下面信息。  
（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。  
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。

TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：

1）更安全的MAC算法

2）更严密的警报

3）“灰色区域”规范的更明确的定义

TLS对于安全性的改进点如下：

1）对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。

2）增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。

3）改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。

4）一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。

5）特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

**HTTPS很安全，很古老也很成熟，为什么一直到今天我们还有66%的网站不支持HTTPS呢？**

1、**慢**，HTTPS未经任何优化的情况下要比HTTP慢几百毫秒以上，特别在移动端可能要慢500毫秒以上，关于HTTPS慢和如何优化已经是一个非常系统和复杂的话题

2、**贵**，特别在计算性能和服务器成本方面。HTTPS为什么会增加服务器的成本？相信大家也都清楚HTTPS要额外计算，要频繁地做**加密和解密操作**，几乎每一个字节都需要做加解密，这就产生了服务器成本

另外还有:

**1、大量的计算。**SSL的每一个字节都涉及到较为复杂的计算。即使是clientHello，也需要在握手完成时做校验。

**2、TLS协议的封装和解析**。HTTPS所有数据都是按照TLS record格式进行封装和解析的。

**3、协议的网络交互。**从TLS的握手过程可以看出，即使不需要进行任何计算，TLS的握手也需要至少1个RTT（round trip time)以上的网络交互。

<table> 
 <tbody> 
  <tr> 
   <td> <p>RTT(Round-Trip Time): 往返时延。在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。</p> </td> 
  </tr> 
 </tbody> 
</table>

4、HTTPS降低用户访问速度（需多次握手）

5、网站改用 HTTPS 以后，由 HTTP 跳转到 HTTPS 的方式**增加了用户访问耗时**（多数网站采用 301、302 跳转）

6、HTTPS 涉及到的安全算法会消耗 CPU 资源，需要增加服务器资源（https 访问过程需要加解密）

## **HTTPS****涉及的计算环节** ##

**1、非对称密钥交换。**比如RSA, Diffie-Hellman, ECDHE.这类算法的主要作用就是根据客户端和服务端不对称的信息，经过高强度的密钥生成算法，生成对称密钥，用于加解密后续应用消息。

**2、对称加解密。**服务端使用密钥A对响应内容进行加密，客户端使用相同的密钥A对加密内容进行解密，反之亦然。

**3、消息一致性验证。**每一段加密的内容都会附加一个MAC消息，即消息认证码。简单地说就是对内容进行的安全哈希计算，接收方需要校验MAC码。

**4、证书签名校验。**这个阶段主要发生在客户端校验服务端证书身份时，需要对证书签名进行校验，确保证书的真实性。

![70 2][]

以上图片文字解释来源：[https://www.cnblogs.com/mylanguage/p/5635524.html][https_www.cnblogs.com_mylanguage_p_5635524.html]

OCSP(Online Certificate Status Protocol，在线证书状态协议)

## **如何优化HTTPS的速度** ##

**1、HSTS重定向技术**

HSTS（HTTP Strict Transport Security）技术，启用HSTS后，将保证浏览器始终连接到网站的 HTTPS 加密版本。

1. 用户在浏览器里输入 HTTP 协议进行访问时，浏览器会自动将 HTTP 转换为 HTTPS 进行访问，确保用户访问安全；

2. 省去301跳转的出现，缩短访问时间；

3. 能阻止基于 SSL Strip 的中间人攻击，万一证书有错误，则显示错误，用户不能回避警告，从而能够更加有效安全的保障用户的访问。

**2、TLS握手优化**

在传输应用数据之前，客户端必须与服务端协商密钥、加密算法等信息，服务端还要把自己的证书发给客户端表明其身份，这些环节构成 TLS 握手过程。

采用 False Start （抢先开始）技术，浏览器在与服务器完成 TLS 握手前，就开始发送请求数据，服务器在收到这些数据后，完成 TLS 握手的同时，开始发送响应数据。

开启 False Start 功能后，数据传输时间将进一步缩短。

**3、Session Identifier（会话标识符）复用**

如果用户的一个业务请求包含了多条的加密流，客户端与服务器将会反复握手，必定会导致更多的时间损耗。或者某些特殊情况导致了对话突然中断，双方就需要重新握手，增加了用户访问时间。

（1）服务器为每一次的会话都生成并记录一个 ID 号，然后发送给客户端；

（2）如果客户端发起重新连接，则只要向服务器发送该 ID 号；

（3）服务器收到客户端发来的 ID 号，然后查找自己的会话记录，匹配 ID 之后，双方就可以重新使用之前的对称加密秘钥进行数据加密传输，而不必重新生成，减少交互时间。

**4、开启OSCP Stapling，提高TLS握手效率**

采用OCSP Stapling ，提升 HTTPS 性能。服务端主动获取 OCSP 查询结果并随着证书一起发送给客户端，从而客户端可直接通过 Web Server 验证证书，提高 TLS 握手效率。

服务器模拟浏览器向 CA 发起请求，并将带有 CA 机构签名的 OCSP 响应保存到本地，然后在与客户端握手阶段，将 OCSP 响应下发给浏览器，省去浏览器的在线验证过程。由于浏览器不需要直接向 CA 站点查询证书状态，这个功能对访问速度的提升非常明显。

**5、完全前向加密PFS，保护用户数据，预防私钥泄漏**

非对称加密算法 RSA，包含了公钥、私钥，其中私钥是保密不对外公开的，由于此算法既可以用于加密也可以用于签名，所以用途甚广，但是还是会遇到一些问题：

（1） 假如我是一名黑客，虽然现在我不知道私钥，但是我可以先把客户端与服务器之前的传输数据（已加密）全部保存下来

（2）如果某一天，服务器维护人员不小心把私钥泄露了，或者服务器被我攻破获取到了私钥

（3）那我就可以利用这个私钥，破解掉之前已被我保存的数据，从中获取有用的信息

所以为了防止上述现象发生，我们必须保护好自己的私钥。

如果私钥确实被泄漏了，那我们改如何补救呢？那就需要PFS（perfect forward secrecy）完全前向保密功能，此功能用于客户端与服务器交换对称密钥，起到前向保密的作用，也即就算私钥被泄漏，黑客也无法破解先前已加密的数据。维基解释是：**长期使用的主[密钥][Link 2]泄漏不会导致过去的[会话密钥][Link 3]泄漏**

实现此功能需要服务器支持以下算法和签名组合：

（1）ECDHE 密钥交换、RSA 签名；

（2）ECDHE 密钥交换、ECDSA 签名；

**面试常见问题，HTTPS优化总结易记版：**

**1、HSTS重定向技术：将http自动转换为https，减少301重定向**

**2、TLS握手优化：在TLS握手完成前客户端就提前向服务器发送数据**

**3、会话标识符：服务器记录下与某客户端的会话ID，下次连接客户端发ID过来就可以直接用之前的私钥交流了**

**4、OSCP Stapling：服务器将带有 CA 机构签名的 OCSP 响应在握手时发给客户端，省的客户端再去CA查询**

**5、完全前向加密PFS：使用更牛逼复杂的秘钥算法**

*部分内容参考：*

*[https://www.cnblogs.com/wqhwe/p/5407468.html][https_www.cnblogs.com_wqhwe_p_5407468.html] *

[https://www.cnblogs.com/xzwblog/p/6834663.html][https_www.cnblogs.com_xzwblog_p_6834663.html]

[https://segmentfault.com/p/1210000009272802/read][https_segmentfault.com_p_1210000009272802_read]

[HTTP_HTTPS]: https://blog.csdn.net/qq_35642036/article/details/82788421?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522160142616219725255500967%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=160142616219725255500967&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_v2~rank_v28-3-82788421.pc_first_rank_v2_rank_v28&utm_term=http%E5%92%8Chttps%E5%8C%BA%E5%88%AB&spm=1018.2118.3001.4187
[Link 1]: https://blog.csdn.net/qq_35642036/article/details/82767070
[70]: /images/20221123/0b108118749441a691f67f7968bff707.png
[70 1]: /images/20221123/e7e9aac34c0b47c4a64dfe2c1d7eaaac.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NjQyMDM2_size_16_color_FFFFFF_t_70]: /images/20221123/afc4c716be2045509fcb86a108906a71.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NjQyMDM2_size_16_color_FFFFFF_t_70 1]: /images/20221123/b019b93e4f764de3a1686daa38395cfa.png
[https_images2015.cnblogs.com_blog_1156565_201705_1156565-20170510103645238-169942462.png]: /images/20221123/7ba4830299c9418ebe22354eb9655919.png
[70 2]: /images/20221123/5a9eac637e4e4bc7bd986734f9df5694.png
[https_www.cnblogs.com_mylanguage_p_5635524.html]: https://www.cnblogs.com/mylanguage/p/5635524.html
[Link 2]: https://zh.wikipedia.org/wiki/%E5%AF%86%E9%92%A5
[Link 3]: https://zh.wikipedia.org/wiki/%E6%9C%83%E8%A9%B1%E5%AF%86%E9%91%B0
[https_www.cnblogs.com_wqhwe_p_5407468.html]: https://www.cnblogs.com/wqhwe/p/5407468.html
[https_www.cnblogs.com_xzwblog_p_6834663.html]: https://www.cnblogs.com/xzwblog/p/6834663.html
[https_segmentfault.com_p_1210000009272802_read]: https://segmentfault.com/p/1210000009272802/read