1.
Tech Talks @Rosenstraße
Bojan Babic
bojan.babic@groupon.de
@bojanbabic

2. SPDY
Architecture of real-time web

3. HTTP/1.0

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

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

7. Pipelining
- non-idempotent connections

8. Yahoo!

9. Apple circa 1997

10. Amazon

11. eBay

12. Google

13. Networking layer

14. TCP Handshake

15. Fast Forward

16. from Alice in Chains

17. to P-P-P-Poker Face

18. 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 75
o google+ 64
o NYT 84
• more more connections

19. 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

20. Still Dre
client: -> GET /A HTTP/1.1
client: -> GET /B HTTP/1.1
client: -> GET /C HTTP/1.1
server: <- RESPONSE A: 200 OK
server: <- RESPONSE B: 200 OK
server: <- 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?

21. Page Load vs Bandwidth

22. 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 )

23. 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

24. SPDY://

25. 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

26. chrome://net-internals/#spdy

27. gmail POC
"Figures don't lie, but liars can figure"
Chrome: loaded 2.65s 305K
Firefox: loaded 5.5s 1.6M

28. 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

29. 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

30. SPDY features cnt
• domain desharding by default
o one connection per domain leaving cwnd 6 time smaller
compared to http
o 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

31. 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

32. 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 rate
o port 443: 95% success rate ( encrypted data goes thru
firewalls )
• Data loss pretty low

33. 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% improvement
o spdy vs https: 15,3% improvement

34. SPDY multiplexing

35. SPDY compression
• avg headers size from 658B to 59B
• dictionary of common headers:
o Content-Type
o User-Agent
o encoding
o Date
o ...
• Do not transfer headers just dict values
• reduce upload size
• reduce download size

36. SPDY lab results
• 77% of requests reduced 90% in size
• 94% of requests reduced 80% in size
• upstream redundant headers

37. 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 server
o spdy google server ( to be open sourced )

38.
o nginx need to be rewritten to be ready for spdy

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

40. SPDY Criticism
• not standard it is draft
• SSL poor fit for hierarchical caching
• debugging tools not ready at moment (being
developed)

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

42. Plans for future
• Spring 2012 FF and Google visit IEEFT
o draft here: http://dev.chromium.org/spdy/spdy-
protocol/spdy-protocol-draft1
• possible projects?
- riak over spdy
- map/reduce over spdy

43.
useful links:
groups.google.com/group/spdy-dev
https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00
http://www.chromium.org/spdy/spdy-protocol/spdy-
protocol-draft2