关于HTTP、HTTPS、HTTP1.1、HTTP2.0、HTTP3.0的介绍及区别

HTTP与HTTPS的区别

一、HTTP的简介

       HTTP(超文本传输协议)是一种用于分布式、协作式和超媒体信息系统的应用层协议,常基于TCP/IP协议传输数据,互联网上应用最为广泛的一种网络协议,所有的www文件都必须遵循这个标准。设计初衷是为了提供一种发布和接收HTML页面的方法。

二、HTTPS的简介

       HTTPS(超文本传输安全协议)是一种透过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信,但利用 SSL/TLS 来加密数据包。HTTPS开发的主要目的是提供对网站服务器的身份认证,保护交换数据的隐私与完整性。

其中,

SSL(安全套接层)是基于HTTPS下的一个协议加密层,它是一项标准技术,可确保互联网连接安全,保护两个系统发送的任何敏感数据,防止网络犯罪分子读取和修改任何传输信息,包括个人资料。两个系统可指服务器和客户端,或两个服务器之间。该协议由两层组成:SSL记录协议和SSL握手协议。

TLS(安全传输层协议)是更为安全的升级版SSL,用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成:TLS记录协议和TLS握手协议。TLS的最大优势在于:TLS是独立于应用协议。高层协议可以透明地分布在TLS协议上面。

三、HTTP与HTTPS的区别

  • HTTP明文传输,数据都是未加密的,安全性较差。HTTPS(SSL+HTTP)数据传输过程是加密的,安全性较好。(HTTPS=HTTP+加密+认证+完整性保护)
  • HTTPS需要CA(数字证书认证机构)申请证书,HTTP不需要。
  • HTTP页面响应速度比HTTPS快,主要是因为HTTP使用TCP三次握手建立连接,客户端和服务器需要交换3个包,而HTTPS除了TCP的三个包,还要加上SSL握手需要的9个包,所以一共是12个包。
  • HTTP和HTTPS使用的是完全不同的连接方式,用的端口也不一样。HTTP使用80端口,HTTPS默认使用443端口。
  • HTTPS其实就是建构在SSL/TLS之上的HTTP协议,所以,HTTPS比HTTP要更耗费服务器。

HTTPS的工作原理

1.客户端发起HTTPS请求

        用户在浏览器输入一个 https 网址,然后俩街道server的443端口。

2.服务端的配置

       采用HTTPS协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请,区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面(startssl 就是个不错的选择,有 1 年的免费服务)。

3.传送证书

       这个证书其实就是公钥,只是包含了很多信息,如如证书的颁发机构,过期时间等。

4.客户端解析证书

       这部分工作是有客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。

       如果证书没有问题,那么就生成一个随机值,然后用证书对该随机值进行加密,就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。

5、传送加密信息

       这部分传送的是用证书加密后的随机值,目的就是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6、服务端解密信息

       服务端用私钥解密后,得到了客户端传过来的随机值(对称秘钥),然后把内容通过该值进行对称加密,所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。

7、传输加密后的信息

       这部分信息是服务段用私钥加密后的信息,可以在客户端被还原。

8、客户端解密信息

       客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容,整个过程第三方即使监听到了数据,也束手无策。

HTTP1.0和HTTP1.1和HTTP2.0的区别

一、HTTP1.0和HTTP1.1的区别

1.长链接

        HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接,而HTTP1.1默认支持长连接。

        HTTP是基于TCP/IP 协议的,创建一个TCP连接是需要经过三次握手的,有一定的开销,如果每次通讯都要重新创建连接的话,对性能有一定影响、因此最好能维持一个长连接,可以用长连接来发送多个请求。

2.节约带宽

        HTTP1.0中存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送了过来,并且不支持断点续传(利用HTTP消息头,使用分块传输编码,将实体主题分块传输)。

        HTTP1.1支持只发送header信息(不带任何body信息),如果服务器认为客户端有权限请求服务器,则返回100,客户端接收到100 ,才开始把请求body发送到服务器;如果返回401,客户端就可以不用发送请求body,节约了带宽。

