Tech Talks @Rosenstraße

Bojan Babicbojan.babic@groupon.de@bojanbabic

SPDY

Architecture of real-time web

HTTP/1.0

 

 

• new header introduced: Keep-alive• it has been adopted by community • default  in next version of HTTP

HTTP/1.1

- RFC 2616: HTTP/1.1- draft 1998- release June 1999

Pipelining

- non-idempotent connections 

Yahoo!

 

Apple circa 1997

 

Amazon

eBay

 

Google

 

Networking layer

 

TCP Handshake

 

Fast Forward

 

from Alice in Chains

to P-P-P-Poker Face 

 

Intrawebz today

In order page to load today on average: • 44 resources• 7 hosts• 320KB • ~66% of compressed ( 90% in Alexa top 1000 )• RTT 50-500ms• number of connections to load  http://www.groupon.de - 83 

o facebook 75o google+ 64o NYT 84

• more more connections 

Still

• Expensive to make client - server connection ( TCP congestion aka TCP slow start)

• One connection at time and responses sequentially ( Keep-alive doesn't work )

• snippet from RFC 

    "server MUST send its responses to those requests in the same order that the requests were received"

• even pipeline

Still Dre

client: -> GET /A HTTP/1.1client: -> GET /B HTTP/1.1 client: -> GET /C HTTP/1.1server: <- RESPONSE A: 200 OKserver: <- RESPONSE B: 200 OKserver: <- RESPONSE C: 200 OK• what if B is extremely large? • what if C is ready before A and B?• parallel request, multiplexing ? pipelining (bad idea RFC) • Requests only triggered by clients ( stocks, chat, weather )• Error 500 response: what does it really mean ( gateway

issue, process crashed ... )  • more downsides? anyone? 

Page Load vs Bandwidth

Http - current state - tricks

• prefetch DNS• work around limitations by enhancing policy within browser  

 (increase number of connections per domain)o enhance http limits in next versions by increasing number

of threads allowed per host ( 2, 4, 6 ...) • connection warming ( make request before it has been

sent , in order to remove handshaking out of way )• server push -  comet, channel, websocket are long lived

gets ( a lot of overhead ) 

Solutions (kinda) 

• pipelining ( doesn't really work )o all browsers turn it off by default ( except Opera )o hard to debug o RFC

• connection sharding ( in order to involve more threads from browser )o img1.groupon.com, img2.groupon.com

• inlining css and js/ css sprites•  embedded images in data url 

SPDY://

 

Finally - SPDY ( HTTP/2.0?)

• SPDY attempts to be efficient by using the network more intelligently

• HTTP compatible• Created by Big G• Chrome: A/B testing 95% spdy 5% http• Google services • Endorsed by Firefox ( FF11 )• Used on Amazon Fire as protocol for their split architecture

chrome://net-internals/#spdy

 

gmail POC 

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

Chrome: loaded 2.65s 305K

Firefox: loaded 5.5s 1.6M

SPDY under the hood

• built on top of SSL but wraps http ( GET/POST remain the same ) 

• adds session layer on top os SSL that allow MX

SPDY features• each request assigned stream-id• mandatory compression: headers compression is mandatory

o most of headers do not change so they are predefined and mapped in browser - only 3B are sent

• connection multiplexing o less connections o less packets 

• uses SSL - finally internet secure (firesheep)• response in order which makes sense for server • server push ( even IDs server vs client request odd IDs) • prioritized request ( stylesheet, viewable images ... )• non-idempotent requests supported

SPDY features cnt

• domain desharding by defaulto one connection per domain leaving cwnd 6 time smaller

compared to httpo no dns lookup

• reduce total amount of packages• reduce number of RT• on closed connection SPDY sends full report ( GOAWAY

FRAME ) which request have been processed • increased bandwidth utilization but speed to light did not

change with spdy (page load time vs RTT, RTT vs bandwidth)

• OVERALL : send fewer bytes using fewer connections 

Why SSL? 

• Why not port 80? Extend http handshake to at least one more RT 

• Why not anther port? By default firewalls close other ports, problem upgrading configs

Why SSL? part 2

• Meantime in Web Sockets team: measuring package lost over non-http protocol using following ports:o port 80 : 65% success rate ( "transparent" proxies - they

do mess with our data )o port 6198: 86% success rateo port 443: 95% success rate ( encrypted data goes thru

firewalls )• Data loss pretty low

Why SSL? part 3

• SSL is sloooow• Really? faster CPUs• TLS increase size of payload up to 2-3%, buut SDPY

compresses headers• real world data by Google:

o spdy-no-ssl vs http: for 1-2% packet loss 41-47% speed increase

o spdy vs http: ~40% improvemento spdy vs https: 15,3% improvement

SPDY multiplexing

SPDY compression

• avg headers size from 658B to 59B• dictionary of common headers:

o Content-Typeo User-Agento encodingo Dateo ...

• Do not transfer headers just dict values• reduce upload size• reduce download size

SPDY lab results

• 77% of requests reduced 90% in size• 94% of requests reduced 80% in size• upstream redundant headers 

How to be ready for SPDY?

• no changes from developer side• changes on client side ( already done ... )• additional header recognition 

o server push X-Associated-Content• changes on server side 

o mod_spdy ( apache )o Netty 3.3.1( twitter team contribution )o spdy for node.js servero spdy google server ( to be open sourced )

 

o nginx need to be rewritten to be ready for spdy

 

• HTTP -> SPDY gateways o comercial CDNs: cotendo, strange loop networks

SPDY Criticism

• not standard it is draft • SSL poor fit for hierarchical caching • debugging tools not ready at moment (being

developed)

SPDY Criticism more

• Next Protocol Negotiation o http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00.htmlo extension to SSL  OKo part of SSL handshake no additional RTs OKo SSL initially requires more RTs

Plans for future

• Spring 2012 FF and Google visit IEEFTo draft here: 

http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1

• possible projects?- riak over spdy - map/reduce over spdy

 

useful links:

groups.google.com/group/spdy-devhttps://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2