SPDY protocol - PowerPoint PPT Presentation

spdy protocol n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
SPDY protocol PowerPoint Presentation
Download Presentation
SPDY protocol

play fullscreen
1 / 25
SPDY protocol
115 Views
Download Presentation
kaycee
Download Presentation

SPDY protocol

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. SPDY protocol By Jory Cohen Made for CISC856, Spring 2010 Thanks to Dr. Amer, Mike Belshe(Google), Jon Leighton

  2. What is SPDY? • Experimental protocol being researched by Google and the UD PEL • Application-layer protocol for transporting content over the web, designed specifically for minimal latency

  3. Why SPDY? • HTTP is inefficient • Single request per connection • Browsers now open 6connections per domain for concurrency • Only clients can initiate requests • Header size – 200 bytes to over 2 KB • Redundant headers • Optional data compression

  4. What does SPDY offer? • 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

  5. Which layer is SPDY?

  6. 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

  7. SPDY benefits • The client can request as many items as the clientwants 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

  8. Server Push • 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

  9. Server Push Example Client Server Stream 1 HTTP Get request Response for HTTP Get Stream 1 Server push Stream 2 Server push Stream 4 Server push Stream 6 Server push Stream 8

  10. Server hint • Server tells client that itwill 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

  11. Server Hint Example Client Server HTTP Get request Stream 1 Response for HTTP Get Stream 1 Server hints to client Stream 2 Client request based on hint Stream 3 Client request based on hint Stream 5 Client request based on hint Stream 7 Client request based on hint Stream 9 Server responses Streams 3,5,7,9

  12. 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

  13. 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, clientsets the FLAG_FIN flag and connection is half closed

  14. Client Server Stream ID = 1 SYN_STREAM Data or Requests Stream ID = 3 SYN_STREAM Data or Requests SYN_STREAM Stream ID = 2 Data or Requests Stream ID = 1 SYN_REPLY SYN_REPLY Stream 3 & Data Stream 1

  15. 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

  16. Client Server Stream 3 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

  17. 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.

  18. 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

  19. Interesting SPDY PDUs (cont’d) • SETTINGS • Used to communicate ID/value pairs • Upload bandwidth • Download bandwidth • Round trip time • Maximum concurrent streams • Current CWND • Persistence of previous settings

  20. 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]

  21. 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]

  22. 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]

  23. Google and PEL work • SPDY enabled Chrome browser with Flip-in-mem server • SPDY “plug-in” for wireshark • Use SCTP with SPDY

  24. References • 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/