3.HOST域

       在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名,HTTP1.0没有host域。在一台物理服务器上可以存在多个虚拟主机,并且它们都共享一个IP地址。HTTP1.1的请求消息和响应消息都支持host域,且请求消息中如果没有host域会报告一个错误。

4.缓存控制

        HTTP1.0中主要使用header里的IF-Modified-Since(条件式请求首部,服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回,状态码为 200 。),Expire(HTTP/1.0控制网页缓存的字段,其值为服务器返回该请求结果缓存的到期时间,即再次发起该请求时,如果客户端的时间小于Expires的值时,直接使用缓存结果。)是来作为判断标准。

        HTTP1.1则引入了更多的缓存控制策略和请求响应头。

5.错误通知的管理

         在HTTP1.1中新增了24个错误状态响应码。

二、HTTP1.1和HTTP2.0的区别

1.头部压缩

        HTTP1.1中的请求头携带大量信息,而且每次都要重复发送,即使是同样的内容,每次请求都需要附带,这会造成性能的损耗。HTTP2.0进行了优化,引入了头信息压缩机制。多个请求中,如果请求头相同,则后续请求只需要发送差异的部分,重复的部分无需再发送。

2.二进制帧

       HTTP1.1的报文为纯文本格式,而HTTP2.0的报文全面采用二进制格式,并将原始的报文拆分为头信息帧和数据帧。采用二进制格式有利于提升数据传输效率。

3.多路复用

       HTTP2.0使用了多路复用的技术,做到同一个连接并处理多个请求,而且并发请求的数量比HTTP1.1大了好几个数量级。当然HTTP1.1也可以多建立几个TCP连接,来支持处理更多并发的请求,但是创建TCP连接本身也是有开销的。

4.服务端推送

       在HTTP1.1中,只能客户端发起请求,服务器对请求进行响应。而在HTTP2.0中,服务器可以主动给客户端推送必要的资源,以减少请求延迟时间。

HTTP3相比于HTTP2性能上的改进

1.无队头阻塞

        HTTP2通过多路复用解决了HTTP1.1的队头阻塞问题,但其只是解决了HTTP这一层面的队头阻塞问题,底层仍然采用TCP连接,HTTP2并没有解决TCP的队头阻塞问题。TCP是可靠的,面向字节流的协议。HTTP2的多个请求虽然可以跑在同一个TCP连接中,但如果出现丢包现象,TCP就需要进行重传,这可能就会导致整个TCP连接上的所有流阻塞,直到丢的包重传成功,这就是TCP的丢头阻塞问题。

        HTTP3底层不再使用TCP,而是采用UDP!而UDP是无连接的多个流互相独立,之间不再有依赖,因而即使某个流发生了丢包,只会对该流产生影响,并不会使得其他流阻塞。

HTTP3在应用层之间重新实现了可靠性机制。也就是说,HTTP3将原先TCP协议提供的部分功能上移至QUIC(基于 UDP 的传输层协议),而且进行了改进。

2.优化重传机制

HTTP2使用的是TCP,HTTP3使用的是QUIC。

        TCP 采用序号+确认号+超时重传机制来保证消息的可靠性,即如果某条消息超过一定时间还没有得到确认,则重新发送此消息。由于网络拥堵情况不断变化,因而消息的超时事件并不是固定的,而是通过采样消息的往返时间不断调整的,但TCP超时采样存在不准确的问题。

        QUIC 定义了一个递增的序列号,每个序列号的包只发送一次,及时重传相同的包,其序列号也不一样。

3.连接迁移

        一条TCP连接是由四元组标识的,分别是源IP、源端口、目的IP、目的端口。一旦其中一个元素发生了变化,就需要断开重连。

       QUIC采用一个64位的随机数作为ID来标识,通过此连接ID标记通信的两端,之后即使网络发生变化,IP或端口变了,但只要ID不变,则无需重连,只需要复用原先连接即可,时延低,减少了用户的卡顿感,只实现连接迁移。

