WHAT PROBLEM ARE WE TRYING TO SOLVE? Web sites are slow*
HOW DO WE WANT TO SOLVE IT? We dont!
IS HTTP THAT BAD? VERB /some/path/to/content HTTP/1.1 Host: www.somehost.com Accept: text/html Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 ( Connection: Keep-Alive Content-Length: 20 Maybe some body here
A QUICK DETOUR FOR TCP WHAT GOES INTO A CONNECTION? Round trip: Syn/Syn-Ack/Ack (LATENCY!) NYC to SFC: ~2530mi, RTT in vacuum: 27ms, RTT in fiber: 41.04ms Slow-Start/Window Scaling (Diminishing returns on bandwidth)
HOW DO WE SOLVE THIS NOW? Http 1.1: Keep-alive default (option for 1.0 Http 1.1: Pipelining (not good enough, maybe not even used) Browsers: 6-8 max concurrent connections per server Think of 1mb of data split 1, 10, 100 ways cache-control Minimize connections (sprites, minification, domain sharding)
WASN'T THIS TALK ON SPDY? SPDY embraces HTTP, don't reinvent wheel. It's not WebSockets, different problem.
MULTIPLEXING Spdy uses one persistent SSL connection and multiplexes requests. True duplex; no waiting. Better window scaling Frames replace individual request/response (Control Frames/Data Frames)
COMPRESSED HEADERS More important than you may realize! Cookies, repetitive headers, etc.
CONTENT PRIORITIZATION Have some control between browser/server
SERVER PUSH/SERVER HINT Server can send or suggest new resources without client having to parse html