架构与思维:了解Http 和 Https的区别(图文详解)

http,https · 浏览次数 : 0

小编点评

一、引言 随着网络的普及和发展,HTTPS逐渐成为了主流的网络传输协议。本文将从原理上对HTTPS的安全性进行讲解,并与HTTP进行比较。 二、HTTP与HTTPS的区别 1. 协议版本:HTTP(Hypertext Transfer Protocol),即超文本传输协议;HTTPS(Hypertext Transfer Protocol Secure),即超文本传输安全协议。 2. 加密方式:HTTP是明文传输协议,而HTTPS是加密传输协议。 3. 安全性:HTTPS通过加密技术和身份认证机制,提供更高的安全防护。 4. 身份验证:HTTPS使用数字证书验证服务器身份,保证数据传输安全。 5. 性能:HTTPS在加密和解密操作上可能略低于HTTP,但差距已经接近可以忽略。 三、HTTPS原理及实现 1. 加密方式:HTTPS结合了对称加密和非对称加密技术,确保数据传输安全。 2. 密钥交换:通过非对称加密,服务器将公钥发送给客户端,实现安全密钥交换。 3. 数据完整性与防篡改:HTTPS引入消息认证码(MAC),并使用哈希函数确保数据包的完整性和不被篡改。 四、HTTPS的优势和应用 1. 敏感信息传输:HTTPS支持传输敏感信息,如信用卡号、密码等,提高了安全性。 2. 安全防护:HTTPS引入了SSL/TLS安全认证证书,提供了更高的安全防护。 3. 浏览器提示:HTTPS有绿色安全锁标志,表示网站安全,降低用户风险感知。 五、总结 HTTPS作为一种加密传输协议,在安全性、身份验证等方面相较于HTTP具有明显优势。在敏感信息传输的场景中,如在线购物、银行业务等,HTTPS已成为首选数据传输协议。

正文

1 介绍

随着 HTTPS 的不断普及和使用成本的下降,现阶段大部分的系统都已经开始用上 HTTPS 协议。 HTTPS 与 HTTP 相比, 主打的就是安全概念,相关的知识如 SSL 、非对称加密、 CA证书、数据完整性保护 等,我们多多少少也都有听过。 本文重点从原理上讲解 HTTPS 的安全性,以及同HTTP的比较说明。

2 HTTP和HTTPS的比较

HTTP(全称:HyperText Transfer Protocol,超文本传输协议)和HTTPS(全称: Hypertext Transfer Protocol Secure,超文本传输安全协议)都是互联网中用于数据传输的协议,它们在多个方面有着显著的差异和特点。

image

2.1 HTTP

HTTP(Hypertext Transfer Protocol),是一种发送和接收HTML页面的方法,主要用于Web浏览器和网站服务器之间传递信息。它的主要特点如下:

1. 基于请求响应模式: HTTP协议采用客户端-服务器架构模式,客户端向服务器发送请求,服务器返回相应的响应。这种模式能有效分离应用逻辑,提高系统的可维护性和扩展性。
2. 基于文本传输: HTTP协议使用ASCII码作为通信协议,每个请求和响应都是一条文本消息,这使得通信协议更加简单、直观、易于处理。
3. 支持多媒体传输: HTTP协议可以传输多种类型的数据,如HTML、XML、JSON、图片、音频、视频等,这使得HTTP协议成为一种通用的网络传输协议,适用于各种不同类型的应用场景。
4. 无连接: HTTP协议是一个无连接协议,每个请求都是独立的,服务器处理请求后立即关闭连接。这有助于节省资源,但也带来了一些缺点,如需要重新建立连接、重复发送相同的头部信息等。
5. 无状态: HTTP协议没有客户端的状态存储,也没有事务处理的“内存”能力。这意味着每次访问网站时可能需要重复的登录操作。

然而,HTTP协议也存在一些不足之处。由于它以明文方式发送内容,不提供任何方式的数据加密,因此安全性较差。如果攻击者截取了Web浏览器和网站服务器之间的传输报文,就可以直接读懂其中的信息。因此,HTTP协议不适合传输一些敏感信息,比如信用卡号、密码等支付信息。

