SPDY @Zynga
-
Upload
mike-belshe -
Category
Documents
-
view
122 -
download
3
description
Transcript of SPDY @Zynga
Agenda
● Motivation & Background
● What is SPDY?
● Who's Using SPDY?
● SPDY and Mobile
● SPDY and REST APIs
● Standardization
Motivation
Latency & Security
Background: What is a WebPage?
● ~86 resources
● ~13 hosts
● ~966KB
● ~66% compressed (top sites are ~90% compressed)
● Except HTTPS, where < 50% compressed.
Source httparchive.org
Background: Poor Network Utilization
Web Page evolution has led to poor network utilization.
Bandwidth is going up... RTT isn't going down.
Background: Pesky Round Trips
Browser Perf Problems
● Network
● Rendering / Layout
● JavaScript Execution
● Stylesheets
● Flash
● More Network Loads
HTTP Connections
Average: 29 connections per page.
25%-tile = 10 50%-tile = 20 75%-tile = 39 95%-tile = 78
Incremental Improvements - Meh.
● Incremental changes don't "move the needle"○ They're hard to figure out individually○ Each only works for some people, with hacks
● Problem is the intermediaries (a.k.a. proxies)○ Transparent proxies change the content.○ Example: pipelining - donde esta?○ Example: stripped "Accept-Encoding" headers
■ we can't even improve "negotiated" compression!
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
What is SPDY?● Multiplexing
○ Get the data off the client
● Compression○ HTTP headers are excessive○ Uplink bandwidth is limited
● Prioritization○ Today the browser holds back○ Priorities enable multiplexing
● Server Push○ Websites do some of this today with data URLs
Less is More - Conns, Bytes, Packets
Deployment: Process of Elimination
● Avoid changing the lower-level transport
● Available transports: TCP or UDP.○ Note: SCTP not an option due to NAT.
● UDP○ We'd have to re-engineer TCP features.
● That leaves us with TCP.○ Ok, so which port? 80 or 443?
Deployment: Port 80
● HTTP runs on port 80.
● Proxies are a barrier to protocols○ HTTP/1.1 1999 - Pipelining still not deployed○ Compression negotiation
● Upgrade header requires a round trip
● 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%
Deployment: Port 443
● Port 443 runs SSL/TLS.○ Adds server authentication & encryption
● Handshake is extensible:○ Next-Protocol-Negotiation
www.ietf.org/id/draft-agl-tls-nextprotoneg-00.txt
Can We Address Latency & Security Separately?● If eavesdropping in the cafe is still possible in 2015 with
trivial tools, we have failed our users.
● The internet is weak already and getting worse.○ A matter of life and death
● Firesheep tools make sniffing easy
● Major content providers want privacy○ Facebook opt-in○ Twitter opt-in UPDATE: Now on by default!○ GMail and G+ already SSL only.○ SSL is just too slow right now...
HTTPS vs SPDY (Google)
Update Jan 2012: Google has announced that SPDY (w/ SSL) is now faster than HTTP on Google properties.
Who Uses SPDY?
● Websites:○ Google since 2010○ Amazon Kindle Fire
● Browsers○ Google Chrome since 2010○ Firefox 11+○ Chrome for Android
● Servers○ Apache w/ mod-spdy○ nginx has announced support coming○ Java/Ruby/Python/node.js/Erlang/Go & C impls!○ netty framework
● Mobile○ iPhone client
SPDY & Mobile
● New client-side problems○ Battery life constraints○ Severely limited CPUs
● New Network Properties○ Latency from 150 - 300ms per Round Trip○ Bandwidth 1-4Mbps
● New use cases○ Mobile Web Browsers are 1st generation
■ So web browsing sucks○ Everyone uses Apps w/ REST APIs anyway
SPDY and Battery Life
● Network activity is one of the biggest battery drains● SPDY is lightweight:
○ Fewer connections○ Fewer packets○ Fewer sends
● But.....○ Mobile network activity can be sporadic
■ e.g. a ping every 60-300secs○ SSL connections are more expensive to establish
■ Anecdotal - is the handshake CPU intensive○ Every SSL implementation is unoptimized.
● I hate to say it, but until we optimize SSL clients on mobile. SPDY may not be ready for mobile.
SPDY and Mobile Networks
● Good news○ Mobile networks are the SPDY sweetspot
■ High latency and High bandwidth
● Bad news○ Operators timeout NATs aggressively (~60s)○ Traditional SSL is unoptimized
■ OCSP validation is particularly poor
● Mitigation○ Trust your own certificate to bypass OCSP in apps○ Don't trust pooled connections over 60s old
SPDY & REST APIs
● Apps use HTTP to transfer JSON or XML
● Don't need to load HTML/CSS/Assets, they are installed up front
● REST APIs over HTTP need batching○ due to HTTP connection/serialization limits○ JSON fundamentally not streamable○ Lose cacheability○ Sacrifices latency for throughput
JSON Streamability
● REST APIs are messages; how to best deliver a message over any network?
● Network will chunk data.
● Round trips exist *between* chunks. More chunks == more chance of delays, lost packets.
● Small JSON blobs are good.
● Large JSON blobs are bad.
● JSON not parseable until all JSON is received!!
Standardization
● Test implementations are cropping up everywhere
● Badly in need of an interoperability test suite!
● Going to IETF next month to talk about HTTP/2.0
○ SPDY will likely change, but hopefully will be a part of it.
● In 2012, SPDY is available on over 50% of browsers
Thank You!
Good luck to Zynga!