1. SPDY - Clean Slate HTTP Note: This presentation is being loaded over SPDY

2. SPDY - Clean Slate HTTP About SPDY o Motivation o Requirements o Plan Initial Results o Testing Methods o Network Efficiency o Header Compression o Page Load Times Deployment o Process of Elimination o Port 80 o Port 443 Lessons o The new bottleneck  Solutions o Suffering handshakes  Bandwidth doesn't matter  Solutions Next steps o Server hint o Server push o Other

3. About SPDY: Motivation We want to reduce page load times on the Web, and we decided to build a protocol for it.

4. About SPDY: Requirements Avoid requiring the website author to change content Allow for incremental changes Performing "better" with content changes is okay Performing "worse" without content changes is unacceptable Perform always better, never worse than HTTP Drop-in replacement from webapp's point of view o Changing the web server/application server is inevitable and therefore acceptable

5. About SPDY: Plan Phase 1 1.Multiplexed Stream Support SPDY can send many sessions concurrently over a single TCP connection without serializing requests. Make SPDY as efficient as HTTP but only use a single connection. 2.Request Prioritization SPDY implements request priorities. A client can request as many items as it wants from the server, and request that the server use best-effort to return the content in the highest-priority first. This allows the client to be free to request resources without having to worry that unimportant requests will clog the channel. 3.HTTP Header Compression SPDY compresses HTTP headers, leading to fewer packets and fewer bytes transmitted. Phase 2 1.Server Initiated Streams (aka "Server Push") SPDY allows either the client or server to initiate a stream once the client has established a connection. 2.Server Hint The server often knows a client will need a resource. It can inform the client about resource it would otherwise discover much later.

6. SPDY - Clean Slate HTTP About SPDY o Motivation o Requirements o Plan Initial Results o Testing Methods o Network Efficiency o Header Compression o Page Load Times Deployment o Process of Elimination o Port 80 o Port 443 Lessons o The new bottleneck  Solutions o Suffering handshakes  Bandwidth doesn't matter  Solutions Next steps o Server hint o Server push o Other

7. Initial Results "Figures don't lie, but liars can figure"

8. Initial Results - Testing Methods 3 major variables on the network o Packet Loss o Bandwidth o Round-Trip-Time Looking at any one configuration is anecdotal, need to look at a spectrum of data. Our test content includes: o high-fidelity copies of top-25 web pages. o includes exact HTTP headers, compression, etc. Packet loss simulators stink (random loss is not realistic) o We don't have a good model. o We don't have a good simulator.

9. Initial Results: Network Efficiency Test: Download the same "top 25" pages via HTTP and SPDY Network simulates a 2Mbps DSL link, 0% packet loss.

10. Initial Results: Header Compression On low-bandwidth links, headers are surprisingly costly. Headers alone can cost more than 1s of latency.

11. Initial Results: Page Load Time top-25

12. Initial Results: Page Load Time

13. SPDY - Clean Slate HTTP About SPDY o Motivation o Requirements o Plan Initial Results o Testing Methods o Network Efficiency o Header Compression o Page Load Times Deployment o Process of Elimination o Port 80 o Port 443 Lessons o The new bottleneck  Solutions o Suffering handshakes  Bandwidth doesn't matter  Solutions Next steps o Server hint o Server push o Other

14. Deployment: Process of Elimination Hoping to avoid changing the lower-level transport o Much easier "burden of proof" o Works with existing infrastructure Available transports: o TCP, UDP are possible. o SCTP not an option due to NAT. UDP o We'd have to re-engineer TCP features. That leaves us with TCP. o Only two ports available universally  Port 80?  Port 443?

15. Deployment: Port 80 Should be our first choice. Except HTTP runs on port 80. Proxies and intermediates make for a treacherous environment. o HTTP/1.1 1999 - Pipelining still not deployed o Compression negotiation WebSockets Data Shows that using HTTP over a non- standard port is less tampered with than port 80. o Success rate:  HTTP (port 80) 67%  HTTP (port 61985) 86%  HTTPS (port 443) 95%

16. Deployment: Port 443 Port 443 runs SSL/TLS. o Added benefit of server authentication & encryption Handshake is extensible: o Next-Protocol-Negotiation www.ietf.org/id/draft-agl-tls-nextprotoneg-00.txt www.ietf.org/id/draft-agl-tls-nextprotoneg-00.txt But isn't TLS too slow? o CPU issues are minor o CPU for bulk encryption is near-zero cost. o TLS does increase bandwidth by 2-3%  Mitigated by SPDY better compression. o Round Trip Times are significant o SSL requires 2 or 1 RTs for the handshake  Can we reduce to 1 or 0 RTs?

17. SPDY - Clean Slate HTTP About SPDY o Motivation o Requirements o Plan Initial Results o Testing Methods o Network Efficiency o Header Compression o Page Load Times Deployment o Process of Elimination o Port 80 o Port 443 Lessons o The new bottleneck  Solutions o Suffering handshakes  Bandwidth doesn't matter  Solutions Next steps o Server hint o Server push o Other

18. Lesson #1: TCP is the new bottleneck HTTP leverages 6 connections per domain. o HTTP has no multiplexing, multiple connections is the only way to get parallelism TCP applies congestion control independently on each connection. SPDY is more efficient on the TCP transport o Reduced bandwidth, packets, and connections. initcwnd (aka TCP Slow Start) favors multiple connections Let's see it in action.