2.2 HTTPS

与HTTP相比,HTTPS(Hypertext Transfer Protocol Secure)则是以安全为目标的HTTP通道。它在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS的内容加密、身份验证以及数据完整性保护的原理主要依赖于SSL/TLS协议。下面我们详细来看看这几方面的实现原理。

2.2.1 内容加密

HTTPS使用对称加密和非对称加密相结合的方式来实现内容加密。

1. 对称加密:在密钥交换完成后,客户端和服务器会生成一个共享的会话密钥。这个会话密钥用于后续的加密和解密操作。双方使用这个会话密钥,通过对称加密算法(如AES)对传输的数据进行加密和解密,确保数据在传输过程中的安全性。

image

如上图,对称加密虽然保证了消息的保密性,但是因Client和Service共享一个密匙,这样就导致密匙特别容易泄露。

2. 非对称加密:在HTTPS的握手阶段,服务器会将其公钥发送给客户端。这个公钥用于后续的加密通信。客户端使用服务器的公钥加密一个随机数,然后将加密后的随机数发送给服务器。服务器使用其私钥解密这个随机数,从而确保双方都能安全地交换密钥,这个过程称为密钥交换。

image

如上图,

  • 非对称加密时需要使用到接收方的公匙对消息进行加密,但是公匙不保密,可以截获客户端发来的消息,然后篡改形成攻击
  • 非对称加密的性能会慢上至少几倍,增加系统消耗。因此,Https将两种加密结合起来使用。

2.2.2 身份验证

HTTPS使用数字证书来验证服务器的身份。

1. 数字证书:数字证书是由权威的证书颁发机构(CA)颁发的,包含了服务器的公钥、服务器的身份信息以及CA的签名等信息。当客户端与服务器建立HTTPS连接时,服务器会将其数字证书发送给客户端。

2. 验证过程客户端收到服务器的数字证书后,会验证证书的合法性。首先,客户端会检查证书是否由受信任的CA颁发。然后,客户端会检查证书是否过期以及证书中的服务器身份信息是否与正在连接的服务器一致。最后,客户端会使用CA的公钥验证证书上的签名,确保证书在传输过程中没有被篡改。如果证书验证通过,客户端就可以确认服务器的身份是可信的。

image

2.2.3 数据完整性

HTTPS通过消息认证码(MAC)来确保数据的完整性。

1. 消息认证码:在HTTPS通信过程中,每个传输的数据包都会附带一个MAC值。这个MAC值是通过将数据包的内容和会话密钥一起输入到一个哈希函数中计算得出的。因此,只有持有相同会话密钥的接收方才能计算出正确的MAC值。

2. 完整性校验:当接收方收到数据包时,它会使用相同的会话密钥和哈希函数计算MAC值,并与数据包中附带的MAC值进行比较。如果两个MAC值相同,那么接收方就可以确认数据包在传输过程中没有被篡改,从而保证了数据的完整性和安全性。

image

2.2.4 端口

HTTP 默认使用 80 端口,而 HTTPS 默认使用 443 端口

2.2.5 性能

因为HTTPS 需要进行加密和解密操作,因此它的性能可能略低于 HTTP。但随着技术的发展,这种性能差距已经接近可以忽略。

3 总结

HTTP和HTTPS在差异方面,最显著的是安全性。HTTP是明文传输协议,而HTTPS是加密传输协议。这种加密特性使得HTTPS在传输敏感信息时更具优势。此外,浏览器地址展示方式也有所不同,Https有绿色安全锁标志,而http则有网站不安全标志提醒。在协议层面,HTTPS在HTTP的基础上加入了SSL安全认证证书,从而提供了更高级别的安全防护。在涉及敏感信息传输的场景中,如在线购物、银行业务等,基本都是用HTTPS协议进行数据传输。

与架构与思维:了解Http 和 Https的区别(图文详解)相似的内容:

