Recent Advances in HTTP, controlling them using ruby

Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
Recent Advances in HTTP,
controlling them using ruby
DeNA Co., Ltd.
Kazuho Oku

Who am I
 lead developer of H2O HTTP/2 server
⁃ one of the most sophisticated HTTP/2 impl.
⁃ initial public release: 2014/10 (license: MITL)
⁃ used by Fastly, etc.
 author of Cache-Digests Internet Draft
⁃ considered as an essential work for HTTP/2 push
 works at DeNA Co., Ltd.
 also developer of: Q4M, Starlet, pisojson, ...
2Recend Advances in HTTP2, controlling them using ruby

Current State of HTTP

Why use HTTP/2?
 latency has become the bottleneck of the Web
 HTTP/2 to conceal latency by raising concurrency
⁃ 6 concurrent requests in HTTP/1
⁃ ~100 in HTTP/2

Current state of HTTP
 HTTP/2 (RFC 7540) released on May 2015
1: https://github.com/HTTPWorkshop/workshop2016/blob/master/talks/http2-review-data.pdf
45
28
37
41
18
31
0% 20% 40% 60% 80% 100%
2015/7
2016/7
# of transactions by Firefox1
HTTP HTTPS (H1) HTTPS (H2)

Key features of HTTP/2
 header compression (HPACK)
 multiplexing & prioritization
 push

Header compression
 working well
 according to Mozilla1:
⁃ median – 90% reduction
⁃ 80th percentile – 75% reduction
⁃ 90th – 10% reduction

Multiplexing & prioritization
 HTTP/2 multiplexes responses into one TCP conn.
⁃ client gives hint for prioritization
⁃ server uses the hint to schedule the responses
 but some client-server pairs don’t do it right

Push
 positive reports:
⁃ “20-30% speedup on page render time”2
 negative comments:
⁃ many unnecessary pushes (47% are reset2)
⁃ increased render time in anti-patterns3
⁃ “consider preload instead of push”3
 push from edge
⁃ how?
2: https://github.com/HTTPWorkshop/workshop2016/blob/master/talks/server-push.pdf
3: https://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXjqKGsCVNYHyLEXIxYMv0/edit

Fixes?

Flow of an ideal HTTP transaction
 respond to high-priority requests
immediately
 send resources in right order
⁃ first send CSS/JS
⁃ then send the HTML
⁃ then send the images
 push only the resources not cached
by the client
client server
1RTT

The reality
 respond to high-priority requests
immediately
⁃ blocked by unsent data in TCP
 send resources in right order
⁃ some browsers don’t specify
priority, some servers fail to
respect priority
⁃ issues caused by hidden resources
 push only the resources not cached
by the client
⁃ how?
client server
1RTT

TCP head-of-line blocking
 head-of-line (HoL) blocking:
⁃ high-priority data blocked by preceding data in
flight
 TCP HoL blocking:
⁃ data in TCP send buffer blocks following data of
higher priority

TCP head-of-line blocking
 typical H2 server writes much more than that can be
sent immediately
⁃ unsent data in TCP send buffer (and TLS buffer)
HOL-blocks following data
TCP send buffer
CWND
unacked poll threshold
TLS buf.
TLS Records
sent immediately not immediately sent
HTTP/2 frames

TCP head-of-line blocking: the solution
 write only what can be sent immediately
⁃ obtain CWND and unacked size using TCP_INFO
 adjust poll threshold to delay write notification until
TCP becomes ready to send some data immediately
CWND
unacked poll threshold
TLS Records
sent immediately not immediately sent
HTTP/2 frames
TCP send buffer

TCP head-of-line blocking: benchmark 1
 conditions:
⁃ server in Ireland, client in Tokyo (RTT 250ms)
⁃ load tiny js at the top of a large HTML
 result: delay decreased from 511ms to 250ms
⁃ i.e. JS fetch latency was 2RTT, became 1 RTT
• similar results in other environments

TCP head-of-line blocking: benchmark 2
 using same data as previous
 server: Sakura VPS (Ishikari DC)
0
50
100
150
200
250
300
HTML JS
milliseconds
downloading HTML (and JS within)
RTT ~25ms
master latopt

HTTP/2 prioritization
Root
Leader G
Follower G
weight: 1
HTML
weight: 32
Image
weight: 22
Image
weight: 22
Image
weight: 22
CSS
weight: 32
CSS
weight: 32
 hybrid approach using weights and chaining
⁃ servers are expected to obey to the priority
specified by the clients
 Firefox’s prioritization graph is shown below
JS
weight: 32
JS
weight: 32

HTTP/2 prioritization
 some web browsers fail to specify priority
⁃ Safari, Blink
⁃ older versions of Chrome also had issues
⁃ server-side countermeasures required
Root
HTML
weight: 16
CSS
weight: 16
JS
weight: 16
Image
weight: 16
Image
weight: 16
Image
weight: 16

HTTP/2 prioritization: the solution
 bandwidth distribution on server-side:
⁃ use Weighted Fair Queuing (WFQ) or Deficit
Round Robin (DRR)
⁃ some servers do it right:
• nghttp2 (and Apache) implements WFQ in O(log N)
• H2O approximates WFQ in O(1)
 detect dumb clients and fallback to server-driven
prioritization
⁃ H2O reprioritizes CSS, JS for clients that do not
use priority chains

HTTP/2 prioritization: benchmark
 differences between the times spent until first-paint
(red bar)

Hidden resource
 hidden resource: a resource
