HTML5, HTTP2, and You 1.1


Published on

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

Published in: Internet, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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!
  • reduced perception of latency

    I don’t know what that means, cut it
  • 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%!
  • 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.
  • Sally Floyd is a retired computer science professor at Berkeley and a prominent TCP researcher.
  • 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!
  • Both are formally proposed extensions to TLS.
  • SSL Resumption still works, etc.
  • 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
  • Chrome supports websockets over SPDY/4
    The WebSocket API should remain stable regardless of how the underlying framing works
    Perhaps as WS 2.0?

  • I think we can see some problems with this proposal, and I expect it will undergo significant revision as the spec progresses. In particular:
    What if there are multiple ‘trusted proxies’?
    Each ‘clear’ proxy increases the overall risk
    Would international users be allowed/denied access to various trusted intermediates? What if the Chinese gov’t for instance decides not to allow
    Users to use trusted proxies in the US?
    Every intermediate proxy in the chain is a very sweet exploit target
    The encryption surface becomes huge due to use of a single cert at given URI
  • 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
  • QUIC does not use large datagrams however.
  • That’s a good thing!
  • I understand they are already hard at work on this. Back to simplicity!
  • HTML5, HTTP2, and You 1.1

    1. 1. HTML5, HTTP/2, and You V 1.1 Daniel Austin Interstellar Travel, Inc. HTML5 DevConf May 22, 2014
    2. 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. 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. 4. No Web Without HTTP WWW HTML (Structure) URI (Addresses) HTTP (Transport)
    5. 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. 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. 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. 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. 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. 10. Bandwidth, Latency, and All That
    11. 11. More Bandwidth? Less Latency!
    12. 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. 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. 14. Illustrating Multiplexing Source:
    15. 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. 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. 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. 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. 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. 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:
    21. 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. 22. ALPN Example [ 0.013] HTTP Upgrade request GET / HTTP/1.1 Host: 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. 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. 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. 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. 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. 27. Implementations Servers • Netty • Nghttp2 • Node-http2 • Chromium • many more, including SPDY implementations Clients • Chrome • Firefox • Opera • CURL • No IE
    28. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 38. Sneak Preview! HTTP/3! This is what the Internet will look like in 2020.
    39. 39. Thank You! Daniel Austin Interstellar Travel, Inc. HTML5 DevConf May 22, 2014 @daniel_b_austin