Try MyIntelliAccount Cloud Accounting Software As A Service Solution Risk Fre...
Next generation web protocols
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.
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
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.
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
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
Notas del editor
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!
There is no minor number version, and 2.0 is incorrect.
Corgrats to the HTTPbis team. Amazing!
reduced perception of latency
I don’t know what that means, cut it
Note: this text was removed from the final RFC.
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%!
Sally Floyd is a retired computer science professor at Berkeley and a prominent TCP researcher.
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.
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!
SSL Resumption still works, etc.
Win Some Lose Some
TLS has performance problems of its own
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
At least half of the top 10 websites by traffic are using HTTP/2.
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