关于HTTP安全性的问题,我们可以使用HTTPS来解决。但是HTTP都发布十几年了,有些规则已经过时了,HTTP/1.1的规则在功能上完全可以开发一套新的协议来弥补,但是由于遵循HTTP协议的Web浏览器已经遍布全球,无法完全抛弃,只能在HTTP基础上不断的累加一些新的功能来满足需求。SPDY就是其中之一。
SPDY(取自SPeeDY,发音同speedy)是Google在2010年发布的,其开发目标旨在解决HTTP的性能瓶颈,缩短Web页面的加载时间。
SPDY并不是一种用于替代HTTP的协议,而是对HTTP协议的增强。 新协议的功能包括数据流的多路复用、请求优先级以及HTTP报头压缩等新机制。Google表示,引入SPDY协议后,在实验室测试中页面加载速度比原先快64%。
SPDY出现以后很多著名的互联网公司,例如百度、淘宝、UPYUN 都在自己的网站或 APP 中采用了 SPDY 系列协议,因为它对性能的提升是显而易见的。主流的浏览器(谷歌、火狐、Opera)也都早已经支持 SPDY,它已经成为了工业标准(其实现在的情况不是这样了,留个悬念后面说),HTTP Working-Group 最终决定以 SPDY/2 为基础,开发 HTTP/2。
SPDY以会话的形式加入,为了安全,它强制性使用SSL/TLS,控制对数据的流动,但还是采用HTTP建立通信连接。
前面简单说了一下SPDY的历史和发展,那么我们首先来看一下HTTP到底有哪些瓶颈,和引入SPDY的必要性。
首先来说最初的HTTP/1.0的时候,一次TCP的链接上只能发送一个HTTP请求,导致HTTP传输的效率特别低。
好在HTTP/1.1的时候,引入了持久链接和管道机制,使得HTTP的传输效率得到了很大的提升(详细和可查看 HTTP基本认识 )。持久链接满足了一条TCP链接可以发送多条HTTP请求的问题,但是每次HTTP请求必须等上一次HTTP响应了以后才能发送新的一条HTTP请求。管道机制实现了在持久链接的基础上 同时 发送多条HTTP请求的机制,但是响应的时候必须按照顺序来响应(如下图)。
HTTP/1.1之前的HTTP请求的只能有客户端发起,服务端返回响应。这种模式导致服务端不能主动发送信息给客户端,所以一些像股票之类的要求时效性的信息无法及时推送到客户端。当然人们研究出了轮训、长轮询、流等解决方案实现,其中著名的就是Comet技术。但是它也存在问题,不是本文重点,就做详细描述了。
HTTP请求或者响应首部每次都要发送一些相关信息,但是HTTP/1.1之前每次HTTP请求都要重复发送这些信息,这样就有些浪费带宽了,而且现在首部信息越来越多,这个问题就更严重了。
HTTP/1.0中就提出了Content-Encoding字段来压缩数据,但是可任意选择数据压缩格式,非强制压缩发送。
针对以上HTTP的瓶颈,Google在2010年发布了SPDY。
通过单一的TCP链接,可以无限制处理多个HTTP请求,所有请求的处理都在一条TCP连接上完成,因此TCP的处理效率得到提高。
SPDY不仅可以无限制地并发处理请求,还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时,解决因带宽低而导致响应变慢的问题。
压缩HTTP请求和响应首部。这样一来,通信产生的数据包数量和发送的字节数就更少了。
支持服务器主动向客户端推送数据的功能。这样服务器可直接发送数据,而不必等待客户端的请求了。
服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在,因此在资源已缓存等情况下,可以避免发送不必要的请求。
前面说了这么多SPDY的优点,但是
所以现在你可以去直接学习HTTP/2了,好在HTTP Working-Group 最终决定以 SPDY/2 为基础,开发 HTTP/2。
按照OSI网络分层模型,IP是网络层协议,TCP是传输层协议,而HTTP是应用层的协议。在这三者之间,SPDY和WebSocket都是与HTTP相关的协议,而TCP是HTTP底层的协议。一、HTTP的不足
HTTP协议经过多年的使用,发现了一些不足,主要是性能方面的,包括:
HTTP的连接问题,HTTP客户端和服务器之间的交互是采用请求/应答模式,在客户端请求时,会建立一个HTTP连接,然后发送请求消息,服务端给出应答消息,然后连接就关闭了。(后来的HTTP1.1支持持久连接)
因为TCP连接的建立过程是有开销的,如果使用了SSL/TLS开销就更大。
在浏览器里,一个网页包含许多资源,包括HTML,CSS,JavaScript,图片等等,这样在加载一个网页时要同时打开连接到同一服务器的多个连接。
HTTP消息头问题,现在的客户端会发送大量的HTTP消息头,由于一个网页可能需要50-100个请求,就会有相当大的消息头的数据量。
HTTP通信方式问题,HTTP的请求/应答方式的会话都是客户端发起的,缺乏服务器通知客户端的机制,在需要通知的场景,如聊天室,游戏,客户端应用需要不断地轮询服务器。
而SPDY和WebSocket是从不同的角度来解决这些不足中的一部分。除了这两个技术,还有其他技术也在针对这些不足提出改进。
二、SPDY
SPDY的主要目的是减少50%以上的页面加载时间,但是呢不增加部署的复杂性,不影响客户端和服务端的Web应用,只需要浏览器和Web服务器支持SPDY。主要有以下几点:
多路复用,一个TCP连接上同时跑多个HTTP请求。请求可设定优先级。
去除不需要的HTTP头,压缩HTTP头,以减少需要的网络带宽。
使用了SSL作为传输协议提供数据安全。
对传输的数据使用gzip进行压缩
提供服务方发起通信,并向客户端推送数据的机制。
实质上,SPDY就是想不影响HTTP语义的情况下,替换HTTP底层传输的协议来加快页面加载时间。
SPDY的解决办法就是设计了一个会话层协议--帧协议,解决多路复用,优先级等问题,然后在其上实现了HTTP的语义。
三、WebSocket
WebSocket则提供使用一个TCP连接进行双向通讯的机制,包括网络协议和API,以取代网页和服务器采用HTTP轮询进行双向通讯的机制。
本质上来说,WebSocket是不限于HTTP协议的,但是由于现存大量的HTTP基础设施,代理,过滤,身份认证等等,WebSocket借用HTTP和HTTPS的端口。
由于使用HTTP的端口,因此TCP连接建立后的握手消息是基于HTTP的,由服务器判断这是一个HTTP协议,还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手,数据传输和HTTP没丁点关系了。
WebSocket也有自己一套帧协议。
四、SPDY和WebSocket的关系
SPDY和WebSocket的关系比较复杂。
补充关系,二者侧重点不同。SPDY更侧重于给Web页面的加载提速,而WebSocket更强调为Web应用提供一种双向的通讯机制以及API。
竞争关系,二者解决的问题有交集,比如在服务器推送上SPDY和WebSocket都提供了方案。
承载关系,试想,如果SPDY的标准化早于WebSocket,WebSocket完全可以侧重于API,利用SPDY的帧机制和多路复用机制实现该API。 Google提出草案,说WebSocket可以跑在SPDY之上。WebSocket的连接建立在SPDY的流之上,将WebSocket的帧映射到SPDY的帧上。
融合关系,如微软在HTTP Speed+Mobility中所做的。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)