HTML5, HTTP/2, and You
V 1.1
Daniel Austin
Interstellar Travel, Inc.
HTML5 DevConf
May 22, 2014
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
Top Related