SPDY - Clean Slate HTTP

1
SPDY - Clean Slate HTTP

•  Note This presentation is being loaded over
  SPDY

2
SPDY - Clean Slate HTTP

• About SPDY
• Motivation
• Requirements
• Plan
• Initial Results
• Testing Methods
• Network Efficiency
• Header Compression
• Page Load Times
•  Deployment
• Process of Elimination
• Port 80
• Port 443

• Lessons
• The new bottleneck
• Solutions
• Suffering handshakes
• Bandwidth doesn't matter
• Solutions
• Next steps
• Server hint
• Server push
• 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
  contentAllow for incremental changesPerforming
  "better" with content changes is okayPerforming
  "worse" without content changes is unacceptable
• Perform always better, never worse than HTTP
• Drop-in replacement from webapp's point of view
• Changing the web server/application server is
  inevitable and therefore acceptable

5
About SPDY Plan

• Phase 1
• Multiplexed Stream SupportSPDY 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.
• Request PrioritizationSPDY  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.
• HTTP Header CompressionSPDY  compresses HTTP
  headers, leading to fewer packets and fewer bytes
  transmitted.
• Phase 2
• Server Initiated Streams (aka "Server
  Push")SPDY  allows either the client or server
  to initiate a stream once the client has
  established a connection.  
• Server HintThe 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
• Motivation
• Requirements
• Plan
• Initial Results
• Testing Methods
• Network Efficiency
• Header Compression
• Page Load Times
•  Deployment
• Process of Elimination
• Port 80
• Port 443

• Lessons
• The new bottleneck
• Solutions
• Suffering handshakes
• Bandwidth doesn't matter
• Solutions
• Next steps
• Server hint
• Server push
• Other

7
Initial Results

• "Figures don't lie, but liars can figure"

8
Initial Results - Testing Methods

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

9
(No Transcript)
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
• Motivation
• Requirements
• Plan
• Initial Results
• Testing Methods
• Network Efficiency
• Header Compression
• Page Load Times
•  Deployment
• Process of Elimination
• Port 80
• Port 443

• Lessons
• The new bottleneck
• Solutions
• Suffering handshakes
• Bandwidth doesn't matter
• Solutions
• Next steps
• Server hint
• Server push
• Other

14
Deployment Process of Elimination

• Hoping to avoid changing the lower-level
  transport
• Much easier "burden of proof"
• Works with existing infrastructure
• Available transports
• TCP, UDP are possible.
• SCTP not an option due to NAT.
• UDP
• We'd have to re-engineer TCP features.
• That leaves us with TCP.
• 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.
• HTTP/1.1 1999 - Pipelining still not deployed
• Compression negotiation
• WebSockets Data Shows that using HTTP over a
  non-standard port is less tampered with than port
  80.
• Success rate
• HTTP  (port 80)    67
• HTTP  (port 61985) 86
• HTTPS (port 443)   95

16
Deployment Port 443

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

17
SPDY - Clean Slate HTTP

• About SPDY
• Motivation
• Requirements
• Plan
• Initial Results
• Testing Methods
• Network Efficiency
• Header Compression
• Page Load Times
•  Deployment
• Process of Elimination
• Port 80
• Port 443

• Lessons
• The new bottleneck
• Solutions
• Suffering handshakes
• Bandwidth doesn't matter
• Solutions
• Next steps
• Server hint
• Server push
• Other

18
Lesson 1 TCP is the new bottleneck

• HTTP leverages 6 connections per domain.
• 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
• 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.

20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
What happens if we increase the initial cwnd
to..... 18?
27
(No Transcript)
28
Compare to Traditional HTTP

•   

29
(No Transcript)
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
• 10 has been proposedwww.ietf.org/id/draft-hkchu-t
  cpm-initcwnd-00.txt
• Not really good enough - not "future proof"
• Not really good enough for high speed links today
• Harder solution is to change TCP's congestion
  management algorithms.
• That means modifying a lot of TCP stacks
• Solution
• Store TCP state on the client

32
Solving init-cwnd (2)
33
SPDY - Clean Slate HTTP

• About SPDY
• Motivation
• Requirements
• Plan
• Initial Results
• Testing Methods
• Network Efficiency
• Header Compression
• Page Load Times
•  Deployment
• Process of Elimination
• Port 80
• Port 443

• Lessons
• The new bottleneck
• Solutions
• Suffering handshakes
• Bandwidth doesn't matter
• Solutions
• Next steps
• Server hint
• Server push
• 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
• Rapidly increasing.
• 1Gbps projects are underway.
• See also http//www.akamai.com/stateoftheinternet
  /
•  Average RTT to Google is 114ms
• Not decreasing quickly
• Mobile makes this worse
• Let's see an example
• Fix RTT at 60ms, 0 packet loss, vary bandwidth
• 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
• Motivation
• Requirements
• Plan
• Initial Results
• Testing Methods
• Network Efficiency
• Header Compression
• Page Load Times
•  Deployment
• Process of Elimination
• Port 80
• Port 443

• Lessons
• The new bottleneck
• Solutions
• Suffering handshakes
• Bandwidth doesn't matter
• Solutions
• Next steps
• Server hint
• Server push
• 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

•                       SPDY (human readable)
•  
• SYN frame
• stream_id 1
• associated_stream_id 0
• priority 1
• num_headers 4
• 6method4POST
• 3url26http//blogger.com/my_blog
• 10user-agent19blahblahblah chrome
• 7version8HTTP/1.1
•  
• DATA frame
• stream_id 1
• flags fin
• length 31
• here is my very short blog post

•                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

48
Request Path

•                  SPDY (closer to actual)
•  
• 80 01 00 01
• 00 00 00 6b  
• 00 00 00 01
• 00 00 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
• 6method4POST
• 3url26http//blogger.com/my_blog
• 10user-agent19blahblahblah chrome
• 7version8HTTP/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.

•