HTML5, HTTP/2, and You

V 1.1

Daniel Austin

Interstellar Travel, Inc.

HTML5 DevConf

May 22, 2014

daniel@thestarsmydestination.com

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.

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

No Web Without HTTP

WWW

HTML(Structure)

URI(Addresses)

HTTP(Transport)

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.

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

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.

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

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

Bandwidth, Latency, and All That

More Bandwidth? Less Latency!

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

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

Illustrating Multiplexing

Source: http://nuli.nhncorp.com/

TCP/IP Is Limited By Packet Loss

• The Floyd Rule:

Bmax = A*(L)^1/2 * MSS/RTT

MSS = max segment size, RTT = round trip timeL = error rate (packet loss as a fraction)A = AIMD constant (canonical value ~ 1.22

• Typical values of L are ~1% for LAN/WANMay be as much as 3-5% on mobile!

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.

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%

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

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 contentng of page content

Phase 1 Phase 2 Phase3

Load the base page object ANDCreate multiple parallel persistent connections to get the intransitive content

Deferred loading of page content

Phase 1 Phase 2

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/

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.

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

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

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

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

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

Implementations

Servers

• Netty• Nghttp2• Node-http2• Chromium• many more, including

SPDY implementations

Clients

• Chrome• Firefox• Opera• CURL• No IE

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)

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

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

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

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

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.

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

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

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

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

Sneak Preview! HTTP/3!

This is what the Internet will look like in 2020.

Thank You!

Daniel Austin

Interstellar Travel, Inc.

HTML5 DevConf

May 22, 2014

@daniel_b_austin

daniel@thestarsmydestination.com