19. Lesson #1: Init-cwnd woes In this example: Network: 100Mbps 200ms RTT 0% loss Browser Chrome Using SPDY, to load the page over a single connection No resources are cached WebPage http://www.facebook.com/ But this can be witnessed on many many webpages. There is nothing wrong with the facebook page content.

26. What happens if we increase the initial cwnd to..... 18?

28. Compare to Traditional HTTP

30. Increasing InitCwnd In this test, we use a simple page which is blocked only on cwnd. HTTP's initcwnd is 6 times larger than SPDY's cwnd by use of multiple connections. This does NOT prove that we should increase initcwnd indefinitely.

31. Solving init-cwnd Obvious solution is to increase the value: o 10 has been proposed www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt o Not really good enough - not "future proof" o Not really good enough for high speed links today Harder solution is to change TCP's congestion management algorithms. o That means modifying a lot of TCP stacks Solution: o Store TCP state on the client

32. Solving init-cwnd (2)

33. SPDY - Clean Slate HTTP About SPDY o Motivation o Requirements o Plan Initial Results o Testing Methods o Network Efficiency o Header Compression o Page Load Times Deployment o Process of Elimination o Port 80 o Port 443 Lessons o The new bottleneck  Solutions o Suffering handshakes  Bandwidth doesn't matter  Solutions Next steps o Server hint o Server push o Other

34. Lesson #2: SSL Handshakes Top-25 pages ~23% benefit without SSL ~14% benefit with SSL Naively we thought SSL had one handshake per page load. It actually has one handshake per "wave" of a page load.

35. Lesson #3: It's not the bandwidth Average bandwidth in the US is 3.9Mbps o Rapidly increasing. o 1Gbps projects are underway. o See also: http://www.akamai.com/stateoftheinternet/http://www.akamai.com/stateoftheinternet/ Average RTT to Google is 114ms o Not decreasing quickly o Mobile makes this worse Let's see an example: o Fix RTT at 60ms, 0% packet loss, vary bandwidth o Fix bandwidth at 5Mbps, 0% loss, vary RTT

36. Latency (page load time) decreases as the bandwidth increases. Note the diminishing returns.

37. Viewed another way, here is the percent latency reduction for each Mbps of bandwidth added. Increasing from 5Mbps to 10Mbps is ~5% benefit to page load time.

38. With a 60ms RTT, effective bandwidth taps out at about 1.6Mbps.

39. Now we vary the RTT for a fixed bandwidth. Reducing RTT, always helps reduce PLT.

40. Viewed another way, here is the percentage improvement for each 20ms of RTT reduced.

41. Effective bandwidth is better for low RTT.

42. Solution to Round-Trips Do less of them! Subdomain learning and pre-warming. Fold handshakes together, similar to what TLS/NPN does. THIS IS HARD.

43. SPDY - Clean Slate HTTP About SPDY o Motivation o Requirements o Plan Initial Results o Testing Methods o Network Efficiency o Header Compression o Page Load Times Deployment o Process of Elimination o Port 80 o Port 443 Lessons o The new bottleneck  Solutions o Suffering handshakes  Bandwidth doesn't matter  Solutions Next steps o Server hint o Server push o Other

44. Next Steps Server Hint Server Push Server-resolved DNS Flow control 0-RTT TLS Handshake Aggressive connection pre-warming IP based connection pooling Better strategies for keeping long-lived connections

45. Thank You! This is exciting stuff! You can help too: http://dev.chromium.org/spdy

46. Backup slides

47. Request Path HTTP POST /my_blog HTTP/1.1\r\n Host: blogger.com\r\n Content-encoding: chunked\r\n user-agent: blahblahblah chrome\r\n \r\n 1F\r\n here is my very short blog post\r\n 0\r\n \r\n SPDY (human readable) SYN frame stream_id = 1 associated_stream_id = 0 priority = 1 num_headers = 4 [6]method[4]POST [3]url[26]http://blogger.com/my_blog [10]user-agent[19]blahblahblah chrome [7]version[8]HTTP/1.1 DATA frame stream_id = 1 flags = fin length = 31 here is my very short blog post

48. Request Path SPDY (closer to actual) 80 01 00 01 00 00 00 6b 00 00 00 01 00 00 40 00 00 04 06method04post 03url1ahttp://blogger.com/my_blog 0auser-agent13blahblahblah chrome 07version08http/1.1 00 00 00 01 01 00 00 1f here is my very short blog post SPDY (human readable) SYN frame stream_id = 1 associated_stream_id = 0 priority = 1 num_headers = 4 [6]method[4]POST [3]url[26]http://blogger.com/my_blog [10]user-agent[19]blahblahblah chrome [7]version[8]HTTP/1.1 DATA frame stream_id = 1 flags = fin length = 31 here is my very short blog post

49. With multiplexing:

50. Results: Packet Loss Real world packet loss is ~1%. SPDY is 41%-47% faster for PL between 1 and 2%.

51. Results: RTT Average RTT is ~110ms. Fast RTTs are ~40ms. Typical US is 50-100ms.

52. Top 300 Content Question: Do highly optimized websites get less benefit? Randomly picked 300 sites from the Alexa Top-1000. Overall page load improvement average was 40%.