架构与思维:了解Http 和 Https的区别(图文详解)

1 介绍 随着 HTTPS 的不断普及和使用成本的下降,现阶段大部分的系统都已经开始用上 HTTPS 协议。 HTTPS 与 HTTP 相比, 主打的就是安全概念,相关的知识如 SSL 、非对称加密、 CA证书、数据完整性保护 等,我们多多少少也都有听过。 本文重点从原理上讲解 HTTPS 的安全性

架构与思维:4大主流分布式算法介绍(图文并茂、算法拆解)

0 导读 之前的文章中,我们介绍过分布式事务的基础知识,也了解了分布式场景下常见一致性问题和解决方案,对分布式锁和CAS模式有一定的了解,有兴趣的同学可以通过下面链接到作者的两篇相关文章。 五种分布式事务解决方案(图文总结) 高并发下的数据一致性保障(图文全面总结) 1 介绍 本文聚焦高并发场景下分

架构与思维:再聊缓存击穿,面试是一场博弈

1 介绍 在之前的一篇文章《一次缓存雪崩的灾难复盘》中,我们比较清晰的描述了缓存雪崩、穿透、击穿的各自特征和解决方案,想详细了解的可以移步。 最近在配合HR筛选候选人,作为大厂的业务方向负责人,招人主要也是我们自己团队在用,而缓存是必不可少的面试选项之一。下面我们就来聊一聊在特定业务场景下缓存击穿和

架构与思维:秒杀和竞拍的业务架构,永不过时的话题

1 互联网架构越来越复杂? 为啥感觉互联网架构越来越复杂了,早期我们的系统,可能也就那么少部分人使用,大都是一些后台管理系统。 所以不用考虑很多东西,比如: 流量少,无需考虑并发问题 数据少,不用考虑什么索引优化、分库分表 访问不集中,不用考虑缓存、过载保护 如果数据不重要,不用考虑安全策略,甚至不

架构与思维:微服务架构的思想本质

我们为什么需要微服务架构,它一定是为了解决我们某些问题才出现了。这篇文章我们讨论下微服务架构模式所解决的问题,带来的挑战,以及他的核心思想本质。 1 早期的服务架构 上图是一个典型的服务分层架构: Client: 调用方是browser web或者App 应用层: 实现计算层的业务逻辑,从上游数据层

凭证管理揭秘:Cookie-Session 与 JWT 方案的对决

在软件架构中,关于凭证如何存储和传递,一直有两种不同的解决思路,两种不同的解决方式,实际上反映了两种不同的架构思路

凭证管理揭秘:Cookie-Session 与 JWT 方案的对决

在软件架构中,关于凭证如何存储和传递,一直有两种不同的解决思路,两种不同的解决方式,实际上反映了两种不同的架构思路

我对《RAG/大模型/非结构化数据知识库类产品》技术架构的思考、杂谈

1、前言 在6.28/29的稀土掘金开发者大会RAG专场上,我们公司CEO员外代表TorchV分享了我们在《RAG在企业应用中落地的难点与创新》 其中最后分享了两个观点: AI在应用场景落地时有三个特点:功能小、质量高、价值大 如果说做产品是把一横做好的话,那么去做企业落地服务就是一竖,从需求和方案

微服务架构必备技术栈:万变不离其宗的奥义!

前言 之前我们说过,微服务是一种软件设计、架构思想。当然,里面也包含了相关技术点要解决当前要务。学习微服务,我们不能空口而谈,一定要落实到具体的技术栈上。 当今使用比较多两个技术体系,一个是Java,另外一个就是Net。 废话不多说,今天我就把相关“微服务架构”所用到的技术栈罗列出来。(以下是微软相

架构师日记-到底该如何搭建一个新系统

本文详细介绍了搭建系统工程架构时需要关注的几个重要方面。基于产品的价值,做出决策。并从系统工程架构的演进、技术方案的选型、系统规范共识的达成等方面入手,对实施过程中的常见问题给出了解决思路。