狠狠撸

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.

Background: Poor Network Utilization

Web Page evolution has led to poor network utilization.

Bandwidth is going up... RTT isn't going down.

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 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
○ 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%

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!

狠狠撸

SPDY @Zynga

Recommended

More Related Content

What's hot (19)

Similar to SPDY @Zynga (20)

SPDY @Zynga