RFC 7540 was ratified over 2 years ago and, today, all major browsers, servers, and CDNs support the next generation of HTTP. Just over a year ago, at Velocity (https://www.slideshare.net/Fastly/http2-what-no-one-is-telling-you), we discussed the protocol, looked at some real world implications of its deployment and use, and what realistic expectations we should have from its use.
Now that adoption is ramped up and the protocol is being regularly used on the Internet, it's a good time to revisit the protocol and its deployment. Has it evolved? Have we learned anything? Are all the features providing the benefits we were expecting? What's next?
In this session, we'll review protocol basics and try to answer some of these questions based on real-world use of it. We'll dig into the core features like interaction with TCP, server push, priorities and dependencies, and HPACK. We'll look at these features through the lens of experience and see if good practice patterns have emerged. We'll also review available tools and discuss what protocol enhancements are in the near and not-so-near horizon.
7. % of overall requests on Fastly’s network (2017)
%ofrequests
0%
25%
50%
75%
100%January
February
M
arch
April
M
ay
June
July
August
Septem
ber
O
ctober
N
ovem
ber
D
ecem
ber
HTTP/2
11. Revisiting HTTP/2
• Core concepts
• Major features
- HTTP and TCP
- Server push
- Priorities and dependencies
- HPACK
• Has anything changed? Have we learned anything?
• What’s next?
16. connection
• A single, long lasting connection
• Theoretically, this means better congestion
management between peers
• TLS/ALPN
• Connection reuse across domains
18. Streams
• Virtual communication channels
- Translate roughly to a request/response exchange
- Either side can initiate a stream
• Stream IDs
- Client: odd; server: even; 0: reserved
- Each ID must be larger than the last
- Cannot be reused
19. +--------+
send PP | | recv PP
,--------| idle |--------.
/ | |
v +--------+ v
+----------+ | +----------+
| | | send H / | |
,------| reserved | | recv H | reserved |------.
| | (local) | | | (remote) | |
| +----------+ v +----------+ |
| | +--------+ | |
| | recv ES | | send ES | |
| send H | ,-------| open |-------. | recv H |
| | / | | | |
| v v +--------+ v v |
| +----------+ | +----------+ |
| | half | | | half | |
| | closed | | send R / | closed | |
| | (remote) | | recv R | (local) | |
| +----------+ | +----------+ |
| | | | |
| | send ES / | recv ES / | |
| | send R / v send R / | |
| | recv R +--------+ recv R | |
| send R / `----------->| |<-----------' send R / |
| recv R | closed | recv R |
`----------------------->| |<----------------------'
+--------+
send: endpoint sends this frame
recv: endpoint receives this frame
H: HEADERS frame (with implied CONTINUATIONs)
PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
ES: END_STREAM flag
R: RST_STREAM frame
21. GET /thing HTTP/1.1
Host: www.example.com
User-Agent: Some_user_agent
HTTP/1.1 200 OK
Server: some_server
Content-Type: text/html
Content-Length: 1000
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html
Request Response
22. GET /thing HTTP/1.1
Host: www.example.com
User-Agent: Some_user_agent
HTTP/1.1 200 OK
Server: some_server
Content-Type: text/html
Content-Length: 1000
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html
Request Response
HEADERS
23. GET /thing HTTP/1.1
Host: www.example.com
User-Agent: Some_user_agent
HTTP/1.1 200 OK
Server: some_server
Content-Type: text/html
Content-Length: 1000
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html
HEADERS
HEADERS
Request Response
24. GET /thing HTTP/1.1
Host: www.example.com
User-Agent: Some_user_agent
HTTP/1.1 200 OK
Server: some_server
Content-Type: text/html
Content-Length: 1000
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html html html
html html html html html
DATA
DATA
DATA
DATA
DATA
DATA
HEADERS
Request Response
HEADERS
25. DATA Carries request or response data
HEADERS Carries request/response headers/trailers; can initiate a stream
PRIORITY Indicates priority of a stream
RST_STREAM Terminates a stream
SETTINGS Defines parameters for the connection only
PUSH_PROMISE Signals peer for server push
PING Maintenance frame for checking RTT, connection, etc
GOAWAY For shutting down a connection
WINDOW_UPDATE Frame responsible for flow control adjustments
CONTINUATION Extends a HEADERS frame and can carry more headers
26. DATA Carries request or response data
HEADERS Carries request/response headers/trailers; can initiate a stream
PRIORITY Indicates priority of a stream
RST_STREAM Terminates a stream
SETTINGS Defines parameters for the connection only
PUSH_PROMISE Signals peer for server push
PING Maintenance frame for checking RTT, connection, etc
GOAWAY For shutting down a connection
WINDOW_UPDATE Frame responsible for flow control adjustments
CONTINUATION Extends a HEADERS frame and can carry more headers
27. TCP
TLS
TLS Record
Header: valuern
Header: valuern
Header: valuern
rn
Body Body Body Body Body
Body Body Body Body Body
Body Body Body Body Body
Body Body Body Body Body
HTTP/1
28. HTTP/2 Frame
TCP
TLS
TLS Record
HTTP/2 Frame
HTTP/2 Frame
…
Stream ID
Stream ID
Stream ID
TCP
TLS
TLS Record
Header: valuern
Header: valuern
Header: valuern
rn
Body Body Body Body Body
Body Body Body Body Body
Body Body Body Body Body
Body Body Body Body Body
HTTP/1 HTTP/2
69. Takeaways (then)
• Despite the experiment flaws, performance
benefits are less than clear cut, out of the box
• Seemed best:
- Not listen to anyone!
- Try for yourself
91. Origin frame
• List of domains eligible for coalescing
- Cert still needs to match
• Empty frame signals no coalescing
- Fall back to SNI
• Obviates DNS lookups for listed domains
92. Origin frame
• List of domains eligible for coalescing
- Cert still needs to match
• Empty frame signals no coalescing
- Fall back to SNI
• Obviates DNS lookups for listed domains
93. Origin frame
• List of domains eligible for coalescing
- Cert still needs to match
• Empty frame signals no coalescing
- Fall back to SNI
• Obviates DNS lookups for listed domains
96. h2 and TCP
• Performance benefits?
- Jury’s still out
- BBR helps, but pros/cons aren’t totally clear yet
- It’s still best to figure out what’s best for you on your
own!
• The context of a connection is being relied on
more and more
102. What to push?
• A replacement for inlining
- All the RTT-saving benefits + caching
• Google paper:
- https://docs.google.com/a/fastly.com/drawings/d/
1mWwY_MeNAjzDRCF0uT97KgN0lh_jX79a53X6iOuH_Is/pub?w=2330&h=1350
• Facebook:
- https://www.facebook.com/atscaleevents/videos/1775942979345465/
• TTFMP:
- https://youtu.be/4pQ2byAoIX0
136. Pushing for push
• Is the 1RTT worth the complexity?
• 103 to the browser gives us the same benefit
as the most important use-case
• Cache digests may still be useful, regardless
of push
138. Prioritization basics
• Address possible contention because of all the
concurrency
• Stream weights
• Dependency
• HEADERS and PRIORITY frames
• It’s only a “suggestion”
139. Example 1
• A gets ¾ of resources
• B gets ¼ of resources
*
A
12
B
4
12/(12+4) 4/(12+4)
140. Example 1
• A gets ¾ of resources
• B gets ¼ of resources
*
A
12
B
4
12/(12+4) 4/(12+4)
141. Example 2
• D gets all resources
• After D is done, C gets all resources
• Weights are meaningless since there are
no siblings
*
D
1
C
8
142. Example 3
• D gets all resources
• After D is done, C gets all resources
• After C is done:
- A gets ¾ of resources
- B gets ¼ of resources
*
D
1
C
8
A
12
B
4
143. Example 4
• D gets all resources
• After D is done:
- C gets ½ of resources
- E gets ½ of resources
• After C is done:
- A gets ¾ of C’s ½ of resources
- B gets ¼ of C’s ½ of resources
*
D
1
C
8
A
12
B
4
E
8
153. HPACK (RFC 7541)
• Addresses the header bloat problem
• Two primary mechanisms
- All headers (name=value) are Huffman encoded
- Indexed tables at each peer
154. Tables
• Static table
- Defined by the RFC, never changes
• Dynamic table
- Built during the connection and maintained by each
side
- FIFO
164. HPACK - things to know
• Default size is 4K
- For entire dynamic table
- Site-wide headers proposal:
• https://mnot.github.io/I-D/site-wide-headers/
• Compression context is set per connection
- New connection starts with blank dynamic table
• Can’t turn it off
• Can be an attack vector:
- https://www.imperva.com/docs/Imperva_HII_HTTP2.pdf
167. HPACK - things to know
• Default size is 4K
- For entire dynamic table
- Site-wide headers proposal:
• https://mnot.github.io/I-D/site-wide-headers/
• Compression context is set per connection
- New connection starts with blank dynamic table
• Can’t turn it off
• Can be an attack vector:
- https://www.imperva.com/docs/Imperva_HII_HTTP2.pdf
190. The promise of QUIC
• Low latency connection setup
- 0RTT (with TLS 1.3)
• UDP
- Addresses TCP’s head of line blocking in h2
- More flexible congestion avoidance algorithms
- “rich signaling for congestion control and loss recovery”
• Everything authenticated and encrypted
• Mitigating middle box tomfoolery
• Connection migration and NAT rebinding
191. Some QUIC reading
• https://dl.acm.org/citation.cfm?id=3098842
• https://quicwg.github.io/
• https://github.com/quicwg
• And a video: https://vimeo.com/227461189
192. Questions
• Has much changed?
• Do we still have a lot to learn?
• Do we still have a lot to do?
• QUIC will fix everything, right?