Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

HTTP/2 turns 3 years old // Web Performance Meetup wao.io 20180612

202 views

Published on

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

Published in: Internet
  • Be the first to comment

HTTP/2 turns 3 years old // Web Performance Meetup wao.io 20180612

  1. 1. h2 turns 3 Felix Hassert Director Software Development & Operations Sevenval Technologies GmbH #WebPerfCGN @ sevenval.com Happy Birthday, HTTP/2!
  2. 2. A story of HTTP ● Problems ● Solutions ● New problems with solutions ● New solutions ● New new problems ● …
  3. 3. Back in the 90s – HTTP was the …
  4. 4. 3% 97% HTML Now we have Images/ Assets HTTP wasbuilt for this
  5. 5. HTTP/1.* wasn’t built for heavy media lifting
  6. 6. The Main Problem of HTTP/1: Inefficient Use of TCP
  7. 7. ● Connection handling (TCP Slow Start) ● Unidirectional messaging (head-of-line blocking)
  8. 8. Problem #1: TCP – Slow start Short lived HTTP connections end up here Warmed up TCP connections with full bandwidth
  9. 9. Problem #2: Head-of-line Blocking One outstanding response per connection No further requests on waiting connections
  10. 10. A lot of waiting High costs per request
  11. 11. HTTP/1 “Solutions”
  12. 12. 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
  13. 13. New Problems
  14. 14. 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)
  15. 15. Serving a Web page became complicated for developers (not servers)
  16. 16. HTTP/2 is designed to shift complexity from developers back to software
  17. 17. New solutions for old problems
  18. 18. 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
  19. 19. Multiplexing Data of multiple responses may be mixed. One connection is warmed up to bandwidth capacity.
  20. 20. 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
  21. 21. h1 Requests h2 requests 6 conns response blocks next request 1 conn almost in parallel
  22. 22. Obsolete “solutions” ● Multiple connections ● Domain Sharding ● Inlining ● Sprites ● Concat ○ (still compresses better)
  23. 23. Making a Web page is easy again! for developers
  24. 24. New new problems
  25. 25. We need TLS ● h2 is binary ● Avoid hops, bypass proxies ● Employ HTTPS everywhere
  26. 26. 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)
  27. 27. 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)
  28. 28. 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
  29. 29. TCP head-of-line blocking Bad TTFB? No! Downstream connection is blocked by images!
  30. 30. fast connection TCP head-of-line blocking Load Balancer h2 Server Client slow connection Buffer BufferBuffer empty always full blocked
  31. 31. 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
  32. 32. TCP head-of-line blocking Small delays in high prio content cause late interactivity First responses from varnish
  33. 33. 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.
  34. 34. 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 …
  35. 35. 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
  36. 36. 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
  37. 37. h2 waterfalls are tricky to read Response header frames are sent one after another. Data frames are not multiplexed.
  38. 38. h2 waterfalls are tricky to read typical h1 shape h1 shape hiding in h2
  39. 39. ● 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 …
  40. 40. 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?
  41. 41. Experiment: Sleepy Images ● Image response delayed by 200ms (varnish) ● Let JS slip in before image payloads block the buffer ● Favors FirstInteractive over SpeedIndex
  42. 42. Experiment: Sleepy Images Regular Sleepy images
  43. 43. Experiment: Sleepy Images Regular Sleepy images
  44. 44. …almost done
  45. 45. 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)
  46. 46. State of h2 Adoption
  47. 47. h2 Clients ● >95% on Desktop ● >77% Mobile ● >97% (Desktop & Mobile) in Germany :) Source: https://caniuse.com/#search=http2
  48. 48. h2 Clients
  49. 49. 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…
  50. 50. (19% of Domains) Source: https://discuss.httparchive.org/t/http-2-adoption/792/16 38% h2 Traffic
  51. 51. (70% of Page Views) Source: wao.io Traffic Data (Kibana) 80% h2 Traffic // Our servers
  52. 52. So, no reason not to use h2 :)

×