Incremental Improvements - Meh.● Incremental changes dont "move the needle" ○ Theyre 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 cant 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 webapps 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
Deployment: Process of Elimination● Avoid changing the lower-level transport● Available transports: TCP or UDP. ○ Note: SCTP not an option due to NAT.● UDP ○ Wed 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 & SecuritySeparately?● 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 ○ Dont trust pooled connections over 60s old
SPDY & REST APIs● Apps use HTTP to transfer JSON or XML● Dont 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