1. HTML5, HTTP/2, and You
V 1.1
Daniel Austin
Interstellar Travel, Inc.
HTML5 DevConf
May 22, 2014
daniel@thestarsmydestination.com
2. About: Today’s Talk
• Part 1 – What Has Gone Before
• Part 2 – Theory of HTTP/2
• Part 3 – HTTP/2 in Practice
• Part 4 – Only Forward
Disclaimer: I am not a member of the HTTPbis Working Group at
IETF. HTTP/2 is a work in progress, expect changes in the future.
3. What Has Gone Before
• 1991 – TimBL publishes HTTP 0.9
– Design Goal: Simplicity
• 1996 – RFC 1945 HTTP 1.0 ‘common usage’ (Informational)
• 1997-99 RFC 2068 (Proposed) & 2616+2617 (Standard)
• 2006-current Revisions of RFC 2616 (26 drafts!)
• 2012 – HTTP 2.0 first draft published (actually SPDY)
– So much for simplicity!
• April 2014 – HTTP 2.0 draft #12 published
• Supported by most major browsers and HTTP servers
4. No Web Without HTTP
WWW
HTML
(Structure)
URI
(Addresses)
HTTP
(Transport)
5. Goal of HTTP/2
• The #1 goal of HTTP/2 is to reduce HTTP response times!
• Improving bandwidth efficiency (not latency!)
– Network latency occurs on layer 4, and is not modifiable by changing
layer 7 protocols like HTTP
– No individual packet will arrive faster using HTTP/2!
Performance is response time.
6. HTTP/2 Defined
“[HTTP/2] describes an optimized expression of the syntax of the
Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more
efficient use of network resources and a reduced perception of
latency…
…HTTP's existing semantics remain unchanged. “
from draft-ietf-httpbis-http2-12
7. HTTP/2 & the Innovator’s Dilemma
Given the bandwidth and network latency we have, what changes can
we make at layer 7 to improve bandwidth efficiency?
• Rule #1: Don’t Break Everything (Anything)
– When even small changes can have large and unforeseen effects
• Preserving HTTP 1.1 Semantics
– Compatible implementations must fail gracefully to HTTP 1.1
This decision places significant constraints on what kinds of changes
can be made.
8. How HTTP/2 Achieves Its Goals
• Reducing the number of HTTP connections required
(multiplexing)
• Reducing the number of bytes and (logical) messages sent
across the wire
– HPACK, server push, Alt_SVC
• Prioritizing both messages and packets for queuing efficiency
• Improving caching efficiency at all levels
9. What’s SPDY?
• Originally proposed by Google as a wire format extension to
HTTP in 2011
• Now on v4, implements all the major features of HTTP/2
• Supported by most browsers and servers
• Serves as a testbed for improvements to HTTP
– Without the burden of standardization and associated risks
• SPDY became the basis for HTTP/2 in 2012
– Most of the development /implementation work focused on HTTP/2
12. Bandwidth Efficiency
• How well do we fill the pipe we have?
• Effective vs. Potential Throughput
• For a single object, The efficiency will depend on file size and
packet loss
• But at the ‘page’ level, HTTP introduces large inefficiencies
13. Streaming, Framing, and Multiplexing
• HTTP/2 effectively moves flow and connection control to a
lower level of the stack;
– Instead of connections we have streams (and stream IDs)
– Streams are divided into control and data frames
– Frames (and packets) are no longer required to arrive sequentially, but
can be queued for higher efficiency
• Hah! Head-of-line blocking solved (for the most part) Wow!
– Downsides
• More vulnerable to packet loss
• Unbroken streaming from client to server required
15. TCP/IP Is Limited By Packet Loss
• The Floyd Rule:
Bmax = A*(L)^1/2 * MSS/RTT
MSS = max segment size, RTT = round trip time
L = error rate (packet loss as a fraction)
A = AIMD constant (canonical value ~ 1.22
• Typical values of L are ~1% for LAN/WAN
May be as much as 3-5% on mobile!
16. Packet Loss & HTTP/2
• From TCP/IP’s point of view, HTTP/2 makes your Website look like one big binary file
– A single connection for each unique hostname on the ‘page’
– Multiplexing efficiently ‘packs the pipe’
• But when packets are lost, that single connection takes a hit across all the multiplexed
streams
– TCP/IP is extremely sensitive to packet loss but large files are less sensitive than
smaller ones
• End result: packet loss hurts more with HTTP/2, but not as much as you might think.
17. HPACK: Header Compression Black Magic
• Current Version: 0.7
• Provides a method for maintaining HTTP Header state
• Headers are in binary and need to be back-translated
• SPDY used DEFLATE, proved vulnerable to CRIME attack
• HPACK addresses CRIME
• Memory limited for small devices
• Works quite well!
– Typical compression ratio 30-80%
18. Server Push: A Modest Proposal
• Server push allows the server to -ahem- suggest to the client
which page requisites are needed for this page
• This is a fundamental change to the overall page loading
semantics of the Web
• Server push eliminates entirely the need for intransitive
hypertext links!!!
– Images should never have been hypertext links to begin with
19. Changing the HTTP loading cycle
Today the Web loads in 3 phases:
Using HTTP/2 and Server Push:
Load the base
page object ML
object
Create multiple parallel
persistent connections to
get the intransitive
content
Deferred loading
of page content
ng of page
content
Phase 1 Phase 2 Phase3
Load the base page
object AND
Create multiple parallel
persistent connections
to get the intransitive
content
Deferred loading
of page content
Phase 1 Phase 2
20. Server Push and Stream Priorities
• We can suggest to the client the priority (not necessarily the
order) in which resources are to be downloaded.
• This isn’t necessarily a good thing ™.
– Warning: manually overriding the default load priorities
many produce suboptimal results!
Source: http://nuli.nhncorp.com/
21. Protocol Negotiation
How to tell a client that the protocol has changed?
• NPN
– ‘Next Protocol Negotiation” originally proposed for SPDY (draft)
– Proposed that the server tell the client which protocols are supported.
– Deprecated in favor of ALPN
• ALPN
– ‘Application-level Protocol Negotiation’ (draft)
– Proposes that the client tell the server which protocols are supported.
23. TLS & HTTP/2
HTTP/ requires the use of TLS for all connections.
• Reduction TLS connection Costs + OCSP Efficiencies
• TLS Tunneling
– Protects connections from proxies and intermediaries
– Experience with WebSockets and others
• Hidden Semantics of Sessions via TLS
• Win Some Lose Some
– TLS has performance problems of its own
24. MPPC and the TCP Transport Equation
• Single Object:
Ttcp= Sz/R+2RTT+tidle
For persistent parallel connections:
Ttcp = (M+1)Si/Ri+[M/kNh]*3SRTTi+tidle
… for 1 base HTML page with M objects, with Si bits, at bandwidth Ri, k
connections per host, and Nh unique hostnames
25. The “SCS” Equation
For persistent connections, since HTTP/2 streaming flow control is
very close to TCP, we can simply set the browser connection
constant to 1:
Ttcp = (M+1)Si/Ri+[M/Nh]*3SRTTi+tidle
… for 1 base HTML page with M objects, with Si bits, at bandwidth
Ri, k connections per host, and Nh unique hostnames
26. Current Status of the HTTP/2 Specs
• HTTP/2 Draft 12 (04/23 2014)
– ‘implementation draft’
– Added BLOCKED control frame
– Changes to priority mechanism
• HPACK Draft 7 (04/03/2014)
• ALT-SVC Draft 1 (04/01/2014)
– New draft
– Suggests an alternate source for
resources to the client
• Associated proposals:
– PATCH, ALPN, others
Timelines
•March 2012: Call for proposals for HTTP 2.0
•September 2012: First draft of HTTP 2.0
•July 2013: First implementation draft of HTTP 2.0
•April 2014: Working Group last call for HTTP 2.0
•November 2014: Submit HTTP 2.0 to IESG as a Proposed
Standard
28. How Well Does it Work (Today)?
Very well!
• Current implementations are comparable to SPDY/3.1
• Significant variation in overall benefit for different application
types
• Response time reductions of 5-60%
• SPDY implementations are more robust and reliable
• Many implementations (up-to-date ones)
29. What about WebSockets?
• RFC 6455 Defines the WebSocket Protocol
– Associated API from W3C
– Bi-directional socket-level connections
– Some similarities with HTTP/2 (upgrades, TLS tunneling, more)
– Framing protocol is different from SPDY or HTTP/2
– Lacks HTTP semantics
• Current proposals are to migrate WS to HTTP/2 framing
– ‘Layering’ of WS on top of HTTP/2 – draft proposal
30. What Will Change?
• Multiplexing
– HTTP will be in binary
• Server Push
– Changes the implicit semantics off the HTTP loading cycle
• Changing the Browser Connection Constant
– One connection per unique hostname
– Changes the implicit semantics of HTTP connections
• Security & HTTP/2
– TLS only please, we’re secure
31. What About HTTP/2 And Mobile Devices?
• SPDY is already widely used for mobile devices using Android
– A lot of learning from the mobile experience
– In some cases it shows dramatic improvements
• Issues with connection times, TTFB, caching remain
• Amazon Silk uses both SPDY and server-side partial rendering
Challenges for mobile devices go beyond what HTTP can fix
32. The ‘Trusted Proxies’ Problem
• Problem: TLS encryption hides all knowledge of the data from intermediaries
– Reduces efficiency in both transport and caching
– Frustrates anonymity, packet inspection (good or bad)
– Makes life more difficult for ISPs and eavesdroppers
• Current Proposal:
– h2:// = HTTP/2 + TLS replaces https://, provides E2E encryption
– h2c:// = HTTP/2 + TLS replaces http://, may be decrypted enroute, requires
user consent
33. Adoption – What Can We Expect?
• The bad news: we’ll need to support HTTP 1.1 indefinitely
• Clients first, as always, then CDNs and ISPs
• Mixed states will be common
– not every HTTP connection will use (or be benefited by) HTTP/2
• We should also expect many sites to run in parallel for some time
• The community has done amazing work with implementations!
Boiling the ocean was never going to be cheap or easy.
34. The Future of SPDY?
• SPDY/4 is under development
– No spec exists (publicly anyway)
– chrome://flags allows spdy4 alpha 2 to be enabled
– Improved framing and better alignment with HTTP/2
• SPDY is serving as an ‘evolutionary testbed’ of sorts for
improvements to HTTP in general
– Parallel development is costly, improves cycle times
– Successful SPDY adoption provides additional confidence
35. Net Neutrality & HTTP/2
• When is your ISP a ‘proxy’, an ‘explicit proxy’, or a ‘trusted
proxy’?
• Can an ISP or intermediate of any kind force a protocol
upgrade/downgrade?
– Yes
• Can an ISP modify server push resource priorities?
– No
• Can an ISP modify framing prioritization?
– No
36. Scratch and QUIC
• QUIC (Google, 2012) is another experimental HTTP protocol
extension
– Proposed by Google in 2012
– Uses UDP rather than TCP/IP
– Shares multiple features with HTTP/2
• Upgrade, framing
• Scratch (Austin, 2010) is a similar proposal based on HTTP-over-UDP
– Most proposed Scratch features appeared in HTTP/2 and QUIC
37. End: No Fate But What We Make
• HTTP/2 is the best thing since sliced bread.
– Multiplexing will change the way the Web moves across the
wire.
– Server push will change the implicit semantics of the HTTP
loading cycle.
– Taken together, the features in HTTP/2 will change the Web
radically.
– Coupling TLS and HTTP/2 creates a bonded protocol
I am speaking for myself and not anyone else.
I originally intended to talk about HTML5 and HTTP/2, but changed the talk to be more about HTTP/2 – after all, this is an HTML5 conference!
reduced perception of latency
I don’t know what that means, cut it
Even though this is a ‘forced move’ in some sense it’s also a good one.
Another point that’s rarely made is that HTTP/2 includes multiple changes that work under the hood to make intermediate caches work better, which will have an additional impact on reducing response times at scale. ALTSVC, Server Push, PATCH
Typical bandwidth efficiency measures for many commercial websites are less than 20%!
Separation of data and control frames in HTTP/2: 12 Frame types, 1 data, 11 control.
Note the big limitation here: the single origin policy limits which URLS can be multiplexed.
Sally Floyd is a retired computer science professor at Berkeley and a prominent TCP researcher.
This is basic systems theory 101 – it stands to reason that as we push the overall throughput of the system to a greater level, failures are more costly.
Of course each packet belongs to a single file; only one file will be immediately impacted, but the congestion window for the connection will be reduced, and this will affect each stream.
This addresses the ‘faster trash problem I originally pointed out in 2009.
At one point the spec said something like ‘headers are compressed by black magic’. Apparently it involves Huffman encoding. Who knew?
Apologies to Marc A!
There really isn’t a bigger deal than this! Radical! No more intransitive hyperlinks!
Both are formally proposed extensions to TLS.
SSL Resumption still works, etc.
Solution for HTTP 1.0 is in Kurose & Ross, and for multiple objects is one of the problems in the book.
The solution for a single object using HTTP 1.1 was solved by Manasce in “Capacity Planning for Web Services”
I published the first solution to the HTTP 1.1 solution for multiple objects (the MPPC equation) in 2009
It doesn’t work as well as it should because of the head
This doesn’t take server push into account directly and is only a preliminary result! If I stand up here next year with something different, consider yourself warned.!
SCS = Single Connection Streaming
Chrome supports websockets over SPDY/4
The WebSocket API should remain stable regardless of how the underlying framing works
Perhaps as WS 2.0?
I think we can see some problems with this proposal, and I expect it will undergo significant revision as the spec progresses. In particular:
What if there are multiple ‘trusted proxies’?
Each ‘clear’ proxy increases the overall risk
Would international users be allowed/denied access to various trusted intermediates? What if the Chinese gov’t for instance decides not to allow
Users to use trusted proxies in the US?
Every intermediate proxy in the chain is a very sweet exploit target
The encryption surface becomes huge due to use of a single cert at given URI
TLS turns out to be good for things we never expected, like making protocol upgrades more reliable, and preventing your data from your ISP. HTTP/2 has some interesting effects:
ISPs can’t limit connections, have to limit bandwidth directly (via pooling, say)
ISPs can’t modify or inject
Nothing will protect you from your own government
QUIC does not use large datagrams however.
That’s a good thing!
I understand they are already hard at work on this. Back to simplicity!