The document discusses the evolution of HTTP/2, which aims to improve the efficiency of web communications by reducing response times and optimizing resource use. Key features include multiplexing to handle multiple requests simultaneously, header compression with HPACK, and server push to proactively deliver content. HTTP/2 represents a significant advancement over HTTP/1.1, though ongoing support for both protocols will be necessary during the transition period.

1. HTTP/2 and Other NextGen Protocols:
What’s New?
V 1.4
Daniel Austin
GRIN Technologies, Inc.
daniel.austin@grintech.net
#daniel_b_austin
.
HTML5 DevConf
October 20, 2015

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 now RFC 7540.

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 first draft published (actually SPDY)
– So much for simplicity!
• May 14, 2015 HTTP/2 becomes RFC 7540 !!! <- victory
• Supported by most major browsers and HTTP servers

4. No Web Without HTTP
WWW
HTML
(Structure)
URI
(Addresses)
HTTP
(Transport)

5. Goals 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
– This doesn’t mean things can’t be fixed
– 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 is was SPDY?
• Originally proposed by Google as a wire format extension to
HTTP in 2011
• Served as an experimental protocol for improvements to HTTP
– Without the burden or standardization and associated risks
• SPDY became the basis for HTTP/2 in 2012
– Most of the development /implementation work focused on HTTP/2
• In February 2015, Google announced its plans to remove
support for SPDY in favor of 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. 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!

14. 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. Illustrating Multiplexing
Source: http://nuli.nhncorp.com/

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 (No More Black Magic)
• Current Version: RFC 7541!
• 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’ now RFC 7301 and RFC 7639
– 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/2 does not require the use of TLS for all connections.
The Working Group did NOT reach consensus regarding the use of
TLS for all HTTP/2 connections. But every HTTP/2 client does
require TLS
• Reduction in TLS connection Costs + OCSP Efficiencies
• TLS Tunneling
– Protects connections from proxies and intermediaries
– Experience with WebSockets and others
• Hidden Semantics of Sessions via TLS

24. MPPC and the TCP Transport Equation
• Single Object:
Ttcp= Sz/R+2RTT+tidle
For multiple 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. Implementations
Servers
• Akamai Edge servers
• F5 BigIP
• Apache (mod_h2)
• Nginx
• Jetty
• MS IIS (Windows 10)
Clients
• Chrome
• Firefox
• Safari 9 (+ apps!)
• CURL
• MS Edge (Windows 10)
– finally

27. How Well Does it Work (Today)?
Very well!
• Significant variation in overall benefit for different application
types
• Response Time reductions of 5-60%
• Many implementations (up-to-date ones)

28. What’s Changed?
• Multiplexing
• HTTP is now 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

29. What About HTTP/2 And Mobile Devices?
• HTTP/2 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
– No support for HTTP/2!
• Challenges for mobile devices go beyond what HTTP can fix

30. Who’s Using HTTP/2?
 Google
 Twitter
 Yahoo!
 Facebook
That’s a large % of Web traffic!

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

32. 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 and framing?
– No

33. Scratch and QUIC
• QUIC (Google, 2012) is another experimental HTTP protocol
extension
– Proposed by Google in 2012
– Uses UDP rather than TCP/IP
• Does not use large datagrams
– Shares multiple features with HTTP/2
• Upgrade, framing, TLS only
• Currently widely used across Google properties
• Scratch (Austin, 2010) is a similar proposal based on HTTP-over-UDP
– Most proposed Scratch features appeared in HTTP/2 and QUIC

34. End: No Fate But What We Make
• HTTP/2 is now officially 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

35. The Last Word
HTTP/2 isn’t just about technical changes to the Web’s
favorite protocol…it also proves that the Web can make
big changes in short periods of time.
Over the course of three years, developers came together
and changed the way the Web moves over the wire. That’s
significant.

36. Thank You!
V 1.4
Daniel Austin
GRIN Technologies, Inc.
daniel.austin@grintech.net
#daniel_b_austin
.
HTML5 DevConf
October 20, 2015