Transcript SPDY protocol

By Jory Cohen
Made for CISC856, Spring 2010
Thanks to Dr. Amer, Mike Belshe(Google), Jon Leighton


Experimental protocol being researched by
Google and the UD PEL
Application-layer protocol for transporting
content over the web, designed specifically
for minimal latency

HTTP is inefficient
◦ Single request per connection
 Browsers now open 6 connections per domain for concurrency
◦
◦
◦
◦
Only clients can initiate requests
Header size – 200 bytes to over 2 KB
Redundant headers
Optional data compression

Multiplexed requests
◦ No limit to number of requests over SPDY connection




Prioritized requests
Compressed headers and data
Server push and server hint
Only changes way data is written to network
◦ SPDY keeps cookies, encoding negotiations, etc.
same as HTTP



Streams can be bi-directional
SPDY allows for unlimited concurrent streams
over a single TCP connection
Fewer network connections need to be made,
and fewer, but more densely packed, packets
are issued


The client can request as many items as the
client wants from the server, and assign a
priority to each request
SPDY compresses request and response HTTP
headers, resulting in fewer TCP PDUs and
fewer bytes transmitted

Server pushes to the client before something
is requested
◦ Valuable for visiting a webpage, server knows
everything that should be requested
◦ Reduces the client’s processing time before being
able to send out subsequent requests
◦ Server must open multiple streams
Server Push Example
Client
Stream 1
Server
HTTP Get request
Response for HTTP Get
Server push
Stream 1
Stream 2
Server push
Stream 4
Server push
Stream 6
Server push
Stream 8

Server tells client that it will probably ask for
certain resources
◦ Client can request resources due to server hint
much faster than without
◦ Client can also make decision to ignore hint given
by the server
◦ Has similar benefit to server push, reduces
processing time necessary at client before new
requests are sent to the server
Server Hint Example
Client
Stream 1
Stream 3
Server
HTTP Get request
Response for HTTP Get
Stream 1
Server hints to client
Stream 2
Client request based on hint
Stream 5
Client request based on hint
Stream 7
Client request based on hint
Stream 9
Client request based on hint
Server responses
Streams 3,5,7,9





Connections started by the client must be odd
Connections started by the server must be even
Stream number 99 can be initiated before
stream number 2
No steam ID of 0
Stream must be set to be unidirectional in
SYN_STREAM, default would be bi-directional



Client sends SYN_STREAM to open connection
Client can begin sending data or requests for
data without waiting for response
After client is done sending, client sets the
FLAG_FIN flag and connection is half closed
Client
Stream ID = 1
Server
SYN_STREAM
Data or Requests
Stream ID = 3
SYN_STREAM
Data or Requests
SYN_STREAM
Stream ID = 2
Data or Requests
SYN_REPLY
SYN_REPLY Stream 3 & Data Stream 1
Stream ID = 1

Normal termination
◦ Both sides have sent FLAG_FIN

Abrupt termination
◦ One side sends RST_STREAM

TCP connection teardown
◦ Both sides must realize that the connection was
abnormally terminated
Client
Stream 3
Server
Data + FLAG_FIN
Data reply for Stream 3
Data reply for Stream 3
Data reply for Stream 3
Data reply for Stream 3
Data reply for Stream 3 + FLAG_FIN
4244 bytes on wire, 9978 total bytes uncompressed.
42% of bytes without compression.
861 bytes on the wire, 2299 total bytes uncompressed.
37% of bytes without compression.

NOOP
◦ Receiver does nothing, ignores PDU

PING
◦ Used to test RTT, takes priority over data

GOAWAY
◦ Used for graceful termination
◦ Contains a last good stream number

HEADERS
◦ Used to send additional headers that would not fit
in a previous PDU

WINDOW_UPDATE
◦ Used for per stream flow control in SPDY

SETTINGS
◦ Used to communicate ID/value pairs






Upload bandwidth
Download bandwidth
Round trip time
Maximum concurrent streams
Current CWND
Persistence of previous settings
DSL 2 Mbps downlink, 375 kbps uplink Cable 4 Mbps downlink, 1 Mbps uplink
Average ms
speedup
average ms
speedup
HTTP
3111
2348
SPDY basic multi-domain connection / TCP
2242
27%
1325
44%
SPDY basic single-domain connection / TCP
1695
46%
933
60%
SPDY single-domain + server push / TCP
1671
46%
950
60%
SPDY single-domain + server hint / TCP
1608
48%
856
64%
SPDY basic single-domain / SSL
1899
39%
1099
53%
SPDY single-domain + client prefetch / SSL
1781
43%
1047
55%
Download of 25 websites with 1% constant packet loss.
Download was run 10 times for each site and average page load time is
reported. [1]
Packet loss rate
0%
0.50%
1%
1.50%
2%
2.50%
Average ms
Speedup
HTTP
SPDY basic(TCP)
1152
1016 11.81%
1638
1105 32.54%
2060
1200 41.75%
2372
1394 41.23%
2904
1537 47.70%
3028
1707 43.63%
Download of 25 websites with 1% constant packet loss.
Download was run 10 times for each site and average page load time is
reported.[1]
RTT in ms
20
40
60
80
120
160
200
Average ms
Speedup
HTTP
SPDY basic(TCP)
1240
1087
12.34%
1571
1279
18.59%
1909
1526
20.06%
2268
1727
23.85%
2927
2240
23.47%
3650
2772
24.05%
4498
3293
26.79%
Download of 25 websites with 1% constant packet loss.
Download was run 10 times for each site and average page load time is
reported.[1]



SPDY enabled Chrome browser with Flip-inmem server
SPDY “plug-in” for wireshark
Use SCTP with SPDY



SPDY protocol specification
http://www.chromium.org/spdy/spdyprotocol/spdy-protocol-draft2
SPDY white paper
http://www.chromium.org/spdy/spdywhitepaper [1]
SPDY homepage with other resources
http://www.chromium.org/spdy/