specified in CSS (@import) or
JavaScript
⁃ was anti-pattern in HTTP/1
⁃ anti-pattern in HTTP/2 as well
 solution:
⁃ avoid use of hidden resources
that block rendering (e.g. CSS,
JS)
⁃ or, specify them using link:
rel=preload
client server

Push
 three use-cases:
⁃ prioritization
⁃ push while processing request
⁃ push from edge

Pushing for prioritization
client server
GET /
GET
/style.css
HTTP/2 200 OK
<html>
<link
rel=style.css...
HTTP/2 200 OK
body: ...
#title: ...
1. send CSS, JS first
2. then send HTML
(can be rendered
progressively)
without push
client server
GET /
GET /style.css HTTP/2
HTTP/2 200 OK
body: ...
#title: ...
with push
HTTP/2 200 OK
<html>
<link rel=style.css ...

Push while processing request
 web applications involving DB access, etc.
req.
processrequest
push-asset
HTML
push-asset
push-asset
push-asset
req.
processrequest
asset
HTML
asset
asset
asset
req.
450ms(5RTT+processingme)
250ms(1RTT+processingme)
without push with push

Push from edge
 CDNs’ use-case
⁃ utilize the conn. while waiting for app. response
req.
push-asset
HTML
push-asset
push-asset
push-asset
client edge server (CDN) app. server
req.
HTML

How to push
 H2 server may push preloaded links
⁃ e.g. Link: </style.css>; rel=preload
⁃ H2 server may push preloaded links
⁃ recognized by Apache, H2O, nghttp2
⁃ patch exists for Nginx
 use nopush attribute to opt-out
⁃ e.g. Link: </dontpush.jpg>; rel=preload; nopush
 note: use of preload as a push indicator is upon the
process of standardization at W3C

How to push while processing request
 send Link: rel=preload as interim response
⁃ application sends 100 then processes the request
 supported in H2O 2.1
GET / HTTP/1.1
Host: example.com
HTTP/1.1 100 Continue
Link: </style.css>; rel=preload
HTTP/1.1 200 OK
Content-Type: text/html
<!DOCTYPE HTML>
...
HTTP/2 server app. server Web app.
GET /
100 Continue
Link: …
GET /
200 OK
200 OK
processrequest

How to push while processing request
 configure your H2 server
⁃ in case of H2O:
mruby.handler: |
Proc.new do |env|
push_paths = []
if /(/|.html)$/.match(env["PATH_INFO"])
push_paths << "/style.css”
...
end
[399, push_paths.empty? ? {} : {"link" =>
push_paths.map{|p| "<#{p}>; rel=preload"}.join("n")}, []]
end
file.dir: /path/to/doc-root

BTW, you can do more by using mruby
 HTTP authentication
mruby.handler: |
require "htpasswd.rb"
Htpasswd.new("/path/to/.htpasswd", "realm-name")
 DoS mitigation
mruby.handler: |
require "dos_detector.rb"
DoSDetector.new({
:strategy => DoSDetector.CountingStrategy.new({
:period => 10,
:threshold => 100,
:ban_period => 300,
}),
})

... and more
 Access Control
mruby.handler: |
acl {
allow { addr == "127.0.0.1" }
deny {
user_agent.match(/curl/i) && !addr.start_with?("192.168.")
}
respond(503, {}, ["Service Unavailable"]) {
addr == malicious_ip
}
redirect("https://example.com/", 301) {
path =~ /moved/
}
use Htpasswd.new("/path/to/.htpasswd", "realm") {
path.start_with?("/admin")
}
}

... and more
 fast IPv4 address matching using Trie4
mruby.handler: |
require "trie_addr.rb"
trie = TrieAddr.new.add([
"192.168.0.0/16", "172.16.0.0/12", ...]
)
acl {
allow { trie.match?(addr) }
deny
}
4: http://dsas.blog.klab.org/archives/51293338.html

How to push from edge
 depends on CDN
⁃ some CDNs may use RUM-based approach
⁃ others may provide DSL
• GCP provides http2-push-manifest (JSON-based)
⁃ though cannot be used for pushing from edge
⁃ anybody using (m)ruby on edge?

Push vs. cache
 why would you ever push cached resources?
⁃ it’s waste of bandwidth (and time)
 several ways to avoid pushing cached resources
⁃ cookie-based
• supported by H2O
⁃ cache-digest
• supported by Apache, H2O
• needs browser support or ServiceWorker script
• standardization in process at IETF
⁃ implement your own

Avoiding negative effect caused by push
 don’t push unless your mechanism is cache-aware
 only push resources that block rendering
⁃ reason:
• H2 endpoints have difficulty in distributing bandwidth
bet. pushed and pulled responses
• negative effect caused by HoL blocking, prioritization
and hidden resources becomes more apparent with
push
 above rules don’t apply to the tiny pushes
⁃ i.e. those used as a replacement for inlining (i.e.
<img src=“data:...”>)

Summary

Summary
 HTTP/2 has become popular
 the effectiveness varies between implementations
⁃ HoL-blocking avoidance, prioritization, cache-
aware push, ...
⁃ upcoming specs (e.g. TLS/1.3, QUIC) may cause
even more difference
⁃ careful evaluation of servers / CDNs is important
 H2O is the leader in HTTP/2 server performance
⁃ and can be configured using mruby

Recent Advances in HTTP, controlling them using ruby

More Related Content

What's hot

Similar to Recent Advances in HTTP, controlling them using ruby

More from Kazuho Oku

Recently uploaded

Recent Advances in HTTP, controlling them using ruby

Editor's Notes