SPDY protocolBy Jory Cohen

Made for CISC856, Spring 2010Thanks 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

What is SPDY?

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

Why SPDY?

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

What does SPDY offer?

Which layer is SPDY?

Some SPDY features 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

SPDY benefits

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

Client Server

HTTP Get request

Response for HTTP Get

Server push Server push Server push

Server push

Server Push Example

Stream 1

Stream 1

Stream 8

Stream 6Stream 4Stream 2

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

Client ServerHTTP Get request

Response for HTTP Get

Server hints to client

Client request based on hint

Client request based on hintClient request based on hint

Client request based on hint

Server responses

Server Hint Example

Stream 1

Stream 1Stream 2

Stream 3Stream 5Stream 7

Stream 9

Streams 3,5,7,9

Stream IDs and connections

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

Example 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 ServerSYN_STREAM

Data or RequestsStream ID = 1

SYN_STREAMData or Requests

Stream ID = 3

SYN_STREAM Stream ID = 2Data or Requests

SYN_REPLY

SYN_REPLY Stream 3 & Data Stream 1

Stream ID = 1

Connection termination 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 ServerData + FLAG_FINStream 3

Data reply for Stream 3

Data reply for Stream 3Data reply for Stream 3Data reply for Stream 3

Data reply for Stream 3 + FLAG_FIN

Compression

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.

Interesting SPDY PDUs 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

Interesting SPDY PDUs (cont’d)

Average ms speedup average ms speedupHTTP 3111 2348SPDY 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%

DSL 2 Mbps downlink, 375 kbps uplink Cable 4 Mbps downlink, 1 Mbps uplink

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]

Average ms SpeedupPacket loss rate HTTP SPDY basic(TCP)

0% 1152 1016 11.81%0.50% 1638 1105 32.54%

1% 2060 1200 41.75%1.50% 2372 1394 41.23%

2% 2904 1537 47.70%2.50% 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]

Average ms SpeedupRTT 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%

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-in-mem server

SPDY “plug-in” for wireshark Use SCTP with SPDY

Google and PEL work

SPDY protocol specification http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2

SPDY white paper http://www.chromium.org/spdy/spdy-whitepaper [1]

SPDY homepage with other resources http://www.chromium.org/spdy/

References