Demystifying HTTP/2

A primer

Ian Ring | Netsuite Inc

Good news

The things you care about probably haven't changed

  • URLs
  • GET, POST, PUT etc
  • Cookies
  • Headers
  • Status codes


As a web programmer, HTTP/2 should not disrupt you at all

Will HTTP/2 replace HTTP/1?

Yes, but it will happen very slowly.

Big players are leading the adoption.

What browsers can make HTTP/2 requests?

  • Chrome
  • Chrome for IOS
  • Firefox v36
  • Internet Explorer 11 on Windows 10
  • Microsoft Edge
  • Opera
  • Safari 9

How does a browser know it can make an HTTP/2 request?

Browser sends a "HTTP2-Settings" header with some info in it

If the server can speak HTTP/2, it will respond with Status 101 Switching Protocols

It's all described in the HTTP/2 spec.

Why change HTTP?

The World Wide Web has changed

HTTP/1 is inefficient

It creates a new TCP/IP connection for each URL resource

Silly things we do

to overcome HTTP inefficiency

Spriting

Data Inlining

Domain Sharding

Asset Concatenation

... all so we can avoid making lots of HTTP requests

Not a inefficiency of TCP/IP

TCP/IP merely sends zeoes and ones from one machine to another

It's an inefficiency of HTTP/1

Because the protocol defines requests and responses

Problem Solved:

SPDY

Developed at Google, now used by many large-scale services

SPDY is basically the first draft of HTTP/2

SPDY is being used right now

concurrently loaded assets from facebook

A contrived example

with HTTP/1: 31s to load

Loading happens in concurrency blocks of 6 assets each

source: Mattias Geniar

30 seconds later...

source: Mattias Geniar

with HTTP/2: 1.7s to load

A single TCP/IP stream, multiplexed.

source: Mattias Geniar

1.5 seconds later...

source: Mattias Geniar

Summary

HTTP/1HTTP/2
Single requests Multiplexing

With HTTP/1, it was good to do:
cdn1.domain.com, cdn2.domain.com, ...

In HTTP/2, Domain sharding hurts performance, doesn't make it better!

It is better to get all your assets through the same TCP connection.

  • only 1 DNS lookup
  • only 1 TCP/IP connection
  • only 1 TCP "slow start"

The TCP "slow start"

Also known as the "congestion avoidance algorithm"

Packet data transfer over time, downloading a 1MB file. Note that it is not linear.

source: Jeremy Stretch

I/O Speed vs Time for a 1MB download

source: Jeremy Stretch

This ramp-up happens for every single HTTP/1 request!

In HTTP/2, all those messages happen in the same TCP/IP connection, which means they can all come in at full speed

Summary

HTTP/1HTTP/2
Single requests, with TCP slow start Multiplexing, full speed

HTTP/2 is binary

Not ASCII, and not readable.

Why binary?

  • more compact
  • ambiguous whitespace handling
  • ambiguous capitalization
  • ambiguous line endings
  • easier, faster to parse


HTTP/1 defines four different ways to parse a message!

Summary

HTTP/1HTTP/2
Single requests, with TCP slow start Multiplexing, full speed
Plaintext Binary

HTTP/2 demands TLS, aka SSL

Not by definition, but by implementation

The protocol DOES NOT require TLS encryption

HTTP/2 demands TLS, aka SSL

SSL was required by SPDY

Some implementations have stated that they will only support
HTTP/2 when it is used over an encrypted connection

Currently no browser supports HTTP/2 unencrypted

Summary

HTTP/1HTTP/2
Single requests, with TCP slow start Multiplexing, full speed
Plaintext Binary
SSL optional, often used sparingly SSL is required (by implementations, not by the protocol)

Header Compression

Great for sites with big cookies.

Headers also tend to be very repetitive.

SPDY compressed its headers

But... the manner in which it was done presents a security risk.

CRIME ("Compression Ratio Info-leak Made Easy")

Therefore SPDY - despite being SSL encrypted - must not be used to send secret information in its cookies.

The new way to compress headers is called

HPACK

... and it's safe from CRIME.

HTTP/2 uses HPACK to compress headers

Summary

HTTP/1HTTP/2
Single requests, with TCP slow start Multiplexing, full speed
Plaintext Binary
SSL optional, often used sparingly SSL is required (by implementations, not by the protocol)
Compression (gzip) is applied to the entire packet Safe compression of headers

Server Push

Why?

Pushed assets are already loading before the HTML is finished parsing

How?

There are working examples available for NodeJS

The mechanics of doing this on other stacks is still unclear

Summary

HTTP/1HTTP/2
Single requests, with TCP slow start Multiplexing, full speed
Plaintext Binary
SSL optional, often used sparingly SSL is required (by implementations, not by the protocol)
Compression is applied to the entire packet Selective compression of headers
Upon request Server push

HTTP/2 can change its mind

If a HTTP/1 client makes a request and then discovers the response isn't needed, it needs to close the connection to save bandwidth.

HTTP/2 can cancel a download without breaking the TCP connection

Summary

HTTP/1HTTP/2
Single requests, with TCP slow start Multiplexing, full speed
Plaintext Binary
SSL optional, often used sparingly SSL is required (by implementations, not by the protocol)
Compression is applied to the entire packet Selective compression of headers
Upon request Server push
Stop download = close connection Can stop without closing

Just The Bad Parts

  • Not many webservers know how to serve it yet
  • Supporting HTTP/1 and HTTP/2 at the same time is hard:
    What is good for HTTP/1 is bad for HTTP/2, and vice versa
  • Critics complain: not enough was changed

HTTP/2: RFC 7540

HPACK: RFC 7541

Thanks

@ianring

http://ianring.com