SPDY is an application-layer protocol developed by Google based on the Transmission Control Protocol (TCP) (pronounced “speedy”), designed to minimize network latency, improve network speed, and optimize the user’s web experience. SPDY is not a replacement for HTTP, but rather an enhancement to the HTTP protocol. The new protocol’s features include multiplexed data streams, request prioritization, and HTTP header compression. Google reports that in lab tests, page load speeds improved by up to 64% with the introduction of the SPDY protocol.
Currently, mainstream browsers such as Google Chrome, Mozilla Firefox, Opera, and Internet Explorer already support SPDY, and major web servers such as Apache, Nginx, Netty, Jetty, and node.js have all begun preliminary support for SPDY. SPDY is not yet a formal standard, but the SPDY development team has started pushing for SPDY to become an official standard.
This article primarily covers the basic concepts of SPDY and how to compile nginx with SPDY support.
Performance Issues with the HTTP Protocol
One connection per request. Communication between the browser and web server uses short-lived connections, where one connection serves only one request. For a page that needs to load multiple resources, this introduces significant latency.
Requests can only be initiated by the client. The server cannot proactively push essential resources to the client.
HTTP only supports body compression, not header compression. On sites with many cookies, this leads to significant bandwidth waste.
Redundant headers. Some headers are sent repeatedly in requests within the same channel. Headers like User-Agent, Host, and Accept* are often fixed and do not need to be sent repeatedly.
Optional compression. HTTP uses optional compression encoding, but content should always be delivered in compressed format.
SPDY’s Goals
1. SPDY defines and implements an application-layer protocol for the web to significantly reduce latency. SPDY’s high-level goals are:
2. Reduce page load time by 50%. Our results are already approaching this target (see explanation below).
3. Minimize deployment complexity. SPDY uses TCP as the underlying transport layer, so existing network infrastructure does not need to change.
4. Avoid requiring website developers to make any changes to their sites. The only changes needed to support SPDY are in the user agent and the web server.
5. Bring together like-minded developers interested in exploring protocols to address latency issues. We hope to collaborate with the open-source community and industry experts to develop this new protocol.
Some Specific Technical Goals:
1. Support concurrent HTTP requests over a single TCP connection
2. Compress headers and remove unnecessary ones to reduce the bandwidth currently consumed by HTTP
3. Define a protocol that is easy to implement and highly efficient on the server side. We aim to reduce HTTP complexity by minimizing edge cases and defining an easy-to-parse message format
4. Enable the SSL protocol to have better security and compatibility within existing network infrastructure. While SSL does introduce latency, we believe that the long-term development of the web depends on secure network connections. Additionally, using SSL to ensure uninterrupted communication is essential.
SPDY Design and Features
A SPDY session layer is added on top of the SSL layer to enable concurrency and stream mechanisms.
The usual HTTP GET and POST formats remain the same; however, SPDY defines a new frame format for encoding and transmission.
Basic Features
Multiplexed streams. SPDY allows unlimited concurrent streams over a single connection. Because requests flow over a single channel, TCP efficiency is higher: fewer network connections, fewer and denser packets are sent.
Request prioritization. While unlimited parallel streams solve the serialization problem, they introduce other issues.
HTTP header compression.
Advanced Features
In addition, SPDY provides advanced features such as server-initiated streams. Server-initiated streams can be used to deliver content to the client without the client requesting it. This option can be configured by web developers in the following two ways:
Server push. SPDY experiments with server push of data to the client through the X-Associated-Content header. This header tells the client that the server will push resources before the client requests them. For initial page loads (e.g., a user visiting a site for the first time), this can greatly enhance the user experience.
Server hint. Instead of automatically pushing resources to the client, the server uses the X-Subresources header to suggest that the client request specific resources, in cases where the server knows in advance that these resources will be needed by the client. However, the server still waits for the client request before sending content. Over slow links, this option can reduce the time it takes for a client to discover needed resources by hundreds of milliseconds, and may work better for non-initial page loads.
SPDY Implementation
The following has been implemented:
A high-speed, fully in-memory server program capable of serving both HTTP and SPDY. We will open-source this code in the near future.
A Chrome browser capable of using either HTTP or SPDY.
A testing and benchmarking infrastructure to ensure that pages remain unchanged.
Compiling NGINX with SPDY
http://nginx.org/patches/attic/spdy/README.txt
Nginx supports SPDY draft 2
Nginx supports it starting from version 1.3.15
Requires OpenSSL 1.01+
Currently known issues and limitations:
Server push is not supported
SPDY connection rate limiting is not supported
How to compile nginx with SPDY?
1. Install OpenSSL 1.0.1+
2. Download nginx 1.3.x or above
3. Extract nginx
4. Download and apply the SPDY module patch
wget http://nginx.org/patches/spdy/patch.spdy.txt
patch -p1 < patch.spdy.txt
5. Configure
./configure –with-http_ssl_module –with-http_spdy_module
6. Compile
Make
Configuration
server {
listen 443 ssl spdy default_server;
ssl_certificate server.crt;
ssl_certificate_key server.key;
…
}
Next, we will primarily study the content of the SPDY draft specification and read the code.
Original link: http://blog.csdn.net/liujiyong7/article/details/17953979
[Editor’s Recommendations]