本文主要是介绍http,https,spdy,http2等协议的主要区别详解,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
http,https,spdy,http2等协议的主要区别详解
SPDY、HTTP/2、QUIC协议
SPDY, HTTP/2, QUIC protocol
幂等和非幂等的关系与区别
技术分享之http2和quic的那些事儿
HTTP发展史(HTTP1.1,HTTPS,SPDY,HTTP2.0,QUIC,HTTP3.0)
程序员面试必考题(二十五)—SPDY与HTTP/2协议
HTTP协议篇(一):多路复用、数据流
HTTTP 2.0原理解析
一文读懂HTTP/2及HTTP/3特性
试图取代 TCP 的 QUIC 协议到底是什么?
一、总结
要了解HTTP2.0,先了解一下HTTP超文本传输协议的历史(HyperText Transfer Protocol),这是为了实现互联网上内容传输提出的协议,其历史伴随着互联网的发展。整个HTTP协议发展历程如下:
一句话介绍:
HTTP 0.9:基于GET请求的文本传输协议
HTTPS:安全的HTTP传输协议
HTTP 1.0:增加HTTP头、扩展PUT、POST等方法
HTTP 1.1:长连接、流水线支持,最广泛使用的HTTP传输协议
SPDY:针对HTTP的增强,工作在SSL层之上、HTTP层之下
HTTP 2.0:安全高效的下一代HTTP传输协议
根据W3Techs统计,到现在为止,互联网上前1000万的网站,已经有27.9%支持了HTTP2.0。
HTTP/1.x 有连接无法复用、队头阻塞、协议开销大和安全因素等多个缺陷
HTTP/2 通过多路复用、二进制流、Header 压缩等等技术,极大地提高了性能,但是还是存在着问题的
QUIC 基于 UDP 实现,是 HTTP/3 中的底层支撑协议,该协议基于 UDP,又取了 TCP 中的精华,实现了即快又可靠的协议
二、HTTP1.0和HTTP1.1的一些区别
1、缓存处理: 在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
2、带宽优化及网络连接的使用: HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。
3、错误通知的管理: 在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
4、Host头处理: 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。
5、长连接: HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,其中长连接也就是对应在HTTP1.1中的Connection: keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
三、HTTP2.0和SPDY的区别
HTTP2.0 支持明文 HTTP 传输,而 SPDY 强制使用 HTTPS
HTTP2.0 消息头的压缩算法采用 HPACK,而 SPDY 采用的是 DEFLATE
四、HTTPS与HTTP的区别
1、HTTPS协议需要到CA申请证书,一般免费证书很少,需要交费。
2、HTTP是超文本传输协议,信息是明文传输,HTTPS则是具有安全性的TLS加密传输协议。
3、HTTP和HTTPS使用的是完全不同的连接方式,用的默认端口也不一样,前者是80,后者是443。
4、HTTPS的连接很简单,HTTPS协议是由TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议,比HTTP协议安全。
5、HTTPS可以有效的防止运营商劫持,解决了防劫持的一个大问题
五、SPDY对比HTTP的优势 & 缺点:
1、优势:
(1)复用连接: 可在一个TCP连接上传送多个资源。应对了TCP慢启动的特性。
(2)请求分优先级: 重要的资源优先传送。
(3)HTTP头部压缩: HTTP头部数据也被压缩,省流量。
(4)主动推送: 服务器端可主动连接客户端来推送资源(Server Push)。
2、缺点: SPDY单连接会因TCP线头阻塞(head-of-line blocking)的特性而传输速度受限。加上存在可能丢包的情况,其负面影响已超过压缩头部和优先级控制带来的好处。
由于这些缺点,SPDY在小网站(资源文件数量较少)的效果不明显,有可能比多并发连接更慢。(由此催生了QUIC)
六、多路复用
虽然 HTTP 1.1 默认启用长TCP连接,但所有的请求-响应都是按序进行的(这里的长连接可理解成半双工协议。即便是HTTP 1.1引入了管道机制,也是如此)。复用同一个TCP连接期间,即便是通过管道同时发送了多个请求,服务端也是按请求的顺序依次给出响应的;而客户端在未收到之前所发出所有请求的响应之前,将会阻塞后面的请求(排队等待),这称为"队头堵塞"(Head-of-line blocking)。
HTTP/2复用TCP连接则不同,虽然依然遵循请求-响应模式,但客户端发送多个请求和服务端给出多个响应的顺序不受限制,这样既避免了"队头堵塞",又能更快获取响应。在复用同一个TCP连接时,服务器同时(或先后)收到了A、B两个请求,先回应A请求,但由于处理过程非常耗时,于是就发送A请求已经处理好的部分, 接着回应B请求,完成后,再发送A请求剩下的部分。HTTP/2长连接可以理解成全双工的协议。
七、http1.1问题:
1、管道机制(Pipelining)
HTTP 1.1 引入了管道机制(Pipelining),即客户端可通过同一个TCP连接同时发送多个请求。如果客户端需要请求两个资源,以前的做法是在同一个TCP连接里面,先发送A请求,然后等待服务器做出回应,收到后再发出B请求;而管道机制则允许浏览器同时发出A请求和B请求,但是服务器还是按照顺序,先回应A请求,完成后再回应B请求。
HTTP 1.1 管线化是将多个 HTTP 请求整批提交的技术,而在传送过程中不需先等待服务端的回应。管线化机制须通过永久连接(persistent connection)完成。浏览器将HTTP请求大批提交可大幅缩短页面的加载时间,特别是在传输延迟(lag/latency)较高的情况下。有一点需要注意的是,只有幂等的请求可以使用 pipeline,如 GET,HEAD 方法。
2、存在的问题
head of line blocking会导致带宽无法被充分利用,以及后续健康请求被阻塞。假设有5个请求同时发出,如下图。 对于http1.0的实现,在第一个请求没有收到回复之前,后续从应用层发出的请求只能排队,请求2,3,4,5只能等请求1的response回来之后才能逐个发出。网络通畅的时候性能影响不大,一旦请求1的request因为什么原因没有抵达服务器,或者response因为网络阻塞没有及时返回,影响的就是所有后续请求,问题就变得比较严重了。
八、HTTP/2 新特性
-
二进制传输
HTTP/2 采用二进制格式传输数据,而非 HTTP 1.x 的文本格式,二进制协议解析起来更高效。 HTTP / 1 的请求和响应报文,都是由起始行,首部和实体正文(可选)组成,各部分之间以文本换行符分隔。HTTP/2 将请求和响应数据分割为更小的帧,并且它们采用二进制编码。 -
多路复用
在 HTTP/2 中引入了多路复用的技术。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题,同时也接更容易实现全速传输,毕竟新开一个 TCP 连接都需要慢慢提升传输速度。 -
Header 压缩
在 HTTP/1 中,我们使用文本的形式传输 header,在 header 携带 cookie 的情况下,可能每次都需要重复传输几百到几千的字节。为了减少这块的资源消耗并提升性能, HTTP/2对这些首部采取了压缩策略:
(1)HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键-值对,对于相同的数据,不再通过每次请求和响应发送;
(2)首部表在HTTP/2的连接存续期内始终存在,由客户端和服务器共同渐进地更新;
(3)每个新的首部键-值对要么被追加到当前表的末尾,要么替换表中之前的值 -
Server Push
Server Push即服务端能通过push的方式将客户端需要的内容预先推送过去,也叫“cache push”。
可以想象以下情况,某些资源客户端是一定会请求的,这时就可以采取服务端 push 的技术,提前给客户端推送必要的资源,这样就可以相对减少一点延迟时间。当然在浏览器兼容的情况下你也可以使用 prefetch。
例如服务端可以主动把JS和CSS文件推送给客户端,而不需要客户端解析HTML时再发送这些请求。
九、HTTP3.0是什么?
HTTP3.0,也称作HTTP over QUIC。HTTP3.0的核心是QUIC(读音quick)协议,由Google在2015年提出的SPDY v3演化而来的新协议,传统的HTTP协议是基于传输层TCP的协议,而QUIC是基于传输层UDP上的协议,可以定义成:HTTP3.0基于UDP的安全可靠的HTTP2.0协议。
虽然 HTTP/2 解决了很多之前旧版本的问题,但是它还是存在一个巨大的问题,主要是底层支撑的 TCP 协议造成的。
上文提到 HTTP/2 使用了多路复用,一般来说同一域名下只需要使用一个 TCP 连接。但当这个连接中出现了丢包的情况,那就会导致 HTTP/2 的表现情况反倒不如 HTTP/1 了。
因为在出现丢包的情况下,整个 TCP 都要开始等待重传,也就导致了后面的所有数据都被阻塞了。但是对于 HTTP/1.1 来说,可以开启多个 TCP 连接,出现这种情况反到只会影响其中一个连接,剩余的 TCP 连接还可以正常传输数据。
那么可能就会有人考虑到去修改 TCP 协议,其实这已经是一件不可能完成的任务了。因为 TCP 存在的时间实在太长,已经充斥在各种设备中,并且这个协议是由操作系统实现的,更新起来不大现实。
基于这个原因,Google 就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议,并且使用在了 HTTP/3 上,HTTP/3 之前名为 HTTP-over-QUIC,从这个名字中我们也可以发现,HTTP/3 最大的改造就是使用了 QUIC。
QUIC 虽然基于 UDP,但是在原本的基础上新增了很多功能,接下来我们重点介绍几个QUIC新功能。
2. QUIC新功能
(1)0-RTT
所谓QUIC的预连接,就是在进入弱网状态前提前建立QUIC连接。大家都知道QUIC引以为傲的0RTT,但第一次建立连接的时候是需要1RTT的,客户端首先会向服务器发送一个client hello消息,服务器会回复一个server reject消息,这个消息中包括了server config,有了server config后客户端就可以直接计算出密钥,完成0RTT。
通过使用类似 TCP 快速打开的技术,缓存当前会话的上下文,在下次恢复会话的时候,只需要将之前的缓存传递给服务端验证通过就可以进行传输了。0RTT 建连可以说是 QUIC 相比 HTTP2 最大的性能优势。那什么是 0RTT 建连呢?
这里面有两层含义:
传输层 0RTT 就能建立连接。
加密层 0RTT 就能建立加密连接。
上图左边是 HTTPS 的一次完全握手的建连过程,需要 3 个 RTT。就算是会话复用也需要至少 2 个 RTT。
而 QUIC 呢?由于建立在 UDP 的基础上,同时又实现了 0RTT 的安全握手,所以在大部分情况下,只需要 0 个 RTT 就能实现数据发送,在实现前向加密的基础上,并且 0RTT 的成功率相比 TLS 的会话记录单要高很多。
(2)多路复用
虽然 HTTP/2 支持了多路复用,但是 TCP 协议终究是没有这个功能的。QUIC 原生就实现了这个功能,并且传输的单个数据流可以保证有序交付且不会影响其他的数据流,这样的技术就解决了之前 TCP 存在的问题。
同HTTP2.0一样,同一条 QUIC连接上可以创建多个stream,来发送多个HTTP请求,但是,QUIC是基于UDP的,一个连接上的多个stream之间没有依赖。比如下图中stream2丢了一个UDP包,不会影响后面跟着 Stream3 和 Stream4,不存在 TCP 队头阻塞。虽然stream2的那个包需要重新传,但是stream3、stream4的包无需等待,就可以发给用户。
另外QUIC 在移动端的表现也会比 TCP 好。因为 TCP 是基于 IP 和端口去识别连接的,这种方式在多变的移动端网络环境下是很脆弱的。但是 QUIC 是通过 ID 的方式去识别一个连接,不管你网络环境如何变化,只要 ID 不变,就能迅速重连上。
(3)加密认证的报文
TCP 协议头部没有经过任何加密和认证,所以在传输过程中很容易被中间网络设备篡改,注入和窃听。比如修改序列号、滑动窗口。这些行为有可能是出于性能优化,也有可能是主动攻击。
但是 QUIC 的 packet 可以说是武装到了牙齿。除了个别报文比如 PUBLIC_RESET 和 CHLO,所有报文头部都是经过认证的,报文 Body 都是经过加密的。
这样只要对 QUIC 报文任何修改,接收端都能够及时发现,有效地降低了安全风险。
如上图所示,红色部分是 Stream Frame 的报文头部,有认证。绿色部分是报文内容,全部经过加密。
(4)向前纠错机制
QUIC协议有一个非常独特的特性,称为向前纠错 (Forward Error Correction,FEC),每个数据包除了它本身的内容之外,还包括了部分其他数据包的数据,因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。向前纠错牺牲了每个数据包可以发送数据的上限,但是减少了因为丢包导致的数据重传,因为数据重传将会消耗更多的时间(包括确认数据包丢失、请求重传、等待新数据包等步骤的时间消耗)
假如说这次我要发送三个包,那么协议会算出这三个包的异或值并单独发出一个校验包,也就是总共发出了四个包。当出现其中的非校验包丢包的情况时,可以通过另外三个包计算出丢失的数据包的内容。当然这种技术只能使用在丢失一个包的情况下,如果出现丢失多个包就不能使用纠错机制了,只能使用重传的方式了。
3、总结
(1)QUIC 协议有哪些优点,如何实现 0-RTT?
a、QUIC 协议在传输层就支持多路复用,避免了队头阻塞问题。
b、QUIC 协议基于 UDP,更自由更高效
c、QUIC 协议借鉴了 TFO 的思想,支持会话上下文缓存,方便恢复, 具备实现 0-RTT 的可能
(2)传统的 HTTP2 + SSL + TCP 协议栈有哪些缺点?
a、SSL 的会话恢复依然需要一个 RTT,而且难以合并到 TCP 层
b、TCP 的滑动窗口存在队头阻塞问题
c、TCP 的重传纠错会浪费一个 RTT
(3)为什么 Google 要另起炉灶,基于 UDP 去做?
a、TCP 由操作系统实现,很难更新
b、UDP 非常高效,几乎没有性能负担
c、将 QUIC 嵌入到 Chrome 中可以方便后续的升级迭代
这篇关于http,https,spdy,http2等协议的主要区别详解的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!