►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
HTTP/3 in Envoy: End to End Acceleration - Alyssa Wilk & Ryan Hamilton, Google
With HTTP/3 support going alpha in the Envoy 1.19.0 release, the team that launched HTTP/3 is excited to explain what HTTP/3 is, and talk about Envoy’s HTTP/3 integration: what is supported today, what is upcoming, and what best practices there are for testing and deploying HTTP/3 for your own Envoy instances, client side or server side.
A
A
This
talk
is
in
three
parts:
I'll
talk
about
the
first
two,
an
overview
of
http
3
and
the
benefits
it
provides
and
the
experience
we
gained
deploying
http
3
at
scale.
Then
alissa
will
take
over
and
cover
the
third
part
envoy
integration,
let's
dive
in
we'll
start
with
an
overview
of
http
3
and
the
benefits
it
provides.
But
first,
let's
start
with
why
http
3
is
so
exciting,
namely
http
3
is
simply
faster.
Let's
look
at
two
metrics
from
google,
which
show
how
much
the
first
is
search.
A
A
The
second
metric
is
from
youtube.
You
probably
recognize
the
spinner
that
happens
when
you're
paused
waiting
for
more
of
your
video
to
load.
This
is
called
buffering.
Youtube
calls
this
buffering
and
the
time
between
buffering
events
is
the
is
the
mtbr
the
longer
it
goes
between
rebuffers,
the
better,
the
fewer
rebuffers,
the
better,
with
http
3,
enabled
youtube
mtbr
improves
by
30.
A
A
It's
supported
in
all
major
browsers
in
many
mobile
apps
in
server
stacks
and
server
deployments
according
to
cloudflare
radar,
17
of
internet
traffic
is
currently
http
3.
and
for
services
like
facebook,
which
have
leaned
heavily
into
http
3
they're,
seeing
something
like
75
of
their
traffic
coming
in
over
http3,
and
quite
simply,
it's
designed
to
be
fast
on
the
internet.
So,
let's
look
at.
A
We
have
ip
packets
at
the
bottom
over
which
we
run
tcp,
on
top
of
which
we
stack
tls
and
then
finally,
http
1
or
http
2.
with
http
3.
This
is
quite
different.
Instead
of
using
tcp,
we
use
udp
on
top
of
that
runs,
a
new
protocol
called
quick
which
consumes
the
reliability
features
of
tcp
and
the
multiplexing
features
of
http
2
and
internally
makes
use
of
tls
1
3
for
the
handshake
and
for
packet
encryption
and
then
on
top
of
that
is
http
3.
A
The
first
is
faster
connection,
establishment
time
through
the
zero
rtt
handshake,
the
zero
round
trip
handshake
so
with
tcp
there's
the
common
synack
exchange,
the
three-way
handshake
between
a
client
and
a
server.
So
after
one
round-trip
of
packets
between
the
client
and
the
server,
the
client
is
able
to
send
application
data.
A
But
of
course,
these
days
we
don't
just
want
to
send
data
between
clients
and
servers.
We
want
to
send
that
data
securely,
so
we
need
to
run
a
security
layer
on
top
typically
tls,
which
adds
its
own
set
of
round
trips
into
the
handshake,
so
with
tcp,
plus
tls12
we're
looking
at
somewhere
between
two
to
three
round
trips.
Before
application,
data
can
be
sent
to
the
server
with
quick,
which
is
equivalent
to
tcp
plus
tls,
we're
down
to
between
zero
and
one.
A
If
a
client
has
spoken
to
a
quick
server
before
the
server
will
give
that
client
an
encrypted
token,
which
the
client
is
able
to
use
in
subsequent
connections,
so
it
sends
the
client
hello
and
can
immediately
follow
that
up
with
encrypted
data
round
trip
times
on.
The
internet
cannot
uncommonly
be
in
the
range
of
250
milliseconds.
A
A
Next,
let's
talk
a
little
bit
about
head
of
line
blocking
and
the
evolution
of
http
back
in
the
http
one
days.
Each
request
would
go
on
a
dedicated,
tcp
connection.
If
you
wanted
to
have
multiple
requests
in
flight
at
once,
you
would
need
multiple
tcp
connections.
If
you
went
a
lot
of
requests
inflate,
you
would
need
a
lot
of
tcp
connections,
but
of
course,
you
can't
have
an
infinite
number,
so
browsers
impose
limits
on
the
number
of
sockets
that
they'll
open
to
a
particular
site.
A
A
However,
because
it's
a
single
tcp
connection
and
a
single
in-order
sequence
of
bytes
packet
loss
can
be
quite
problematic
when
packets
make
their
way
onto
the
internet.
The
internet
sometimes
decides
to
drop
those
packets
and
on
a
tcp
connection,
any
data
after
the
lost
packet
can't
be
delivered
up
to
the
application.
A
Until
that
data
is
retransmitted
and
arrives
at
the
server.
This
is
called
head
of
line
blocking
and
it's
a
real
problem
for
latency
and
here's
where
http
3
comes
in
using
quick,
quick
runs
over
udp,
which
doesn't
present
a
single
in
order
sequence
of
bytes.
Instead,
it's
a
series
of
datagrams
sent
from
the
client
to
the
server
that
are
each
capable
of
being
processed
independently.
A
A
Http
3
is
new,
tcp
is
not
the
internet
is
old
and
tcp
has
been
a
part
of
it
from
the
beginning.
So,
basically,
all
internet
infrastructure
is
expected
to
allow
tcp
traffic
to
pass
if
you're,
if
you're
on
a
network
and
your
tcp
traffic
doesn't
get
through.
Your
network
is
basically
broken
and
it's
time
to
complain
to
somebody
about
it.
Unfortunately,
that's
not
true
for
quick,
that's
not
true
for
http
3..
There
are
lots
of
devices
out
there
that
block
all
sorts
of
things,
including.
B
A
And
hd
v3,
and
so
an
h3
client
needs
to
be
able
to
fall
back
to
http,
1
or
http
2.
In
these
situations,
some
data
we
have
from
chrome
suggests
that
currently
something
like
10
of
all
users
will
be
unable
to
ever
make
quick
connections
and
will
always
need
to
be
doing
http,
1
or
http
2.,
and
there
are
a
couple
of
network
pathologies
which
lead
to
this
behavior.
A
One
which
is
most
common
is
that
all
quick
traffic
will
be
blocked.
So
when
a
client
tries
to
establish
a
quick
connection
that
quick
handshake
fails,
the
connection
is
never
established.
The
client
notices
this
switches
to
a
tcp
connection
instead
and
sends
requests
over
that
clients
are
often
smart
and
will
notice
that
quick
is
broken
and
avoid
attempting
subsequent
quick
connections
as
performance
optimization.
A
However,
some
networks
are
worse.
Some
networks
will
cause
failures
after
the
handshake
by
blackholing,
all
packets
or
sometimes
connectivity
will
randomly
drop
in
the
middle
of
a
connection,
and
so
clients
need
mitigations
for
this.
The
first
thing
they
need
is
detection.
Clients
need
to
be
able
to
notice
that
they're
sending
packets
into
a
black
hole
that
everything
they
send
results
in
nothing
coming
back.
A
A
B
Hey
I'm
melissa,
one
of
the
unvoiced
singer
maintainers
and
a
long
time
server
and
protocols
developer
at
google.
Before
I
dive
into
how
this
all
works,
I
want
to
do
a
call
to
dan
the
google
engineer,
who
did
the
heavy
lifting
for
all
this
work.
She's,
actually
heads
down
closing
off
the
last
few
mpv
blockers
to
get
envoy
quick
to
ga
for
an
upcoming
launch.
So
as
I've
been
doing
much
of
the
quick
client-side
integration,
I'm
standing
in
to
talk
about
how
it
all
hangs
together
envoy.
B
Has
this
amazing
series
of
api
abstractions
with
a
clean
separation
of
function
as
new
requests,
land
on
the
machine
they
get
accepted
and
assigned
to
a
worker
thread?
Data
is
read
from
and
written
to
a
transport
socket.
For
example,
the
tls
socket
where
the
transport
socket
is
responsible
for
decrypting
data
from
the
wire
and
encrypting
data
that
it
writes
out.
As
data
is
read,
it's
passed
through
a
configurable
series
of
l4
filters
which
can
inspect
the
data
or
do
transformations
on
it
for
hdp.
B
Each
of
the
streams
has
its
own
series
of
l7
filters,
culminating
in
the
router
filter,
which
ships
the
data
upstream
things
don't
work
quite
the
same
way
for
http
3..
To
start
with,
getting
the
packets
to
a
connection
from
a
connection
to
a
worker
thread
is
a
little
bit
more
complicated
where
accepting
a
tcp
connection
makes
it
really
simple
for
pcb
data
to
land
on
the
right
worker
thread.
The
kernel.
B
B
Now
that
we've
solved
the
problem
of
landing
packets
on
the
right
threads,
we
need
to
get
them
to
the
right
connections.
All
the
packets
for
this
thread's
connections
will
land
on
the
same
listener
and
something
needs
to
sort
them
into
individual
connections.
That
entity
is
the
dispatcher
it
takes
in
all
the
udp
packets,
for
that
thread,
creates
new
logical
connections
for
new
handshake
packets
and
for
established
connections
just
route
the
packets
to
those
connections.
B
Quick
has
one
option
for
crypto
and
it's
tls13,
so
the
server
simply
won't
start
up.
If
you
configure
a
different
transport
socket
for
quick
as
the
dispatcher
handles
forwarding
packets
to
the
right
connections,
there's
no
need
for
the
transport
socket's.
Traditional
read:
write
support,
there's
also
currently
not
support
for
l4
filters
for
http
3..
Each
quick
stream
is
logically
an
l4
connection
and
an
l7
stream,
and
we
treat
them
as
a
ladder.
B
There
is
the
same
need
to
turn
the
stream
of
packets
for
connection
into
a
series
of
streams.
The
onboard
quick
server
session
does
this
creating
new
server
streams
for
each
http
3
stream?
These
map
one-to-one
with
the
streams
inside
the
http
connection
manager,
so
as
headers
bodies
and
data
arrive
at
the
quick
server
streams,
they're
passed
to
the
on
voice
stream
representation
and
pass
through
the
l7
filters,
just
as
stream
data
does
for
http
1
and
http
2..
B
Okay,
now
that
we've
established
how
http
3
works
in
envoy,
the
real
question
is:
how
do
we
use
it?
I'm
going
to
run
through
three
example:
configurations
using
hp
downstream
and
using
http
upstream.
All
of
these
examples
are
linked
to
the
online
repo.
So
if
you
have
an
envoy
instance,
you
can
run
them
pretty
easily.
Just
by
setting
the
config
path
flag
to
one
of
the
files
listed
above.
B
The
first
thing
that
we're
going
to
run
through
is
how
to
use
envoy
to
terminate
http3
traffic.
If
you
have
edge
envoy
deployments
today,
you
can
pretty
trivially
get
the
latency
and
quality
of
experience
gains
for
all
major
browser
traffic.
Just
by
adding
these
sections
to
your
config
file
for
hdb3
deployments,
you
still
need
to
maintain
a
tcp
ttp
lessener
doing
tls
for
hp1
or
hdb2
responses
from
that
listener
should
inform
clients.
You
now
support
each
to
b3.
B
We
do
this
here
by
sticking
an
alt
service
header
in
response
headers,
to
add
so
for
this
route
browsers
will
now
try
to
do
http
3
for
all
the
hostnames
they
encounter
and
they'll
direct
that
http
3
to
port
1000..
Now
normally
in
production
that
would
be
443,
but
for
the
example
configs.
We
wanted
folks
to
be
able
to
play
around
without
needing
root
credentials,
so
we
picked
an
alternate
port.
B
Of
course
you
also
have
to
have
the
http
3
listener,
or
rather
a
udp
listener
configured
to
do
http
3-
and
this
is
what
that
looks
like
it's.
A
standard
udp
listener,
with
quick
options
to
tell
the
listener
code,
it'll
be
doing
quick
and
then
a
transport
socket
with
a
quick,
crypto
config
to
make
sure
it
does
it's
tls13
correctly.
The
listener
is
running
on
port
10000.
B
Since
that's
what
the
alt
service
advertisement
is
set
to,
you
can
also
get
fancier
with
your
alt
service
headers,
directing
quick
traffic
to
a
set
of
canary
clusters,
rather
than
having
your
quick
server
and
tcp
servers
in
the
same
process.
If
you
want
to
scale
up
more
slowly
and
carefully
getting
envoy
to
do,
h3
upstream
is
even
simpler.
You
just
configure
the
cluster's
protocol
options
to
do
h2b3
and
configure
a
quick
transport
socket
now
note.
B
B
B
If
it
gets
a
response
with
alt
service
headers
for
http,
3
only
will
cache
that
the
endpoint
uses
http
3
and
attempt
to
use
that
going
forward
if
each
v3
fails
consistently.
Despite
the
l-service
advertisement,
onway
will
keep
on
using
tcp
connections
and
eventually
h3
gets
marked
broken.
The
important
part
is
that,
with
this,
configuration
envoy
will
try
to
use
the
best
available
protocol,
but
we'll
make
sure,
at
the
end
of
the
day
the
queries
get
through
as
quickly
as
possible.
B
There's
more
data
about
the
timing
of
trying
http
3
failing
over
to
tcp
how
connections
get
marked
broken
in
the
envoy
docs
so
feel
free
to
check
those
out.
If
you
want
the
gritty
details,
we've
largely
set
up
the
default
timings
to
match
what
chrome's
been
doing
for
failover,
which
has
been
tested
at
scale
of
the
real
world.
It
does
a
great
job
of
balancing
the
desire
to
do
each
v3,
where
it's
possible,
while
minimizing
time
waiting
on
http
connections
on
networks
where
it's
blocked.
B
One
last
thing
I
want
to
call
out
before
we
go
to
q,
a
the
quick
j
is
coming
really
soon.
The
config
is
stabilized
and
is
being
tested
at
scale
and
production,
as
we
speak,
we're
down
to
four
blockers,
which
are
all
pretty
small.
I
was
honestly
hoping
it
would
land
this
week
rather
than
in
a
week
or
two,
so
I
could
announce
it
here,
but
we'd
really
rather
have
it
solid
than
rush
anything
after
that
our
team
is
going
to
be
head
down
getting
fully
functional,
http
3
for
onslaught
mobile.
B
This
is
largely
making
sure
that
things
like
the
alt
surface
entries
and
zero
run
trip
credentials
are
cached
persistently
across
application
restarts
you
lose
some
of
the
latency
benefits
that
every
time
your
app
loses
focus.
It
forgets
to
use
http
3
and
has
to
do
a
full
handshake,
but
there's
also
work
to
be
done
for
the
black
hole,
detection
and
port
migration
things
that
ryan
mentioned
earlier.
Hopefully,
we'll
be
able
to
finish
that
work
quickly
and
start
using
h3
for
online
mobile
early
next
year.
B
We
should
have
time
for
q
a
after
this,
but
if
you're
watching
this
online
or
have
questions,
we
didn't
get
to
feel
free
to
reach
out
to
us
on
voice
slack.
We
keep
an
eye
on
the
envoy,
udp,
quick,
dev
channel,
so
it's
a
great
place
to
keep
in
touch
with.
What's
going
on
or
ask
questions
about,
what's
coming
so
thanks
and
any
questions.