Improving performance by changing the rules from fast to SPDY
SPDY Talk
-
Upload
bojan-babic -
Category
Documents
-
view
1.627 -
download
0
description
Transcript of SPDY Talk
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
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