HTTP/2 for Front-End Developers
What's Wrong with HTTP/1?
1. Bad Network Utilisation
- Browsers use 4-8 connections for HTTP/1
- ... but modern Web pages have 100s of assets to load
- Head of Line Blocking is still a problem
- ... so browsers still need to guess what to do
- Meanwhile, TCP behaves really badly when you use multiple connections...
img[0-3].etsystatic.com - 25 images
2. Verbose Headers
- 1000+ bytes of request headers not uncommon
- Much of this data is redundant
- Lots of large requests at the start of a connection is slow
HTTP/2 in One Slide
- A Fully Multiplexed, Binary Protocol…
- One connection per origin - Better network utilisation
- Browsers don't have to guess when/where to send requests
- …with Header Compression…
- Many requests in one packet!
- …and Server Push.
- Put a response in the browser cache before it knows it needs it.
Theme: reduce the overhead of HTTP requests
Same, but different.
You can use the same HTTP APIs, headers, methods, and status codes, but to get the most out of the protocol, there are a few things to tweak, tune and consider.
You Might Need New URLs (2)
Spreading traffic to multiple hosts hurts perf and HTTP/2.
- "Cookieless" domains
- Separate CDN hosts - e.g.,
Why? Increased chance of congestion events, worse header compression.
You can use connection coalescing if DNS and cert agree.
Recommendation: There Can Be Only One (hostname).
HTTP/1 Content “Optimisations”
Spriting, inlining and concatenation are all techniques to reduce the number of HTTP requests.
In HTTP/2, they can hurt your performance:
- Cache inefficiency due to coarse granularity ∴ expensive invalidation
- Unnecessary download because of unused data ∴ opportunity cost
Recommendation: Think about a strategy to de-optimise.
Think about Prioritisation…
In HTTP/1, browsers are responsible for deciding request priority and ordering - and sometimes they get it wrong.
In HTTP/2 it's up to the server (thanks to multiplexing).
- Which responses do I send back first?
- How do I interleave responses?
…Because Prioritisation Works.
Recommendation: Look for APIs, data and studies.
In principle, push can save you a round trip - putting something in cache before the browser knows it needs it.
In practice, no one is quite sure how to think about push yet.
- Genuinely new
- Most implementations don't have APIs
- Performance benefits are highly situational
Recommendation: Experiment and gather data
HPACK is coarse-grained; it works on an an entire header.
- One character changes in your
Cookie? No compression for you.
- Weird platform-specific
X-request-ID? No compression for you.
- Fancy header that shows how many ms it took to generate the response? No compression for you. Probably.
SETTINGS_HEADER_TABLE_SIZE is 4k.
Recommendation: Reduce header variability.
FYI: TLS Requirements
- TLS 1.2+
- Perfect Forward Secrecy
- No renegotiation
- No compression
- Server Name Indication
- Application Layer Protocol Negotiation
Tune TLS Performance
- Use Session Tickets ∵ one RT
- Keep cert chain size small ∵ conn setup
- Do OCSP Stapling ∵ one less external service
- Keep record size small ∵ interactivity
Client Certificates and HTTP/2
HTTP/2 doesn't support client certificates, because no renegotiation.
- H2 has a
HTTP_1_1_REQUIRED error code to force downgrade.
- H2-specific solutions in the works.
HTTP/2 thrives with long-lived connections.
- Better TCP goodput / utilisation
- Better header compression
Recommendation: Architect and configure for long-lived connections.
DNS Load Balancing
HTTP/1 DNS load balancing leverages short connections.
GOAWAY allows you to tear the the conn gracefully, so you get a new DNS lookup.
ALTSVC will give a better way to balance traffic.
- Sort-of DNS
CNAME inside HTTP
- "Start a connection to that
host:port, and when it's authenticated and ready, treat it as this origin."
HTTP/2 removes application-layer issues, but TCP congestion control brings its own.
- Set IW=10 - in Linux 2.6.39 / 3.0
- Congestion Control - look at CUBIC, Proportional Rate Reduction & others
net.ipv4.tcp_slow_start_after_idle = 0
Choose a Good Server
- …support TLS session tickets, OCSP stapling, reduced record sizes?
- …use TCP_NOTSENT_LOWAT for better interactivity?
- …support TCP Fast Open?
- …offer an API for prioritisation?
- …for Server Push?
Just Getting Started.
- UDP-based Applications (e.g., QUIC)