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!