SPDY、HTTP/2、QUIC协议

标签: spdyHTTP2QUIC协议Chromium
50966人阅读 评论(7) 收藏 举报
分类:

1 SPDY协议

1.1 概述

SPDY为speedy(单词原意:快速的)的缩写,读音也就是speedy。

SPDY协议已发布过4个草案,分别为版本1、2、33.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 NPN

NPN简单来说就是在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_STREAMSYN_REPLYRST_STREAMHEADERS)的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了。

2.3 TCP上的应用

HTTP/2可使用http或https scheme作为URL。

当使用http scheme时,client先用HTTP/1.1的request发给server,但要加入header Upgrade和HTTP2-Settings。格式为:

GET /default.htm HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>

如果server支持HTTP/2,则以状态码101回复,形式如下:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2

[ HTTP/2 connection ...

然后双方开始以HTTP/2作为传输协议。否则以HTTP/1.1回复response,即HTTP/1.1 200 OK。

3 QUIC

QUIC是Quick UDP Internet Connections的缩写,读作quick。由Google开发,概要设计文档放在google docs https://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的实现代码也在完善中,这还是个试验性的半成品,没有性能比较的数据。只浅浅研究即止,不深入了。

转载请注明出处:http://blog.csdn.net/hursing

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.comwww.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认可。
转载请注明出处:http://blog.csdn.net/hursing
9
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1013712次
    • 积分:9432
    • 等级:
    • 排名:第2013名
    • 原创:173篇
    • 转载:0篇
    • 译文:0篇
    • 评论:539条
    联系方式
    博客专栏
    最新评论