SPDY > SPDY Protocol >
Mike Belshe (mbelshe at google.com) & Roberto Peon (fenix at google.com)
DRAFT
Overview
One of the bottlenecks of current HTTP is that it relies solely on multiple connections for concurrency. This causes several problems, including additional round trips for connection setup, slow-start delays, and a constant rationing by the client where it tries to avoid opening too many connections to a single server. HTTP "pipelining" doesn't help, as each connection may be blocked on the request at the head of the line; in addition, many proxies apparently have poor support for pipelining. Applications, in their desire to create many connections, create many sub-domains to work around browser per-domain connection throttling.
SPDY aims to address this and other application-layer problems associated with modern web applications, while requiring little or no change from the perspective of web application writers.
In a nutshell, SPDY adds a framing layer for multiplexing multiple, concurrent streams across a single TCP connection. The framing layer is optimized for HTTP-like request-response streams.
The SPDY session offers three basic improvements over HTTP:
- Multiplexed requests. There is no limit to the number of requests that can be issued concurrently over a single SPDY connection. Because requests are interleaved on a single channel, the efficiency of TCP is much higher.
- Prioritized requests. Clients can request certain resources to be delivered first. This avoids the problem of congesting the network channel with non-critical resources when a high-priority request is pending.
- Compressed headers. Clients today send a significant amount of redundant data in the form of HTTP headers. Because a single web page may require 50 or 100 subrequests, this data is significant. Compressing the headers saves a significant amount of latency and bandwidth compared to HTTP.
Note that for the most part, SPDY attempts to preserve the existing semantics of HTTP features. All features such as cookies, etags, vary headers, content-encoding negotiations, etc work exactly as they do with HTTP; SPDY only replaces the way the data is written to the network.
Definitions
- connection: A TCP-level connection between two endpoints.
- endpoint: Either the client or server of a connection.
- session: A framed sequence of data chunks. Frames are defined as SPDY frames; see Framing below.
- stream: A bi-directional flow of bytes across a virtual channel within a SPDY session.
Main differences from HTTP
SPDY is intended to be as compatible as possible with current web-based applications. This means that, from the perspective of the server business logic or application API, nothing has changed. To achieve this, all of the application request and response header semantics are preserved. SPDY introduces a "session" which resides between the HTTP application layer and the TCP transport to regulate the flow of data. This "session" is akin to an HTTP request-response pair. The following changes represent the differences between SPDY and HTTP:
The request
To initiate a new request, clients first create a new SPDY session. Once the session is created, the client can create a new SPDY stream to carry the request. Part of creating the stream is sending the HTTP header block. The HTTP header block in SPDY is almost unchanged from today's HTTP header block, with the following differences:
- The first line of the request is unfolded into name/value pairs like other HTTP headers. The names of the first line fields are
method, url, and version. These keys are required to be present. The 'url' is the fully-qualified URL, containing protocol, host, port, and path.
- Duplicate header names are not allowed.
- Header names are all lowercase.
- The
Connection and Keep-Alive headers are no longer valid and are ignored if present.
- Clients are assumed to support
Accept-Encoding: gzip. Clients that do not specify any body encodings receive gzip-encoded data from the server.
- HTTP request headers are compressed. This is accomplished by compressing all data sent by the client with gzip encoding.
- The "host" header is ignored. The host:port portion of the HTTP URL is the definitive host.
- User-agents are expected to support gzip and deflate compression. Regardless of the Accept-Encoding sent by the user-agent, the server may select gzip or deflate encoding at any time.
- POST-specific changes:
- POST requests are expected to contain a data stream as part of the post; see Data flow below.
Content-length is only advisory for length (so that progress meters can work).- Chunked encoding is no longer valid.
- The POST data stream is terminated by a zero-length data frame.
The response
When responding to a HTTP request, servers will send data frames using the SPDY stream created by the client. The response is similar to HTTP/1.1 in that it consists of a header block followed by a body. However, there are a few notable changes:
- The response status line is unfolded into name/value pairs like other HTTP headers. The names of the status line are
status and version. These keys are required to be present
- If the SPDY reply happens before a SYN_STREAM, then it includes parameters that inform the client regarding the request that would have been made to receive this response, by including
url and method keys.
- All header names must be lowercase.
- The
Connection and Keep-alive response headers are no longer valid.
Content-length is only advisory for length.- Chunked encoding is no longer valid.
- Duplicate header names are not allowed.
Connections
The first implementation of the SPDY session runs atop TCP, similarly to how HTTP works today. The client is expected to be the TCP connection initiator. Because it runs on TCP, we have a reliable transport. Unlike HTTP, all connections with SPDY are persistent connections. The HTTP connection header does not apply.
For best performance, it is expected that clients will not close open connections until the user navigates away from all web pages referencing a connection, or until the server closes the connection. Servers are encouraged to leave connections open for as long as possible, but can terminate idle connections after some amount of inactivity if necessary.
Framing
Once the TCP connection is established, clients and servers exchange framed messages. There are two types of frames: control frames and data frames. Frames always have a common header which is 8 bytes.
The first bit is a control bit indicating whether a frame is a control frame or data frame. Control frames carry a version number, a frame type, flags, and a length. Data frames contain the stream ID, flags, and the length for the payload carried after the common header. The simple header is designed to make reading and writing of frames easy. All integer values, included length, version, and type, are in network byte order. SPDY does not enforce alignment of types in dynamically sized frames. Control frames
+----------------------------------+
|C| Version(15bits) | Type(16bits) |
+----------------------------------+
| Flags (8) | Length (24 bits) |
+----------------------------------+
| Data |
+----------------------------------+
Control frame fields:
Control bit: The 'C' bit is a single bit indicating that this is a control message. For control frames this value is always 1.
Version: The version number of the session protocol (currently 1).
Type: The type of control frame. Control frames are SYN_STREAM, SYN_REPLY, etc.
Flags: Flags related to this frame. Flags for control frames and data frames are different.
Length: An unsigned 24-bit value representing the number of bytes after the length field.
Data: data associated with this control frame. The format and length of this data is controlled by the control frame type.
Data frames
+----------------------------------+
|C| Stream-ID (31bits) |
+----------------------------------+
| Flags (8) | Length (24 bits) |
+----------------------------------+
| Data |
+----------------------------------+
Data frame fields:
Control bit: For data frames this value is always 0.
Stream-ID: A 31-bit value identifying the stream.
Flags: Flags related to this frame. Valid flags are:
- 0x01 = FLAG_FIN - signifies that this frame represents the half-close of this stream. See Stream half-close below.
Length: An unsigned 24-bit value representing the number of bytes after the length field. The total size of a data frame is 8 bytes + length. It is valid to have a zero-length data frame.
Data: A variable-length field containing the number of bytes in the payload.
Hello message
After the connection has been established, SPDY employs an asynchronous Hello sequence where each side informs the other about the communication details it knows about. Unlike most protocols, this Hello sequence is optional and fully asynchronous. Because it is asynchronous, it does not add a round-trip latency to the connection startup. But because it is asynchronous and optional, both sides must be prepared for this message to arrive at any time or not at all.
To initiate a Hello sequence, either side can send a HELLO control frame. The Hello frame is optional, but if it is to be sent, it must be the first frame sent. When a Hello message is received, the receiver is not obligated to reply with a Hello message in return. The message is therefore completely informational.
HELLO control message:
+----------------------------------+
+----------------------------------+
| Flags (8) | Length (24 bits) |
+----------------------------------+
| Unused |Number of entries |
+----------------------------------|
| ID/Value Pairs |
| ... |
HELLO message fields:
Control bit: The control bit is always 1 for this message.
Version: The SPDY version number.
Type: The message type for a HELLO message is 4.
Unused: 16 bits of unused space, reserved for future use.
Number of entries: A 16-bit value representing the number of ID/value pairs in this message.
ID: A 32-bit ID number. The following IDs are valid:
-
1 - HELLO_BANDWIDTH_TO_YOU allows the sender to send its expected upload bandwidth on this channel. This
number is an estimate. The value should be the integral number of kilobytes per second that the sender predicts
as an expected maximum upload channel capacity.
-
2 - HELLO_BANDWIDTH_FROM_YOU allows the sender to send its expected download bandwidth on this channel. This
number is an estimate. The value should be the integral number of kilobytes per second that the sender predicts as
an expected maximum download channel capacity.
- 3 - HELLO_ROUND_TRIP_TIME allows the sender to send its expected round-trip-time on this channel. The round trip time is defined as the minimum amount of time to send a control frame from this client to the remote and receive a response. The value is represented in milliseconds.
-
4 - HELLO_MAX_CONCURRENT_STREAMS allows the sender to inform the remote endpoint the maximum number of concurrent
streams which it will allow. By default there is no limit. For implementors it is recommended that this value be
no smaller than 100.
Value: A 32-bit value.
The message is intentionally expandable for future information which may improve client-server communications. The sender does not need to send every type of ID/value. It must only send those for which it has accurate values to convey. When multiple ID/value pairs are sent, they should be sent in order of lowest id to highest id.
Streams
Streams are independent sequences of bi-directional data cut into frames. Streams can be created either by the client or the server, can concurrently send data interleaved with other streams, and can be cancelled. The usage of streams with HTTP is such that a single HTTP request/response occupies a single stream, and the stream is not reused for a second request. This is because streams can be independently created without incurring a round-trip.
Upon stream initiation, streams allow for each side to transmit a fixed-length list of name/value pairs to the other endpoint.
Stream creation
A stream is created by sending a control packet with the type set to SYN_STREAM(1). If the server is initiating the stream, the Stream-ID must be even. If the client is initiating the stream, the Stream-ID must be odd. 0 is not a valid Stream-ID. Stream-IDs from each side of the connection must increase monotonically as new streams are created. E.g. Stream 2 may be created after stream 3, but stream 7 must not be created after stream 9.
Upon receipt of a SYN_STREAM frame, the server replies with a SYN_REPLY frame. The client does not need to wait for a SYN_REPLY before sending any data frames.
If the endpoint receiving a SYN_STREAM does not want to accept the new stream, it can immediately respond with a FIN_STREAM control frame. Note, however, that the initiating endpoint may have already sent data on the stream as well; this data must be ignored.
SYN_STREAM control message:
+----------------------------------+
+----------------------------------+
| Flags (8) | Length (24 bits) |
+----------------------------------+
|X| Stream-ID (31bits) |
+----------------------------------+
| Pri | Unused | NV Entries |
+----------------------------------|
| Name/value header block |
| ... |
SYN_STREAM message fields:
Flags: Flags related to this frame. Valid flags are:
- 0x01 = FLAG_FIN - signifies that this frame represents the half-close of this stream. When set, it indicates that the sender will not produce any more data frames in this stream.
Length: An unsigned 24 bit value representing the number of bytes after the length field. The total size of a SYN_STREAM frame is 8 bytes + length. The length for this frame must be greater than or equal to 8.
Priority: A 2-bit priority field. If an endpoint has initiated multiple streams, the priority field represents which streams should be given first precidence. Servers are not required to strictly enforce the priority field, although best-effort is assumed. 0 represents the lowest priority and 3 represents the highest priority. The highest-priority data is that which is most desired by the client.
Unused: 14 bits of unused space, reserved for future use.
NV entries: (16 bits) The number of name/value pairs that follow.
The Name/value block is described below.
SYN_REPLY control message:
+----------------------------------+
+----------------------------------+
| Flags (8) | Length (24 bits) |
+----------------------------------+
|X| Stream-ID (31bits) |
+----------------------------------+
| Unused | NV entries |
+----------------------------------|
| Name/value header block |
| ... |
SYN_REPLY message fields:
Flags: Flags related to this frame. Valid flags are:
0x01 = FLAG_FIN - signifies that this frame represents the half-close of this stream. When set, it indicates that the sender will not produce any more data frames in this stream..
Length: An unsigned 24-bit value representing the number of bytes after the length field. The total size of a SYN_STREAM frame is 8 bytes + length. The length for this frame must be greater than or equal to 8.
Unused: 16 bits of unused space, reserved for future use.
NV entries: (16 bits) The number of name/value pairs that follow.
The Name/value block is described below.
Name/value header block format
Both the SYN_STREAM and SYN_REPLY frames contain a Name/value header block. The header block used by both the request and the response is the same. It is designed so that headers can be easily appended to the end of a list and also so that it can be easily parsed by receivers. Each numeric value is 2 bytes.
+-------------------------------
gipoco.com
is neither affiliated with the authors of this page or responsible
for its contents. This is a safe-cache copy of the original web site.
gipoco.com
is neither affiliated with the authors of this page nor responsible
for its contents. This is a safe-cache copy of the original web site.
| |
|
