- 浏览: 11435510 次
文章分类
最新评论
-
wahahachuang8:
我觉得这种东西自己开发太麻烦了,就别自己捣鼓了,找个第三方,方 ...
WebSocket和node.js -
xhpscdx:
写的这么详细,全面,对架构师的工作职责,个人能力都进行了梳理。 ...
架构师之路---王泽宾谈架构师的职责 -
xgbzsc:
是http://www.haoservice.com 吗?
android WIFI定位 -
lehehe:
http://www.haoservice.com/docs/ ...
android WIFI定位 -
lehehe:
http://www.haoservice.com/docs/ ...
android WIFI定位
SPDY: An experimental protocol for a faster web
转载地址:http://dev.chromium.org/spdy/spdy-whitepaper
Executive summary
Background: web protocols and web latency
- Single request per connection. Because HTTP can only fetch one resource at a time (HTTP pipelining helps, but still enforces only a FIFO queue), a server delay of 500 ms prevents reuse of the TCP channel for additional requests. Browsers work around this problem by using multiple connections. Since 2008, most browsers have finally moved from 2 connections per domain to 6.
- Exclusively client-initiated requests. In HTTP, only the client can initiate a request. Even if the server knows the client needs a resource, it has no mechanism to inform the client and must instead wait to receive a request for the resource from the client.
- Uncompressed request and response headers. Request headers today vary in size from ~200 bytes to over 2KB. As applications use more cookies and user agents expand features, typical header sizes of 700-800 bytes is common.For modems or ADSL connections, in which the uplink bandwidth is fairly low, this latency can be significant.Reducing the data in headers could directly improve the serialization latency to send requests.
- Redundant headers. In addition, several headers are repeatedly sent across requests on the same channel. However, headers such as the User-Agent, Host, and Accept* are generally static and do not need to be resent.
- Optional data compression. HTTP uses optional compression encodings for data. Content should always be sent in a compressed format.
Previous approaches
- Stream Control Transmission Protocol(SCTP) -- a transport-layer protocol to replace TCP, which provides multiplexed streams and stream-aware congestion control.
- HTTP over SCTP-- a proposal for running HTTP over SCTP.Comparison of HTTP Over SCTP and TCP in High Delay Networksdescribes a research study comparing the performance over both transport protocols.
- Structured Stream Transport(SST) --a protocol which invents "structured streams": lightweight, independent streams to be carried over a common transport.It replaces TCP or runs on top of UDP.
- MUXandSMUX-- intermediate-layer protocols (in between the transport and application layers) that provide multiplexing of streams. They were proposed years ago at the same time as HTTP/1.1.
Goals for SPDY
- To target a 50% reduction in page load time. Our preliminary results have come close to this target (see below).
- To minimize deployment complexity. SPDY uses TCP as the underlying transport layer, so requires no changes to existing networking infrastructure.
- To avoid the need for any changes to content by website authors. The only changes required to support SPDY are in the client user agent and web server applications.
- To bring together like-minded parties interested in exploring protocols as a way of solving the latency problem. We hope to develop this new protocol in partnership with the open-source community and industry specialists.
-
To allow many concurrent HTTP requests to run across a single TCP session.
-
To reduce the bandwidth currently used by HTTP by compressing headers and eliminating unnecessary headers.
-
To define a protocol that is easy to implement and server-efficient. We hope to reduce the complexity of HTTP by cutting down on edge cases and defining easily parsed message formats.
- To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.
- To enable the server to initiate communications with the client and push data to the client whenever possible.
SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved streams over a single TCP connection.
The usual HTTP GET and POST message formats remain the same; however, SPDY specifies a new framing format for encoding and transmitting the data over the wire.
SPDY aims to achieve lower latency through basic (always enabled) and advanced (optionally enabled) features.
Basic features
- Multiplexed streams
SPDY allows for unlimited concurrent streams over a single TCP connection. Because requests are interleaved on a single channel, the efficiency of TCP is much higher: fewer network connections need to be made, and fewer, but more densely packed, packets are issued.
-
Request prioritization
Although unlimited parallel streams solve the serialization problem, they introduce another one: if bandwidth on the channel is constrained,the client may block requests for fear of clogging the channel. To overcome this problem, SPDY implements request priorities: the client can request as many items as it wants from the server, and assign a priority to each request. This prevents the network channel from beingcongested with non-critical resources when a high priority request is pending.
- HTTP header compression
SPDY compresses request and response HTTP headers, resulting in fewer packets and fewer bytes transmitted.
Advanced features
In addition, SPDY provides an advanced feature,server-initiated streams. Server-initiated streams can be used to deliver content to the client without the client needing to ask for it. This option is configurable by the web developer in two ways:
- Server push.
SPDY experiments with an option for servers to push data to clients via the X-Associated-Content header. This header informs the client that the server is pushing a resource to the client before the client has asked for it. For initial-page downloads (e.g. the first time a user visits a site), this can vastly enhance the user experience.
- Server hint.
Rather than automatically pushing resources to the client, the server uses theX-Subresources header tosuggestto the client that it should ask for specific resources, in cases where the server knows in advance of the client that those resources will be needed. However, the server will still wait for the client request before sending the content.Over slow links, this option can reduce the time it takes for a client to discover it needs a resource by hundreds of milliseconds, and may be better for non-initial page loads.
SPDY implementation: what we've built
-
A high-speed, in-memory server which can serve both HTTP and SPDY responses efficiently, over TCP and SSL. We will be releasing this code as open source in the near future.
-
A modified Google Chrome client which can use HTTP or SPDY, over TCP and SSL. The source code is athttp://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/. (Note that code currently uses the internal code name of "flip"; this will change in the near future.)
-
A testing and benchmarking infrastructure that verifies pages are replicated with high fidelity. In particular, we ensure that SPDY preserves origin server headers, content encodings, URLs, etc. We will be releasing our testing tools, and instructions for reproducing our results, in the near future.
Preliminary results
We downloaded 25 of the "top 100" websites over simulated home network connections, with 1% packet loss. We ran the downloads 10 times for each site, and calculated the average page load time for each site, and across all sites. The results show a speedup over HTTP of 27% - 60% in page load time over plain TCP (without SSL), and 39% - 55% over SSL.
DSL 2 Mbps downlink, 375 kbps uplink | Cable 4 Mbps downlink, 1 Mbps uplink | |||
Average ms | Speedup | Average ms | Speedup | |
HTTP | 3111.916 | 2348.188 | ||
SPDY basic multi-domain* connection / TCP | 2242.756 | 27.93% | 1325.46 | 43.55% |
SPDY basic single-domain* connection / TCP | 1695.72 | 45.51% | 933.836 | 60.23% |
SPDY single-domain + server push / TCP | 1671.28 | 46.29% | 950.764 | 59.51% |
SPDY single-domain + server hint / TCP | 1608.928 | 48.30% | 856.356 | 63.53% |
SPDY basic single-domain / SSL | 1899.744 | 38.95% | 1099.444 | 53.18 |
SPDY single-domain + client prefetch / SSL | 1781.864 | 42.74% | 1047.308 | 55.40% |
* In many cases, SPDY can stream all requests over a single connection, regardless of the number of different domains from which requested resources originate. This allows for full parallelization of all downloads. However, in some cases, it is not possible to collapse all domains into a single domain. In this case, SPDY must still open a connection for each domain, incurring some initial RTT overhead for each new connection setup. We ran the tests in both modes: collapsing all domains into a single domain (i.e. one TCP connection); and respecting the actual partitioning of the resources according to the original multiple domains (= one TCP connection per domain). We include the results for both the strict "single-domain" and "multi-domain" tests; we expect real-world results to lie somewhere in the middle.
The role of header compression
The role of packet loss and round-trip time (RTT)
- SPDY sends ~40% fewer packets than HTTP, which means fewer packets affected by loss.
- SPDY uses fewer TCP connections, which means fewer chances to lose the SYN packet. In many TCP implementations, this delay is disproportionately expensive (up to 3 s).
- SPDY's more efficient use of TCP usually triggers TCP's fast retransmit instead of using retransmit timers.
Table 2: Average page load times for top 25 websites by packet loss rate
Average ms | Speedup | ||
Packet loss rate | HTTP | SPDY basic (TCP) | |
0% | 1152 | 1016 | 11.81% |
0.5% | 1638 | 1105 | 32.54% |
1% | 2060 | 1200 | 41.75% |
1.5% | 2372 | 1394 | 41.23% |
2% | 2904 | 1537 | 47.7% |
2.5% | 3028 | 1707 | 43.63% |
Average ms |
Speedup | ||
RTT in ms |
HTTP |
SPDY basic (TCP) |
|
20 | 1240 | 1087 | 12.34% |
40 | 1571 | 1279 | 18.59% |
60 | 1909 | 1526 | 20.06% |
80 | 2268 | 1727 | 23.85% |
120 | 2927 | 2240 | 23.47% |
160 | 3650 | 2772 | 24.05% |
200 | 4498 | 3293 | 26.79% |
SPDY next steps: how you can help
- Bandwidth efficiency is still low. Although dialup bandwidth efficiency rate is close to 90%, for high-speed connections efficiency is only about ~32%.
- SSL poses other latency and deployment challenges. Among these are: the additional RTTs for the SSL handshake; encryption; difficulty of caching for some proxies. We need to do more SSL tuning.
- Our packet loss results are not conclusive. Although much research on packet-loss has been done, we don't have enough data to build a realistic model model for packet loss on the Web. We need to gather this data
to be able to provide more accurate packet loss simulations.
- SPDY single connection loss recovery sometimes underperforms multiple connections. That is, opening multiple connections is still faster than losing a single connection when the RTT is very high. We need to figure out when it is appropriate for the SPDY client to make a new connection or close an old connection and what effect this may have on servers.
- The server can implement more intelligence than we have built in so far. We need more research in the areas of server-initiated streams, obtaining client network information for prefetching suggestions, and so on.
To help with these challenges, we encourage you to get involved:
- Send feedback, comments, suggestions, ideas to thechromium-discuss discussion group.
- Download, build, run, and test theGoogle
Chrome client code.
- Contribute improvements to the code base.
相关推荐
spedye: A reverse proxy for the HTTPS and SPDY protocols
用法例子服务器: var spdy = require ( 'spdy' ) , fs = require ( 'fs' ) ;var options = { // Private key key : fs . readFileSync ( __dirname + '/keys/spdy-key.pem' ) , // Fullchain file or cert file &#...
这是曾经在 golang.org/x/net/spdy 上可用... 当 Chromium 浏览器放弃 spdy 支持时,我们也会从 nghttp2 中放弃 spdy 支持,并删除此存储库。 由于我们无意维护此存储库,因此会默默忽略针对此存储库的任何 PR 和问题。
在标准SPDY传输上使用时,jschan与当前的Go参考实现兼容。 我们还有一个websocket传输机制,允许我们在浏览器上运行jschan。 规范未涵盖此功能,并且与其他实现不兼容。 安装 npm install jschan-spdy --save 例子...
图片说明得分 这是用于图片描述的自动评分系统。
js-libp2p-spdy 与libp2p Stream Muxer预期接口兼容的SPDY 3.1实现包装器首席维护者安装npm > npm i libp2p-spdy在Node.js中使用const spdy = require ( 'libp2p-spdy' ) 在带有browserify,webpack或任何其他捆绑...
SPDY protocol now enabled by default for faster browsing on supported sites CHANGED Restored background tabs are not loaded by default for faster startup CHANGED Smooth scrolling is now enabled by ...
SPDY for iPhone ,SPDY for iPhone 是一个为 iPhone 构建的 SPDY 客户端开发包。
KORE 是一个用 C 语言开发的支持 SPDY 的 Web 服务器。支持 Linux 和 BSD 系统。 特性: - Supports SNI - Supports SPDY/3 - Supports HTTP/1.1 - Secure by default - SSL connections only - Virtual host ...
编译方法请参考。http://blog.csdn.net/hursing/article/details/20367381 能找到这来,相信你懂它用来干什么。
SPDY协议文档英文版
第十二章:SPDY.pdf
spdy - 用与内置的https模块相同的API创建SPDY服务器
SPDY 是 Google 开发的基于传输控制协议 (TCP) 的应用层协议 ,开发组正在推动 SPDY 成为正式标准(现为互联网草案)。SPDY 协议旨在通过压缩、多路复用和优先级来缩短网页的加载时间和提高安全性。
NULL 博文链接:https://ssdutliuhaibo.iteye.com/blog/1396845
SPDY并不是一种用于替代HTTP的协议,而是对HTTP协议的增强。新协议的功能包括数据流的多路复用、请求优先级...谷歌已经开发一个网络服务器原型机,以及支持SPDY协议的Chrome浏览器版本。 该文件是apache支持SPDY的扩展
okhttp 是一个 Java 的 HTTP SPDY 客户端开发包,同时也支持 Android。 示例代码: OkHttpClient client = new OkHttpClient(); String get(URL url) throws IOException { HttpURLConnection connection = ...
要使用要通过 SPDY 加载的资源创建测试网页,请运行: node create-test-page.js [numberOfJsFilesToLoad] [numberOfCSSFilesToLoad] 。 这两个参数是可选的。 这将生成一个 index.html 页面,其中包含所需数量...
HTTP1.1基础上的新的应用层协议,由谷歌提出,目的为了加快网页的下载速度,实现了TCP的多路复用
Chrome插件HTTP/2 and SPDY indicator,安装完毕后访问启用HTTP2的站点,如果地址栏出现蓝色的闪电,说明站点已启用HTTP2.0