HTTP/2 for Front-End Developers

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...

2. Verbose Headers

• 1000+ bytes of request headers not uncommon
• E.g., Cookies, Referers
• Much of this data is redundant
• Lots of large requests at the start of a connection is slow

HTTP/2 in One Slide

1. A Fully Multiplexed, Binary Protocol…
   • One connection per origin - Better network utilisation
   • Browsers don't have to guess when/where to send requests
2. …with Header Compression…
   • Many requests in one packet!
3. …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.

All major browsers require encrypted connections for HTTP/2.
Practically speaking, this means https://

Recommendation: Start transitioning to HTTPS now.

You Might Need New URLs (2)

Spreading traffic to multiple hosts hurts perf and HTTP/2.

• Sharding
• "Cookieless" domains
• Separate CDN hosts - e.g., image-cdn.example.com

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).

Decisions like:

• Which responses do I send back first?
• How do I interleave responses?

…Because Prioritisation Works.

"first-paint times [with #http2] are reduced by about 30% when compared to HTTP/1.1 or SPDY/3.1." http://t.co/yOC4PKve7p

— Daniel Stenberg (@bagder) June 16, 2015

Recommendation: Look for APIs, data and studies.

Server Push

In principle, push can save you a round trip - putting something in cache before the browser knows it needs it.

Header Compression

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.

Default SETTINGS_HEADER_TABLE_SIZE is 4k.

Recommendation: Reduce header variability.

FYI: TLS Requirements

HTTP/2 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.

DoS Protection

• Bad news: HTTP/2 involves more state, e.g.,
  • multiple outstanding requests
  • flow control windows
  • compression context
• Good news: HTTP/2 lets you bound commitment with SETTINGS
• There are some tricky bits - e.g., CONTINUATION

Recommendation: ask your vendor/project for h2 support!

Hyper-Persistent Connections

For HTTP/1 74% of our active connections carry just a single transaction - persistent connections just aren't as helpful as we all want. But in HTTP/2 that number plummets to 25%.

Connection Timeouts

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.
• Soon, 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."

TCP Configuration

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
• Set net.ipv4.tcp_slow_start_after_idle = 0

Choose a Good Server

Do you:

• …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?

Some tools to help

• Wireshark - requires NSS Keylogging
• Curl
• h2i
• Chrome devtools - chrome://net-internals/#spdy

Just Getting Started.

• TLS/1.3
• UDP-based Applications (e.g., QUIC)
• HTTP/3

More

• HTTP/2 home - https://http2.github.io/
• HTTP/2 explained - http://daniel.haxx.se/http2/
• High Performance Browser Networking - https://hpbn.co/http2
• TLS Performance - https://istlsfastyet.com/
• This talk - https://www.mnot.net/talks/h2fe/