h2) is the major revision of the network protocol used by the world wide web - meant to improve the perceived performance of loading web content
HTTP/1.1 was approved in 1999 - since then nothing has changed. Even slight delays make web users lose interest.
h2 powers google, facebook, twitter and wikipedia.
In 2009, HTTP/1.1 was a decade old.
Now loading a single web page often involved making hundreds of requests, slowing down the web
Many alternative protocols were introduced: * Roy Fielding’s WAKA * HTTP over SCTP * Google’s SPDY - making use of Chrome browser
In 2012: firefox , nginx and akamai implemented the protocol
In October 2012, the HTTP working group charted
SPDY as a starting point.
…in a few cases it was agreed that moving forward was more important than one person’s argument carrying the day, so we made decisions by flipping a coin. While this might seem like madness to some, to me it demonstrates maturity and perspective that’s rare
In December 2014,
HTTP/2 was submitted to the Internet Engineering Steering Council.
- Mark Nottingham
1. Evolution of HTTP#
- In 1930’s, Vannevar Bush, introduced the idea of linking data together contextually - memex
Hypertextwas coined in 1963 by Ted Nelson - a body of information interconnected in a complex way not conveniently represented or presented on paper. - docuverse or xanadu
- In 1989,
HTTPwas introduced by Tim Berners-Lee - he embraces hypertext: human readable information linked together in an unconstrained way and hypermedia: linking not bound to text.
HTTP/0.9 and HTTP/1.0#
- has a single method:
- No headers
- Could only fetch text - html
In 1996, RFC 1945, codified
- Response Codes
- Conditional Requests
- Content Encoding (Compression)
- More request methods:
- Inability to keep a connection open between requests
- Lack of a mandatory Host header
- Bare bones options for caching
- The protocol that has lived for 20 years
- Fixed the above
- The mandatory
Hostheader made virtual hosting possible - serving multiple sites form a single IP
- No longer needed to reestablish the TCP connection on every request
- Extenstion to Caching headers
- The Upgrade Header
- Range requests
- compression with transfer-encoding
- pipelining - allows client to send all requests at once but server had to respond in order - so it was a “mess up”
- An ecommerce site went far beyond the vision of the interwoven docuverse
SPDYintroduced: multiplexing, framing and header compression
- Enhance user perceived latency
- Address the head of line blocking problem
- Not require multiple connections to a server
- Retain the semantics (names of things) of
2. HTTP/2 Quickstart#
h2 server up and running:
- Get and install a webserver that speaks h2
- Get and install a TLS certificate
Getting a certificate#
A self-signed cert is not signed by a CA, it will generate warnings in a web browser
Using an Online Generator#
Use an online cert generator at sslchecker - becasue the private key is not generated in a secure environment you control they should only used for experimentation.
openssl genrsa -out key.pem 2048 openssl req -new -x509 -sha256 -key privkey.pem -out cert.pem -days 365 \ -subj "/CN=fake.example.org
- Easy automated and free Certificate Authority
wget https://dl.eff.org/certbot-auto chmod a+x certbot-auto ./certbot-auto certonly –webroot -w
- Your certificate’s private key:
- Your new certificate:
- The Let’s Encrypt CA chain:
- Your new cert and the chain all in one:
Running your Server#
nghttp2 is a useful tool for working with and debugging
sudo apt-get install nghttp2 ./nghttpd -v -d <webroot> <port> <key> <cert>
./nghttpd -v -d /usr/local/www 8443 \ /etc/letsencrypt/live/yoursite.com/privkey.pem \ /etc/letsencrypt/live/yoursite.com/cert.pem
Adding HTTP/2 to your Existing Webserver running Nginx#
The gist of it is to change:
listen 443 ssl;
listen 443 ssl http2;
3. How and Why we Hack the Web#
- Hundreds of objects per page
- Variability in networks
- Wide range of devices using the site
A consistent and fast web experience is a challenge
The Anotomy of a web page request#
2 parts: fetching and rendering
- Put URL in the queue to fetch
- Resolve the ip address of the hostname of the URL
- Open a TCP connection to the Host
- If HTTPS, intiiate and finish a TLS handshake
- Send the request for the page URL
- Receive response
- Parse Base HTML then trigger fetches for objects on the page
- If the critical objects on the page have been received - start rendering
- As additional objects are received - continue to parse and render until done
The above processes need to be done for every click - straining the network and devices.
Challenges on the network
- Latency - how long it takes for an ip packet to get from one point to another
- Round trip time (RTT) - double the latency
- bandwidth - Amount of data a connection can handle at a time
- DNS lookup - The internets phonebook - only needs to lookup once per hostname
- Connection time - three way TCP handshake. SYN -> SYN, ACK -> ACK
- TSL Negotation time - More round trips and processing time
Challenges on the server
- Time to First Byte (TTFB) - Time from when a browser sends a request to acquiring the first byte
- Content download time - Time to last byte (TTLB)
- Start Render Time - How quickly a client can put something on the screen for the user
- Document Complete (Page Load Time) - Time a page is considered
doneby the client
Internet movement to more:
- More bytes
- More objects
- More complexity
- More hostnames
- More TCP sockets
The problems with HTTP/1#
- Head of line blocking - a browser usually wants many objects from a particular host. Each asset needs its own connection - it doesn’t use a single connection. If any of those requests or responses have a problem - subsequent requests are blocked. Modern browsers open up to 6 connections per host.
- Inefficient use of TCP - built in congestion avoidance mechanisms. It is not the fastest but it is the most reliable. Central to this is the congestion window - the number of tcp packets a client can send before being acknowledged by the receiver.
An internet protocol packet is a series of bytes encapsulated in a dataframe. The most data one packet can transmit is 1460 bytes.
Sending one packet at a time is not terribly efficient. TCP has a slow start to feel out the network first to not congest it. The window size will be calculated during the slow start.
Modern operating systems commonly use an initial congestion window size between 4 and 10 packets, meaning only 5840 bytes can be sent before needing an acknowledgement.
Todays webpages average 2MB - 9 round trips are needed.
When packet loss occurs the congestion window is decreased.
- Fat message headers - no way to compress the message headers. Headers make up the majority of the bytes on a request. The median request header is 460 bytes. A page with 140 objects - that is 63 KB.
- Limited priorities
Web Performance Techniques#
- Steve Souders, in early 2000’s wrote High Performance Websites and Even faster websites
- In 2010, Google added web performance as a criteria in ranking
Majority of time is spent fetching assets and rendering the page - rather than the inital load.
Best Practices for Web Performance#
- Optimise DNS Lookups
- Optimise TCP Connections
- Avoid redirects
- Cache on the client
- Cache at the edge
- Conditional caching
- Compression and minification
- Avoid blocking CSS/JS
- Optimise Images
Optimise DNS Lookups#
- Limit unique hostnames
- Understand DNS resolution
- Leverage DNS prefetch eg.
<link rel="dns-prefetch" href="//ajax.googleapis.com">
Optimise TCP Connections#
- Leverage preconnect:
<link rel="preconnect" href="//fonts.example.com" crossorigin>- establishes a connection before it is needed
- Use early termination - leverage a CDN (Content Delivery Network)
- Use TLS best practices for optimising HTTPS
- Redirects trigger connections to additional hostnames
- Use rewrite rules if it is the same host
- Redirects are used in the dark art of SEO - sometimes tearing the bandaid off in one go is the best solution
Cache on the client#
- Nothing is faster than retrieving an asset from local cache
- It is also cheaper
- TTL (Time to live) - specifies the time to keep resources
- Static content like images and versioned content can be cached forever
- For CSS, JS and personalised objects cache twice the median session time
Client caching can be set through the
Cache at the Edge#
- Take strain off server infrastucture
- Only sharable assets should be cached at the edge. Not personalised items.
- Assets that are time sensitive should also be avoided
- Only give me the new asset if it has changed
- Use the
- Include an
Compression and minification#
- All textual context can be compressed
- Comments and space is removed
- Compression reduces size with
Avoid blocking CSS/JS#
- CSS tells the browser where to render content - clients therefore download it before rendering.
- It is good to place CSS resources early in the
- jS by default is fetched and prcoessed at the point in the HTML
If JS order is not critical and it must run before
onloadthen mafe use of: