Presentation by Felix Hassert about HTTP/2 at the #CGNWebPerf Meetup in Cologne at Sevenval. Date: 12.06.2018

1. h2 turns 3
Felix Hassert
Director Software Development & Operations
Sevenval Technologies GmbH
#WebPerfCGN @ sevenval.com
Happy Birthday, HTTP/2!

2. A story of HTTP
● Problems
● Solutions
● New problems with solutions
● New solutions
● New new problems
● …

3. Back in the 90s – HTTP was the …

4. 3% 97%
HTML
Now we have
Images/
Assets
HTTP wasbuilt for this

6. HTTP/1.*
wasn’t built for heavy media lifting

7. The Main Problem of HTTP/1:
Inefficient Use of TCP

8. ● Connection handling (TCP Slow Start)
● Unidirectional messaging (head-of-line blocking)

9. Problem #1: TCP – Slow start
Short lived HTTP
connections end
up here
Warmed up TCP
connections with
full bandwidth

10. Problem #2: Head-of-line Blocking
One outstanding response per connection
No further requests on waiting connections

11. A lot of waiting
High costs
per request

12. HTTP/1 “Solutions”

13. Problem Solution
Short lived connections
suffering from TCP slow start
Connection Keep-Alive
HTTP head-of-line blocking 6 connections per host
Domain Sharding
(= more connections)
Requests are expensive Inlining
Concatenation & Sprites

14. New Problems

15. New Problems
● Web pages need a build system (Sprites, Bundles)
● Web pages need run-time handling (Inlining)
● Inlining vs Caching (repeated sends, critical path)
● Concat vs Caching (one change, all new)
● More domain names, more certificates, more link rewriting
● (No problem with keep-alive, though)

16. Serving a Web page
became complicated
for developers (not servers)

17. HTTP/2
is designed to shift complexity
from developers back to software

18. New solutions
for old problems

19. HTTP/2 solution
Bidirectional
Messaging &
Multiplexing
No head-of-line blocking
One connection per host
Mitigates TCP slow start
HPACK Reduces cost of requests
Bonus: Server Push Utilizes initial server think time

20. Multiplexing
Data of multiple responses may be mixed.
One connection is warmed up to bandwidth capacity.

21. HPACK // Header compression
● Requests become small & cheap
● Many requests fit in one TCP segment
● “Parallel” requests in one connection (not really)
● Saves RTT, especially for slow uploads (“ADSL”)
$ h2load --h1 https://example.test.stage.wao.io/ -n50
33.14KB headers // min 3 RTT
$ h2load https://example.test.stage.wao.io/ -n50
10.19KB headers (space savings 68.94%) // 1 RTT

22. h1 Requests h2 requests
6 conns
response
blocks next
request
1 conn
almost in
parallel

23. Obsolete “solutions”
● Multiple connections
● Domain Sharding
● Inlining
● Sprites
● Concat
○ (still compresses better)

24. Making a Web page
is easy again!
for developers

25. New new problems

26. We need TLS
● h2 is binary
● Avoid hops, bypass proxies
● Employ HTTPS everywhere

27. TLS Problems
● Certificates for every domain: buy (or automate Let’s
Encrypt)
● Make sure it is used! Redirects, HSTS
● Fix all mixed content (3rd party, too!): change URLs, use CSP
(This may be the major pain point when migrating to h2)

28. Request Bursts
● h1 HOL and 6 connections == “cooperative throttling”
● Without inlining/sprites/bundles -> even more requests
● Coming in at the same time
● Be prepared for 50+ simultaneous requests from one client
● Protect your application servers
● Employ a reverse proxy (e.g Varnish)

29. More Connection Problems
● Connections need a looooong life-time
● Packet loss severely impacts h2 (Slow start prob is back!)
● h2 is intended only for the last mile (client-end)
● De-couple TLS/h2 from application server
● Avoid TCP balancing h2

30. TCP head-of-line blocking
Bad TTFB?
No!
Downstream
connection is
blocked by images!

31. fast
connection
TCP head-of-line blocking
Load
Balancer
h2
Server
Client
slow
connection
Buffer BufferBuffer
empty always full blocked

32. TCP head-of-line blocking breaks Multiplexing
● Requests come in at once
with different priorities (CSS: highest, images: low)
● TCP Buffers are serialized: FIFOs
● The fastest responses fill up the buffer (Cache Hits)
● Important content may get delayed

33. TCP head-of-line blocking
Small delays in high
prio content cause
late interactivity
First responses from
varnish

34. h2 waterfalls are tricky to read
TTFB is the first byte
received by the client.
The server may have
sent it much earlier.
All responses were
generated in the
same second.

35. To multiplex or not to …?
● Most file formats are not usable while in-flight
● JS is executed after download
● CSS is applied after download
● Font is used after …

36. To multiplex or not to …
● Is multiplexing responses useless?
● No!
● Progressive JPEG is rendered in-flight!
○ Hello, Speed Index!
○ (There is no “progressive WebP”)
● Response Header Frames are often multiplexed

37. Multiplexed Response Header Frames
H1 H2 H3 D1 D1 D1 D1 D2 D2
Serialized Response Data Chunks
but no “parallel” download
fast TTFB (for assets) Server

38. h2 waterfalls are tricky to read
Response
header frames
are sent one
after another.
Data frames
are not
multiplexed.

39. h2 waterfalls are tricky to read
typical h1
shape
h1 shape
hiding in h2

40. ● Multiplexing is bad
if data is only usable when complete (TTLB)
● Most servers tend not to multiplex
● Exception: h2o server multiplexes more!
● What about Progressive JPEG? :(
To multiplex or not to …

41. WebPageTest and h2
● SpeedIndex favors Multiplexing for JPEG hero images
● SpeedIndex favors Serializing for WebP heros (TTLB)
● FirstInteractive favors Multiplexing/ Prioritization JS before img
● Load Time favors Serializing
● Packet Loss favors HTTP/1 :)
● What metric do you want to fake today?

42. Experiment: Sleepy Images
● Image response delayed by 200ms (varnish)
● Let JS slip in before image payloads block the buffer
● Favors FirstInteractive over SpeedIndex

43. Experiment: Sleepy Images
Regular Sleepy images

44. Experiment: Sleepy Images
Regular
Sleepy images

45. …almost done

46. Takeaways
● Requests are cheap
● Bytes are still expensive (TCP HOL, Multiplexing Issues)
● Compress Images, lazy load
● Multiplexing needs work (from Browsers & Servers)
● TCP setup can be tricky (next solution: QUIC)

47. State of h2 Adoption

48. h2 Clients
● >95% on Desktop
● >77% Mobile
● >97% (Desktop & Mobile) in Germany :)
Source: https://caniuse.com/#search=http2

49. h2 Clients

50. h2 Servers
● h2o (1.0, 03/2015)
● nghttp2 (1.0, 05/2015)
● Nginx (1.9.5, 09/2015)
● Apache mod_http2 (2.4.17, 10/2015)
● Varnish + Hitch (5.0, 09/2016)
● haproxy (1.8, 11/2017)
● MS IIS (10.0, 11/2016)
● CDNs…

51. (19% of Domains)
Source: https://discuss.httparchive.org/t/http-2-adoption/792/16
38%
h2 Traffic

52. (70% of Page Views)
Source: wao.io Traffic Data (Kibana)
80%
h2 Traffic // Our servers

53. So, no reason not to use h2 :)