HTTP 2.0 and QUIC - Protocols of the (near) future

HTTP 1.1 forced both developers and browser vendors to invent different tricks in order to make sites to load and run faster. HTTP 2.0 and QUIC will provide many significant improvements overt HTTP 1.1.

In this talk I will give an introduction to both protocols and emphasize why are they so important for the Web development workflow and performance.

Transcript

1. HTTP 2.0 and QUIC protocols of the (near) future @ipeychev
2. Why a new version of HTTP protocol? 2.0
3. HTTP is used by the World-Wide Web since 1990 Browser sends request to the server Server responds GET /index.html HTTP/1.1 HTTP/1.1 200 OK
4. The number of requests per page increases HTTP Archive Top 100 sites data for 15.11.2010 - 1.10.2014
5. HTTP 1.1 has issues
6. Optional parts, like HTTP Pipelining It is very latency sensitive The specification is huge HTTP 1.1 issues and more...
7. Latency kills and bandwidth is not everything
8. Latency vs bandwidth Ilya Grigorik Developer Advocate, Google
9. What could be the solution?
10. HTTP pipelining? WikipediA The free Encyclopedia
11. HTTP pipelining
12. Why not HTTP Pipelining? The server must send its responses in the same order that requests were received So the entire connection remains first-in-first-out (FIFO) and Head-of-line (HOL) blocking can occur and more, like buggy proxy servers
13. In most browsers HTTP pipelining is disabled Or not implemented at all Browsers achieve multiplexing by opening multiple connections to servers As a result...
14. Developer workarounds
15. Image sprites 1 Sharding 2 Resource inlining 3 Developers invented workarounds
16. Concatenating files 4 Combo services 5 Preloading resources 6 Developers invented workarounds
17. Reducing cookie size 7 Using cookie-free domains 8 Using <link> instead of @import 9 Developers invented workarounds
18. Pack components into a multipart document
 (like email with attachments) 10 Developers invented workarounds
19. browser diet
21. Got tired?
22. Welcome to HTTP 2.0 and QUIC
23. HTTP 2.0 (draft 14)
24. HTTP 2.0 fixes issues in HTTP 1.1 without breaking the web
25. Using HTTP Upgrade mechanism HTTP How browser switches to HTTP 2.0 GET / HTTP/1.1 Host: server.example.com Connection: Upgrade, HTTP2-Settings Upgrade: h2c HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
26. HTTPS How browser switches to HTTP 2.0 ALPN Using Application Layer Protocol Negotiation extension
27. HTTP 2.0 features
28. HTTP 2.0 Features It is a binary protocol, not text one Browser and server exchange frames Each frame belongs to stream Streams are multiplexed, with priorities Server push
29. ONE connection to the server should be enough (not six connections per domain as most browsers do now) HTTP 2.0 Features
30. Frames
31. Frame format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (24) | +---------------+---------------+---------------+ | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) ... +---------------------------------------------------------------+
32. Frame types DATA Convey arbitrary data associated with a stream HEADERS Used to open a stream and carries name-value pairs PRIORITY Specifies the sender-advised priority of a stream RST_STREAM Allows abnormal termination of a stream SETTINGS Conveys configuration parameters that affect how endpoints communicate
33. Frame types PUSH_PROMISE Used to notify the peer endpoint in advance of streams the sender intends to initiate PING Measuring a minimal round-trip time from the sender; checks if a connection is still alive GOAWAY Informs the remote peer to stop creating streams on this connection WINDOW_UPDATE Used to implement flow control on each individual stream or on the entire connection. CONTNUATION Used to continue a sequence of header block fragments
34. Streams
35. Stream Logical, bi-directional sequence of frames.
36. Streams One single connection - multiple open streams.
37. Priorities and dependencies
38. Stream priority Each stream has priority Specified by the client (browser) Priority can be changed runtime
39. Stream dependencies A stream can depend on another one. A B C D
40. Stream dependencies A B C D A stream can depend on another one.
41. Headers
42. Header compression HTTP 2.0 is stateless protocol too The client still has to send data to the server The headers in HTTP 2.0 are compressed
43. Header compression Stateful Using a single compression context for the entire connection The algorithm is called HPACK (Header Compression for HTTP/2)
44. Header compression HPACK has been invented because of attacks like CRIME and BREACH
45. Server push (we did that for years)
46. Server push Server pre-emptively sends resources to a client, in association with a previous client-initiated request
47. Server push The client explicitly must allow it A client cannot push
48. HTTP/2 rulez!
49. QUIC protocol
50. QUIC Features Natural extension of SPDY/HTTP 2.0 research Multiplexing transport protocol Runs on top of UDP
51. Why not SCTP over DTLS? After all, SCTP provides (among other things) stream multiplexing And DTLS provides SSL quality encryption and authentication over a UDP stream
52. Why not SCTP over DTLS? Mainly because roughly 4 round trips are needed to establish an SCTP over DTLS connection In contrast, the goal of QUIC is to perform a connection establishment with zero RTT overhead
53. Goal: 0-RTT (round-trip time) connectivity overhead Has all the benefits of SPDY/HTTP 2.0 QUIC Features but...
54. QUIC Features No head-of-line blocking in QUIC!
55. QUIC Features Delay of only one packet causes the entire set of SPDY (aka HTTP/2) streams to pause. (Since TCP only provides a single serialized stream interface) In QUIC, when a single packet is lost, only one stream is being delayed
56. QUIC Features No head-of-line blocking in QUIC!
57. QUIC Features 100 ms 0 ms RTT Repeat connection New connection QUIC TCP + TLS 300 ms 200 ms RTT Repeat connection New connection
58. QUIC Encryption Comparable to TLS, with more efficient handshake Replay attack and IP Spoofing protection
59. QUIC Forward error correction
60. QUIC Internet connections persistence Communication channels are not defined by IP +Port but by an ID You leave a WiFi zone and entering a mobile one but the connection continues
61. Demo time
63. https://http2rulez.com Open Source platform for testing different optimization strategies for HTTP 2.0 Same content, served via HTTP, HTTPS, SPDY and HTTP/2 (No QUIC endpoint yet) View Page Load Time for each page
64. HTTPS Waterfall HTTPS waterfall
65. HTTPS connection view
66. HTTP/2 waterfall without server push
67. HTTP/2 connection view without server push
68. HTTP/2 waterfall with server push
69. HTTP/2 connection view with server push
70. Wrap up
71. Wrap up Remember the workarounds we do to speed up our sites?
72. Wrap up Ask yourself
73. Wrap up How HTTP 2.0 will affect the way YOU develop and optimize Web applications?
74. Thank you! ipeychev