总结

本篇文章简要阐述了http与http的区别,https的工作原理,http各种更新迭代版本之间的区别,通过查阅了大量资料,整理出这一篇,在帮助自己总结复习的同时,也能够让其他人参考学习。如果内容有什么问题和错误,可以私聊我提出来,感谢!

 更多详细的SSL、TLS的介绍与区别,请点击该条链接https://blog.csdn.net/enweitech/article/details/81781405

HTTPS原理部分参考了该链接的内容https://www.runoob.com/w3cnote/http-vs-https.html

  • 52
    点赞
  • 44
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
.Net/C# 实现 中国移动 CMPP v3.0 ISMG SP 收发短信的 SP 客户端 (第2版)(CMPP SP Client) 增加了 CMPP Client 类本程序严格按 《中国移动通信企业标准》之《中国移动通信互联网短信网关接口协议(China Mobile Point to Point)》(版本号: 3.0.0) 即: CMPP v3.0.0 http://www.spzone.net/protocol/CMPPV3.0.rar 文档,实现了下面消息的定义及其相关协议级交互: 8.4 业务提供商 (SP) 与互联网短信网关 (ISMG) 间的消息定义 8 8.4.1 SP 请求连接到 ISMG(CMPP_CONNECT) 操作 8 8.4.1.1 CMPP_CONNECT 消息定义 (SP -> ISMG) 8 8.4.1.2 CMPP_CONNECT_RESP消息定义 (ISMG -> SP) 9 8.4.2 SP 或 ISMG 请求拆除连接 (CMPP_TERMINATE)操作 9 8.4.2.1 CMPP_TERMINATE 消息定义 (SP -> ISMG 或 ISMG -> SP) 9 8.4.2.2 CMPP_TERMINATE_RESP 消息定义 (SP -> ISMG 或 ISMG -> SP) 10 8.4.3 SP 向 ISMG提交短信 (CMPP_SUBMIT) 操作 10 8.4.3.1 CMPP_SUBMIT 消息定义 (SP -> ISMG) 10 8.4.3.2 CMPP_SUBMIT_RESP 消息定义 (ISMG -> SP) 11 8.4.5 ISMG 向 SP 送交短信 (CMPP_DELIVER) 操作 13 8.4.5.1 CMPP_DELIVER 消息定义 (ISMG -> SP) 13 8.4.5.2 CMPP_DELIVER_RESP 消息定义 (SP -> ISMG) 16 8.4.7 链路检测 (CMPP_ACTIVE_TEST) 操作 17 8.4.7.1 CMPP_ACTIVE_TEST定义 (SP -> ISMG 或 ISMG <- SP) 17 8.4.7.2 CMPP_ACTIVE_TEST_RESP定义 (SP -> ISMG 或 ISMG <- SP) 17 可采用《中国移动通信 CMPP v3.0 短消息网关模拟器 v1.10》进行测试: 下载于: 《北京风起水流软件工作室》 http://www.zealware.com/download/cmpp3smg.rar本程序以熟悉理解 CMPP 3.0 协议为主要目的,只将 "消息定义" 对象化,其相关协议级交互并未作更深层次的 OO! 也暂无任何错误处理程序! 消息定义的所有字段名称及其数据类型均与上述之 CMPP v3.0.0 文档完全一致! 其间参阅过 shanhe@CSDN or yexiong@cnBlogs 大作(在此鸣谢): http://blog.csdn.net/shanhe/archive/2004/07/19/45383.aspx http://cnblogs.com/yexiong/articles/115330.aspx 但其中有些消息定义字节错位,因此不能正常交互?!且对象化层次较高,不利于理解协议本身! 遂自己动手,丰衣足食,实现部分主要协议(SP 收发短信):
JSF将是J2EE5.0中所包含的web开发框架,这应该是第一个成为jcp标准,并且随j2eesdk一起发布的web框架,可以看出sun对它的期望很高。JSF最大的竞争对手是tapestry,是apache的产品,但是apache又弄出了个myfaces,是对jsf标准的一个实现。也许你也和我一样,在jsf和tapestry之间犹豫很久,将来从apache的态度上应该可以看出二者的走向。在tss上有一篇比较jsf 1.0与tapestry 3.0的文章,内容很扎实到位:http://www.theserverside.com/articles/article.tss?l=JSFTapestry JSF的竞争对手不是struts/webwork之流,它们基本上已经是不同阶段上的东西了,放在一起比较意义不大。 JSF的开发流程和asp.net中所倡导的code behind方式很相似,核心是事件驱动,组件和标签的封装程度非常高,很多典型应用已经不需要开发者去处理http。页面操作会被自动映射到对应的java bean中,后台逻辑只需要同java bean发生交互。整个过程是通过“依赖注入(DI)”来实现的,看来这是目前解偶合的最佳途径啊,spring的影响真是深远。不过正式因为jsf采用了这样的方式,导致开发工作和以前的jsp/struts等都有非常大的不同,需要一定的时间去学习。学习之前建议先对依赖注入有比较清楚的认识,可以参考我的learn Spring in spring系列的第一篇。 本系列将以两个例子来讲解jsf的基本开发,第一个例子当然是hello world。目前可用的jsf ide不多,ibm要到06年才能放出支持jsf的wtp版本。所以我们的例子基本以手写为主,这样也能让我们有更清楚的认识,同时推荐目前最好的jsf开发工具:myeclipse 4.0 GA。后面的例子将会有jsf和hibernate的内容,它都能给予很好的支持。由于myeclipse并不免费,所以我们除了讲解在ide中如何操作外,还会叙述手动操作的具体内容,以免过于依赖开发工具。用什么服务器都可以,这里采用了jboss 4.0.2。如果你的服务器是高版本的tomcat(5.5+),那么必须要删除它自带的一些包才能很好的支持jsf,具体细节请查看它的文档。 请自行下载jsf ri和JSTL 1.1。 废话少说,开始了。 在myeclipse 4.0GA中新建一个web项目,命名为hello,为项目增加对JSTL的支持: 在JSTL的版本中选择1.1
HTTP 协议是一种用于 Web 通信的应用层协议,目前主要有以下几个版本: 1. HTTP/1.0:最早的版本,于 1996 年推出。它使用短连接(即每次请求都需要建立和关闭连接),并且不支持持久连接、管线化、虚拟主机等特性。 2. HTTP/1.1:于 1999 年推出,是目前最广泛使用的版本。它引入了持久连接、管线化、请求头压缩等特性,可以大幅提高网络传输效率。此外,HTTP/1.1 还支持虚拟主机、缓存等特性,使得 Web 应用程序更加灵活和高效。 3. HTTP/2.0:于 2015 年推出,是 HTTP 协议的最新版本。它引入了二进制分帧、多路复用、头部压缩、服务器推送等特性,可以进一步提高传输效率和性能。HTTP/2.0 还支持流量控制、优先级和服务器提示等特性,使得 Web 应用程序更加快速、可靠和安全。 4. HTTP/3.0:正在研究开发中,预计将于未来几年推出。HTTP/3.0 将使用基于 UDP 的 QUIC 协议,可以进一步提高传输效率和性能,同时还具有更好的安全性和可靠性。 总体来说,HTTP/1.0、1.1、2.0、3.0 版本的主要区别在于传输效率、性能和安全性方面的改进。HTTP/1.0 和 1.1 主要是在连接管理和头部处理方面的改进,HTTP/2.0 和 3.0 则在传输协议的基础上引入了更多的特性,如二进制分帧、多路复用、服务器推送等,以提高传输效率和性能。同时,HTTP/2.0 和 3.0 还具有更好的安全性和可靠性,可以更好地满足现代 Web 应用程序的需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值