My talk on HTTP/2 for HTML5 DevConf May 22, 2014. I explain the current state as of draft 12.

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

10. Bandwidth, Latency, and All That

11. More Bandwidth? Less Latency!

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

14. Illustrating Multiplexing
Source: http://nuli.nhncorp.com/

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.

22. ALPN Example
[ 0.013] HTTP Upgrade request
GET / HTTP/1.1
Host: nghttp2.org
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c-12 HTTP2-Settings: AwAAAGQEAAD__wUAAAAB
Accept: */*
User-Agent: nghttp2/0.4.0-DEV
[ 0.024] HTTP Upgrade response
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c-12
…
Source: nghttp2 README

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

27. Implementations
Servers
• Netty
• Nghttp2
• Node-http2
• Chromium
• many more, including SPDY
implementations
Clients
• Chrome
• Firefox
• Opera
• CURL
• No IE

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

38. Sneak Preview! HTTP/3!
This is what the Internet
will look like in 2020.

39. Thank You!
Daniel Austin
Interstellar Travel, Inc.
HTML5 DevConf
May 22, 2014
@daniel_b_austin
daniel@thestarsmydestination.com