`
nj_link
  • 浏览: 10863 次
  • 性别: Icon_minigender_1
  • 来自: 厦门
社区版块
存档分类
最新评论

(转)SPDY、HTTP/2、QUIC协议

    博客分类:
  • java
 
阅读更多
1 SPDY协议
1.1 概述SPDY为speedy(单词原意:快速的)的缩写,读音也就是speedy。
SPDY协议已发布过4个草案,分别为版本1、2、3、3.1。目前版本4已在试验阶段,但未发布,Chromium里已有一些针对版本4的代码。
SPDY对比HTTP的优势:
1. 复用连接,可在一个TCP连接上传送多个资源。应对了TCP慢启动的特性。
2. 请求分优先级,重要的资源优先传送。
3. HTTP头部数据也被压缩,省流量。
4. 服务器端可主动连接客户端来推送资源(Server Push)。
缺点:
1. 单连接会因TCP线头阻塞(head-of-line blocking)的特性而传输速度受限。加上存在可能丢包的情况,其负面影响已超过压缩头部和优先级控制带来的好处。

由于这些缺点,SPDY在小网站(资源文件数量较少)的效果不明显,有可能比多并发连接更慢。(由此催生了QUIC)
1.2 协议层次基于安全的考虑,SPDY规定建立在TLS之上,即URL scheme为https。发明者表示TLS的握手是在一定程度上占用了时间和流量,但网络安全是必然的趋势,所以不计较这一成本。协议层次如下:
   SPDY  ←  HTTP 
    ↓
   TLS   ←  NPN 
    ↓
   TCP

对比普通的HTTPS协议层次:
    HTTP 
     ↓
  SSL/TLS  
     ↓
    TCP

SPDY协议虽然在TLS基础上代替了HTTP协议,但SPDY的内容又包含了HTTP协议的内容,用设计模式来理解就是应用装饰者模式扩展了HTTP。
另外为了在TLS之上不使用标准规定的HTTP协议,为TLS扩展出NPN(Next Protocol Negotiation,协议协商)。
1.3 NPNNPN简单来说就是在TLS的握手阶段增加一些字段来表明服务器端和客户端希望在TLS基础上使用HTTP之外的(SPDY)协议。NPN同样是Google提出的,为SPDY铺路。
Client端程序的实现是:握手前对OpenSSL(或封装它的库)设置可接受哪些协议,握手后获取选择了哪个协议,然后按选择的协议进行通信。
1.4 数据格式本节不会完整介绍SPDY,只讲重点,并假定读者熟悉HTTP协议而不解释SPDY中类似HTTP的概念。
SPDY把一次单向传输(服务器到客户端或客户端到服务器)的内容称作帧(frame),按协议组装帧内容称为装帧(framing)。帧内容分为头部(header)和载荷(payload),类似于HTTP的头部(header)和实体(entity),但有以下区别:
1. SPDY的头部都是8个字节,根据其中一些位的数值不同来表示不同的信息,并把HTTP的头部放到SPDY的载荷里。
2. HTTP的实体(除POST信息外)是文件数据(data),SPDY的载荷除了可以是文件数据还可以是其它信息。

根据载荷的内容,帧分为控制帧和数据帧。
控制帧的数据格式:
+----------------------------------+
|C| Version(15bits) | Type(16bits) |
+----------------------------------+
| Flags (8)  |  Length (24 bits)   |
+----------------------------------+
|               Data               |
+----------------------------------+

数据帧的数据格式:
+----------------------------------+
|C|       Stream-ID (31bits)       |
+----------------------------------+
| Flags (8)  |  Length (24 bits)   |
+----------------------------------+
|               Data               |
+----------------------------------+

各数据位的意义:
* C是第一个bit,值为0或1分别表示数据帧和控制帧。
* Version为SPDY协议版本号,目前为3。
* Type用作区分控制帧的类型。
* Flags标记一些操作指示,不同的Type有不同的Flag。常见的是FLAG_FIN表示一个Stream结束。
* Length表示Data的数据长度。
* Data也就是payload。数据帧的Data就是一个文件(HTML文档、图片、脚本等),控制帧的Data根据Type不同而有不同。
* Stream-ID记录流水号。

SPDY把一次HTTP Request/Response来回称作流(Stream),因为复用TCP连接,所以一个SPDY连接里会有多个流。为了区分不同的流,用Stream-ID来标记流水号(注:因为可以reload,所以不能以URL来确定一个流)。Stream-ID还存在于4种控制帧(SYN_STREAM、SYN_REPLY、RST_STREAM、HEADERS)的payload里。
控制帧的8种类型及作用:
1. SYN_STREAM:创建流,在payload里携带请求(Request)。
2. SYN_REPLY:回复创建流,在payload里携带HTTP头部。注意:SPDY把HTTP response拆开,response header放在控制帧SYN_REPLY的payload里并经过压缩,response entity放在数据帧里。
3. RST_STREAM:报告流错误,payload里携带错误类型。
4. SETTINGS:查询或设置控制信息。可处理的信息有8种:上传带宽、下载带宽、Round Trip时间、最大并行流数量、TCP的CWND值、下载重传率、初始窗口(Window)值、证书数量。
5. PING:一种机制来测量Round Trip时间。
6. GOAWAY:通知即将断开TCP连接。
7. HEADERS:可做补充SVN_REPLY中的response header,或传递私有信息,特定的应用可用做自定义的扩展。
8. WINDOW_UPDATE:设置窗口大小。

下图为帧格式的整理参考(需对照协议文档来理解具体意义,可跳过,点击查看大图):

1.5 流程
普通流程如下图:

Server Push的server端流程:回复client端的SYN_STREAM之后,再在server端发起SYN_STREAM,并在payload中用字段Associated_To_Stream_ID表示这个推送与哪个stream关联。
2 HTTP/2
   2.1 概述HTTP/2准第11版草案于2014年3月17日更新在http://http2.github.io/http2-spec/。
HTTP/2由标准化组织来制定,是基于SPDY的,差别是:
1. 增加了HTTP/1.1 Upgrade的机制,可在TCP上直接使用HTTP/2,不像SPDY那样必须在TLS上。
2. HTTPS连接时使用NPN的规范版ALPN(Applcation Layer Protocol Negociation)。
3. 更完善的协议商讨和确认流程。
4. 更完善的Server Push流程。
5. 增加控制帧的种类,并对帧格式考虑得更细致。
6. 有新算法HPACK专门压缩SPDY header block。

HTTP/2文档带有一些示例和详细说明,这是SPDY没有的。
Chromium最新代码和Google网站已支持HTTP2-10(HTTP/2第10版草案)。

2.2 ALPN
    ALPN第5版草案于2014年3月3日发布在http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05。 它是基于NPN的,并做了流程优化,但原则没变,就是在TLS握手过程增加一种协商协议的手段。标准流程为:

Client                                              Server

   ClientHello                     -------->       ServerHello
     (ALPN extension &                               (ALPN extension &
      list of protocols)                              selected protocol)
                                                   Certificate*
                                                   ServerKeyExchange*
                                                   CertificateRequest*
                                   <--------       serverhellodone
certificate*
clientkeyexchange*
certificateverify*
[changecipherspec]
finished                           -------->
                                                   [ChangeCipherSpec]
                                   <--------       Finished
   Application Data                <------->       Application Data

目前Chromium的PC发布版已经在使用ALPN,不用NPN了。

如果server支持HTTP/2,则以状态码101回复,形式如下:
然后双方开始以HTTP/2作为传输协议。否则以HTTP/1.1回复response,即HTTP/1.1 200 OK。

3 QUIC
QUIC是Quick UDP Internet Connections的缩写,读作quick。由Google开发,概要设计文档放在google docshttps://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit,还在不断更新。传输格式的详细设计文档放在https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit。
概要设计文档从TCP/UDP特性、网络安全等考虑出发,做了非常多设计思路方面的论述,开头就阐述了SPDY的4个缺点:

1. 单个包(packet)丢失会阻塞整个流(stream)。
2. TCP避免拥堵的机制做的不好,导致带宽降低和序列化的等待时间开销。
3. TLS会话重连的等待时间开销。握手机制带来额外的Round Trip。
4. TLS解密的开销。先到的包必须等后面的包到来才能解密。

可以认为QUIC是为了解决SPDY在TCP遇到的瓶颈而在UDP上做探索所设计的方案。参考SPDY来理解,可认为QUIC的传输内容分两层,高层类似SPDY,低层是在UDP上模仿实现TCP的面向连接特性和可靠性并加入类似TLS的加密过程。
QUIC的文档还算未完成的状态,且Chromium的实现代码也在完善中,这还是个试验性的半成品,没有性能比较的数据。只浅浅研究即止,不深入了。

4 研究与调查
4.1 SPDY服务器搭建4.1.1 Apache具体的搭建方法请参考《Linux Mint + Apache2.2搭建SSL/HTTPS/SPDY服务器》。
环境配置为Linux + Apache2.2 + mod_spdy。其中mod_spdy是Chromium为Apache开发的插件,只支持Apache2.2,直接安装插件包即可。SPDY协议支持版本为3。
4.1.2 Nginx具体的搭建方法请参考《Linux Mint + Nginx 1.5.11搭建SSL/HTTPS/SPDY服务器》。
环境配置为Linux + Nginx1.5.11,需要编译源码来启用SPDY,普通发布包并不支持。SPDY协议支持版本为3.1,还不支持Server Push。
4.1.3 份额根据新闻网页http://www.csdn.net/article/2013-07-04/2816099-nginx-just-became-the-most-used-web-server表示,在全球排名前1000的高流量网站所使用的Web服务器中,Nginx占34.9%,Apache占34.5%。两者分别排名第一和第二,第三的Microsoft-IIS并不支持SPDY。
4.2 Wireshark截包Chromium为Wireshark1.7.1做了源码patch,名为spdyshark,需要下载Wireshark源码和spdyshark源码共同编译才能令Wireshark支持SPDY协议。具体的编译安装方法请参考《Linux Mint下编译安装支持SPDY协议的Wireshark》。
因为SPDY基于TLS,所以Wireshark截包需要先解密SSL,再解析SPDY协议。具体的截包方法请参考《Wireshark+Apache2.4解密SSLv3》和《使用支持SPDY协议的Wireshark截包(含spdyshark插件)》。
4.3 Server端应用现状4.3.1 调查方法调查Web服务器是否支持SPDY,可使用第三方网站的方法:访问http://spdycheck.org/,在网页中输入网址即可反馈结果

但是国内网站并非全站都用HTTPS scheme,所以需要人工找到登录账号的页面来做测试。
还可使用Wireshark截包,在TLS的Server Hello信息中找Extension,ALPN会显示Unknown 16,NPN能识别出是Extension: next_protocol_negotiation。
可知目前Google网站用3.1:

Facebook用2和3:

4.3.2 调查结果
国内外的常见网站看了看,只发现四家:Google、Facebook、wordpress.com和www.cloudflare.com。国内还没有网站支持。(注,此调查结果很粗浅,不可当权威结论)
4.4 Browser端应用现状
4.4.1 测试方法用目标浏览器访问https://isspdyenabled.com/即会在页面上显示是否支持SPDY。
4.4.2 数据根据第三方数据,支持SPDY的浏览器有:

1. Internet Explorer 11 部分支持
2. Firefox 13+
3. Chrome 4+
4. Opera 12.1+
5. Android系统浏览器3.0+(应该是错的,测试的结果是4.1+才对)
6. Opera Mobile 12.1+
7. Chrome for Android 33+
8. Firefox for Android 26+

支持SPDY的浏览器占65.26%。具体请参看http://caniuse.com/spdy。
搜索到CNZZ统计了中国的浏览器份额,但无法直观地看出支持SPDY的占比,个人估算是桌面版低于50%,移动版低于30%。http://brow.data.cnzz.com/main.php?s=brow&uv=1&type=2&date=2014%E5%B9%B402%E6%9C%88。
5 浏览器实现方案
SPDY对浏览器的实现来说,工作在加载框架的网络层。假如已实现SPDY,下图描述网络层内部再分层细化以及各细化层的职责:

无论是HTTP还是SPDY,在一次加载流程中都需要各细化层承担所有的职责。在代码实现来看,若HTTP和SPDY有不同,则需要对各职责设计基类,HTTP和SPDY各自继承基类以实现不同的过程。
SPDY特殊实现的职责有:

1. Callback回调机制。SPDY的HTTP header是压缩的,要与普通HTTP流程对接的话,要么先行解压,要么由callback解压。
2. Protocol Transport协议传输过程控制。特别是Server Push特性。
3. error错误处理
4. SPDY全双工。SPDY的socket是全双工应用,同时发送和接收,和一般的HTTP先发送后接收不同。
5. Framing装帧。这层大部分都和HTTP不同。
6. SSL/TLS handshake握手过程。因为SPDY有NPN。
7. SpdyConnection。Connection一般由URL的scheme、host、port来区分,SPDY和HTTPS的这些区分点全都相同,故connection的复用需增加protocol来区分。

除了Chromium自己外,其SPDY文档还列出了几种实现。C/C++的其它实现,都有个共同点:因为工作在底层,依赖比较多的外部库代码。而且他们最近三个月都还有更新,多数并未支持所有的SPDY特性,并且在修复bug。所以代码的完善程度还不能达到浏览器级别的标准。

6 网站是否该支持SPDY
暂无必要支持SPDY、HTTP/2和QUIC。
原因:

1. SPDY是公司标准,还不是行业标准,存在缺陷,待完善。
2. SPDY成熟的时候就会被接纳并完善成为行业标准甚至国际标准,那时候再支持也不迟。HTTP/2草案就是基于SPDY的,且HTTP/2优于SPDY,SPDY迟早会退出历史舞台,届时业界会大量支持HTTP/2。
3. Server端本身对SPDY的支持不完善,未完全实现所有特性,且存在bug。网站贸然使用的话存在一定风险。Apache2.2 + mod_spdy只支持SPDY3,Nginx1.5.1只支持SPDY3.1,未实现Server Push。等到Server端程序较完善的时候再做也不迟。收费的Server端程序没有一个开始支持SPDY,等到他们开始支持的时候,可认为是一个标志,代表业界会开始做很多配套的东西来支持新标准。
4. Server端并未普及,已应用的网站寥寥无几。
5. 支持SPDY的浏览器在中国的份额低于50%,网站还没迫切必要支持SPDY。Safari完全不支持,即SPDY还未获Apple认可。

  • 大小: 274.1 KB
  • 大小: 66.2 KB
  • 大小: 14.7 KB
  • 大小: 48.2 KB
  • 大小: 51.7 KB
  • 大小: 70.8 KB
分享到:
评论

相关推荐

    quic协议设计文档

    QUIC整合了TCP的可靠传输特性以及UDP的低延迟优势,并且支持多路复用,使得它可以避免HTTP/2在TCP上可能遇到的队首阻塞问题。QUIC协议的设计目的是为了优化Web应用,特别是对延迟敏感的应用,如网页浏览和实时通信。...

    QUIC协议传输格式的详细设计文档

    而在传输层,Google也在2013年提出并实行了QUIC(读音同quick)协议。将近两年,QUIC进展如何了呢? 昨天Google官方博客透露,QUIC已经支撑了Chrome与Google服务器之间近50%流量,而且在搜索和YouTube等服务上体验...

    HTTP/2 and SPDY indicator-crx插件

    每个网站的HTTP / 2,SPDY和QUIC支持的指示器按钮。 HTTP / 2(基于Google的SPDY)使浏览器和服务器之间的信息交换性能大大提高。 升级其基础架构以支持它们的网站和应用程序具有明显的优势。 此扩展名在地址栏中...

    HTTP2 讲解

    QUIC协议结合了HTTP/2的优点,同时尝试解决TCP的一些限制,如拥塞控制等。此外,QUIC还提供了一个加密层,使安全性成为其核心特性之一。 #### 扩展阅读与致谢 原文档作者Daniel Stenberg是一位经验丰富的网络...

    QCon2017上海

    标题《QCon2017上海》与描述中提到的《从HTTP2到QUIC-黄佳琳》涉及的是2017年在中国上海举行的QCon国际软件开发大会,其中黄佳琳进行了一场关于HTTP/2到QUIC协议的演讲。标签“QCon”指的是国际知名的软件开发者大会...

    快速UDP互联网连接协议QUIC.zip

    QUIC (Quick UDP Internet Connections)是 chromium 的一个项目,这是一个体验的协议,旨在降低基于 TCP 通讯的 Web 延迟。QUIC 非常类似 TCP TLS SPDY ,但是基于 UDP 实现的。因为 TCP 是由操作系统内核或者是 ...

    http2讲解.pdf

    书中提到,随着技术进步和新的协议(如QUIC)的出现,HTTP/2也可能会有新的扩展和修改,以便进一步提高网络通信的性能和安全性。 ### 总结 通过《http2讲解》这本书,我们可以系统地了解HTTP/2的产生背景、核心...

    阿里巴巴HTTP 2.0实践及无线通信协议的演进之路 陈虓将.pdf

    而QUIC协议作为基于UDP的传输层网络协议,对TCP进行了改进,旨在减少连接延迟,提高移动通信效率,这与HTTP/2的优化目标是相符的。 头部压缩技术HPACK在HTTP/2中扮演着核心角色,它能有效减少传输过程中头部数据的...

    gospdyquic:SPDYQUIC对Go的支持

    【标题】:“gospdyquic:Go语言对SPDY/QUIC协议的支持” 【正文】: 在现代网络环境中,速度和效率是关键因素,这促使了SPDY和QUIC协议的诞生。gospdyquic是一个针对Go编程语言的开源库,它实现了对这两种高效网络...

    Learning.HTTP2.pdf

    《Learning.HTTP2》这本书详细讲解了这些特性,并涵盖了实施HTTP2的最佳实践、性能优化策略以及与其他技术(如SPDY、QUIC)的关系。书中还可能包含实际案例分析,帮助读者理解如何在实际项目中应用HTTP2,提高网站和...

    QUIC-Quick UDP Internet Connections RFC

    QUIC(Quick UDP Internet Connections,发音'quick')是一种基于UDP的多路传输协议,它的主要目标是实现零往返时间的连接开销。Google的开发人员Robbie Shade在最近的一个视频中对QUIC做了介绍,主要有以下特性: ...

    goquic:QUIC对Go的支持

    QUIC是一种实验性协议,旨在通过TCP减少Web延迟。 从表面上看,QUIC与在UDP上实现的TCP + TLS + SPDY非常相似。 由于TCP是在操作系统内核和中间盒固件中实现的,因此对TCP进行重大更改几乎是不可能的。 但是,由于...

    RFC2616中文版

    - **HTTP/3**:基于QUIC协议,解决了HTTP/2的一些问题,如队头阻塞等。 #### 三、HTTP/1.1的主要特点 - **持久连接**(Persistent Connections):允许客户端和服务器之间的多个请求共享一个TCP连接,减少了建立...

    WebKit和Chromium源码及原理剖析.pdf

    #### 第16篇 SPDY、HTTP/2、QUIC协议 - **协议概述**: - SPDY是由Google开发的一种网络传输协议,旨在提高Web应用的加载速度。 - HTTP/2是HTTP协议的下一代版本,引入了多项改进,如多路复用、头部压缩等。 - ...

    HTTP2.0协议

    例如,HTTP/3正在开发中,它将基于QUIC协议,提供更低的延迟和更好的安全性。 #### 结论 HTTP2.0协议代表了HTTP协议的重大进步,通过引入一系列创新性的特性,极大地改善了网络性能和用户体验。随着其在全球范围内...

    蚂蚁通信框架实践1

    首先,文章提到在互联网领域,通信技术多样,包括基于TCP/IP协议簇的HTTP、SPDY、WebSocket以及QUIC等标准协议。这些协议具有完善的安全、序列化、压缩和校验机制,适用于公网环境的高效稳定通信。但在私有网络如...

    WatchTower-在您的浏览器中观察OKHttpAPI调用请求和响应详细信息

    它提供了异步和同步的 API,支持 HTTP/1.1 和 HTTP/2 协议,以及 SPDY/QUIC 作为备选协议。OKHttp 的核心特性包括连接池、缓存机制、重试和重定向策略,以及对 gzip 压缩的支持,这些都使得它在处理网络请求时具有...

    电商消息系统架构演进&mdash1

    - **HTTP/HTTP2/SPDY/QUIC/WebSocket**:不同的网络协议,用于优化HTTP请求,提升性能和响应速度。 - **H5-IM-JSSDK**:JavaScript SDK,使得Web应用也能实现即时通讯功能。 5. **负载均衡与服务发现** - **LVS...

    阿里巴巴移动中台技术与应用25页.pdf

    最后,文档提到了网络安全方面的一些技术措施,例如SPDY/HTTP2.0和QUIC协议,这些新技术使得数据传输更加安全、高效。同时,还提及了SSL0RTT和TLS1.3协议的使用,这些协议在建立安全连接时能够减少延迟,提供快速的...

    阿里巴巴移动中台技术与应用.pdf

    接着,阿里巴巴引入了ACCS(Ali-Cloud-Channel-Service)来优化网络协议,比如采用HTTP 1.1、SPDY/HTTP 2.0、QUIC等协议,实现真正的并发请求,利用gzip/HPACK压缩头部,以及异步多路复用和头部压缩等技术,进一步...

Global site tag (gtag.js) - Google Analytics