►
Description
Featuring Adam Sayah. HTTP/3 is the latest version of the HyperText Transfer Protocol used wildly in the WEB, Unlike its predecessors (HTTP/1 and HTTP/2), HTTP/3 doesn’t use TCP, and relay on a protocol based on top of UDP, which allows a significant improvement in performance and reducing latency, in this talk:
- We will have an introduction to HTTP
- We will compare HTTP/3 to HTTP/1 and HTTP/2
- We explore QUIC, the new protocol based on UDP that HTTP/3 uses
- We will see how HTTP/3 operates in practice through a demo.
Attending this talk, the attendees will get a better understanding of HTTP/3, a fundamental technology that will accelerate the WEB.
A
A
This
is
a
quick,
basically
a
quick
intro
to
what
HTTP
3
actually
was
used
for.
What's
the
use
cases
we
have
for
today,
and
how
do
you
turn
it
on
in
Envoy?
How
can
you
use
Envoy
for
serving
HTTP
3?
Okay,
all
right
so,
first
a
bit
about
me.
My
name
is
Adam
Saya
I'm,
a
field
engineer
at
solo
I
help
my
customers
and
Prospects,
basically
with
all
their
API
gateways,
questions
and
service
mesh
and
so
on.
A
So
if
you
guys
want
to
have
a
chat,
you
know
slack
dot,
solar,
Tire
or
Twitter
here,
I
want
to
give
a
big
shout
out
to
Batista
one
of
my
Fe
colleagues
on
that
worked
on
HTTP
3
blog.
He
has
a
really
good
content
there.
It
has
a
lot
of
extra.
You
know
data
if
you
guys
want
to
go
deeper
in
this
subject,
but
for
most
of
this
slides,
apparently
I
get
a
lot
of
inspiration
from
this
block.
A
Okay,
so
what
we're
gonna
do
gonna,
go
through
a
brief
history
of
HTTP
3..
Basically,
why
all
this
Evolution,
and
basically
where
we
are
today
with
HTTP
3
and
what's
the
nuances
there
so
can
be?
What's
the
differences
between
HTTP
one
should
be
two
and
it
should
be
three
and
then
we're
going
to
talk
about
quick,
which
is
basically
spoiler
alerts.
A
Okay,
so,
let's
start
here
a
quick
history
of
HTTP,
so
HTTP
is
pretty
old.
I
mean
we're
talking
about
30
years
of
existing.
Now
it
started
with
a
good.
Oh,
we
have
good
Ambiance
too
yeah.
So
a
stupid
started
with
a
basic
basic
protocol
to
allow
us
to
access
data,
but
was
way
too
limited.
We
were
able
to
make
calls
like
get
calls
to
get
data,
but
that
was
pretty
much
it
now.
A
Things
that
are
lacking
at
that
time
was
basically
differentiating
in
terms
of,
like
you
know,
header
support
for
multiple
use
cases,
kind
of
the
most
common
use
case
for
how
to
support
is,
and
we
need
headers
for
cache
control
right.
If
we
have
any
data
that
we
need
to
Cache,
somehow
we
need
to
activate
certain
mechanisms
and
beta
different
based
on
different
behaviors.
Headers
are
kind
of
the
way
to
go,
and
this
is
what
came
out
in
HTTP
one
one.
We
added
HTTP
header
support
to
basic
HTTP,
and
that
was
fine.
A
The
thing
is
with
HTTP
the
basic
version.
I
mean
one
and
one
one.
It
chooses
one
connection
per
kind
of
request.
Can
this
is
not
scalable,
meaning
if
you
make
a
lot
of
requests
and
services
are
already
consuming
a
lot
of
traffic,
it
means
that's
going
to
create
a
lot
of
connections
that
will
stress
your
network.
A
lot
now
Google
thinking
about
this
solution
to
this
problem.
They
came
up
with
different
things
and
I
think
the
main
the
first
one
is
Speedy
right.
A
The
Speedy
protocol
allow
us
to
basically
do
Multiplex
in
multiplexing
off
different
connections
on
a
different
requests
on
the
same
connection
right.
This
is
kind
of
the
first
step
to
what
we
know
in
HTTP
2
using
multi
Multiplex
connections
right,
so
that
was
limited
to
only
couple
I
think
only
like
eight
or
nine
connections
on
start
really
basic,
but
also
they
worked
on
a
different
thing,
which
is
the
LPN
that
we
still
use
today,
meaning
when
we
negotiate
TLS.
A
At
the
same
time,
we
actually
can
Define,
which
protocol
we
can
use
in
this
case
before
the
LPN
will
allow
you
to
if
there
is
any
enhancement
in
term
of
like
connectivity,
something
we
can
turn
on
as
part
of
like
the
TLs
negotiation.
We'll
be
able
to
have
this
data,
and
you
know
retry
the
request
or
upgrade
the
request
for
a
better
protocol,
and
actually
these
two
together
are
kind
of
the
first
steps
to
what's.
Http
2
is
which
is
a
way
to
Multiplex
connections
again
and
it's
way
quicker
than
HTTP
one
right.
A
If
in
comparison,
I,
don't
have
any
diagram
here,
but
if
you
look
into
comparison
between
HTTP
one
and
HTTP
2
in
terms
of
performance,
we
are
talking
double
triple,
sometimes
right.
So
this
is
really
important
and
it
was
a
big
step
into
the
right
direction.
Now,
HTTP
2
is
great.
The
thing
is
we
live
in
a
world
where,
where
it's
not
always,
we
don't
have
always
stable
connections.
If
we
talk
about
you
know,
we
all
are
all
our
phones.
We
are
all
you
know
on
bad
networks.
A
So
we
need
a
solution
to
help
us
having
the
best
of
you
know,
use
you
know,
user
experience
in
all
situations,
and
this
is
what
actually
is
the
premise
of
why
HTTP
3.?
Okay,
we
have
good
performance
with
HTTP
2.,
that's
great.
That
based
on
TCP,
is
fine.
If
your
network
is
good
and
all
that
stuff,
but
real
world
use,
cases
need
something
more
like
HTTP
3..
A
A
Now
only
the
packets
that
are
lost
can
be
reset
right.
So
that
means
from
a
performance
perspective.
Now
we
are
not.
We
don't
need
to
resend
everything,
and
this
is
a
big
big
Improvement
in
and
a
lot
of
things
like
imagine,
you
are
downloading
something
imagine
you
are
connecting
to
a
game.
Imagine
anything
else
like
you
are
losing
one
package
because
of
bad
network.
Imagine
all
the
lane
seeking
that
can
be
involved
into
resending
everything
every
time
right,
especially
if
we
talk
about
real-time
data
and
things
like
that.
A
A
Also,
on
top
of
that
there's
new
feature
for
connection
migration
connection.
Migration
is
really
important.
Imagine
I
think
that's
a
use
case
for
everyone
here
you
are
at
home.
You
have
your
Wi-Fi
you're,
fine
you're,
you
know
you're
on
a
zoom
call
whatever,
and
then
you
have
to
go
outside
for
some
reason
right
then,
you
are
in
your
your
connection
and
somehow
everything
drops
why?
Because
well,
you
have
to
switch
to
a
different
network.
You
can
actually
need
to
switch
different
things.
We
have
to
restart
all
the
connections
that
gets.
A
You
know
you
feel
it.
There
is
something
going
on
there
where,
if
you
have
connection
migration,
meaning
like
if
you
are
actually
on
top
of
basically
you're
already
running
HTTP
3,
if
you
are
switching
networks,
switching
traffic
going
somewhere
else
that
would
just
automatically
switch
to
that
or
to
the
new
to
the
new
way
of
connecting
to
your
service.
Basically,
and
so,
if
you
are
in
the
same
example,
I
was
talking
about.
A
If
you
are
on
your
Wi-Fi
and
then
you
go
outside,
and
you
are
now
on
your
data
on
your
phone
you'll
see
no
lost
no
packet
loss.
You
can
see
there
everything
going
to
continue
to
work
perfectly
as
used
to
be.
This
is
a
huge
yeah
so
now
in
term
of
performance
in
terms
of
comparison
like
when
we
try
to
talk
to
a
back
end
using
let's
say
the
basic
use
case.
A
So,
in
terms
of
like
the
time
we
get
to
make
the
request,
this
is
way
longer
than
actually
for
at
first
with
two:
that's
one:
three,
we
have
one
one
less
stop
there,
so
it's
gonna
get
way
faster
in
getting
the
data,
but
the
important
thing
is
actually
in
HTTP
3,
where
quick
itself,
like
the
protocol,
that's
actually
connecting
to
your
back
end,
contains
contains
TLS
embedded.
So
as
part
of
the
first
negotiation
as
part
of
the
first
connection,
you
are
already
already
TLS
connected.
Everything
is
ready
to
just
start
sharing
data
plus.
A
So
let's
talk
quickly.
Oh
that's
good
work
quickly
about
quick,
quick
for
quick,
UDP
internet
connections.
Okay,
this
is
the
protocol
behind
HTTP
3.
In
this
case,
what
I
think
we
talked
a
bit
about
all
this
so
in
if
we
want
to
do
a
pros
and
cons
here,
it
fixed
the
TCP
head
of
line
blocking
situation
that
we
talked
about
earlier
right.
We
if
we
have
a
packet,
that's
lost
for
some
reason.
A
We
are
not
going
to
send
everything
back,
we're
going
to
send
only
the
packet,
that's
being
lost,
so
this
is
kind
of
the
power
of
UDP
in
cents
plus
it
has
a
better.
Obviously,
since
we
have,
since
we
can
send
only
the
packet
lost
in
internet
where,
in
like
situations
where
we
have
a
bad
Network,
this
drives
right,
because
obviously
this
is
where
it's
more
often
happening.
Yes,
oh
okay!
Thank
you,
and
so
another
thing
is
it's
reduced,
obviously,
the
time
to
connect
right.
A
It
goes
from
like
multiple
steps
to
zero
step
now,
because
if
you
have
a
session
reception
and
but
the
thing
is
like
in
on
the
cons
side,
there's
a
couple
things
first,
TCP
is
everywhere.
So
usually
you
know
your
load.
Balancers
are
all
happy
with
it.
So
there's
no
problem
with
HTTP
one
and
two
when
it
comes
to
UDP,
usually
by
default,
we
don't
see
all
the
networks
having
UDP
allowed.
So
you
need
to
worry
about
this.
A
If
you
have
to
turn
on
HTTP
3
in
your
network,
make
sure
you
are
allowing
UDP
connections
and
also
there's
different
implementations
at
this
point.
We
know
that
things
like
this
mature
in
the
long
term,
even
if
it's
GH
day
things
like
HTTP
2
I-
think
even
now,
there's
still
people
using
http1.
So
it's
kind
of
gonna
take
your
time
to
get
to
a
dominant
player
there.
In
terms
of
implementations.
A
A
A
Now
quick
thing.
Let's
take
a
look
at
how
HTTP
3
is
actually
configured
in
Android
Envoy
supports
HTTP
3,
since
Envoy
122
on
Downstream
connections,
meaning
connect
connecting
to
envoys
a
client
can't
connect
using
HTTP
3
to
Android
on
the
recent
version
of
of
envoy
by
124.
Now
we
have
support
for
Upstream
connection,
so
from
Envoy
itself
we
can
connect
to
a
backend
service,
which
is
in
HTTP
3..
A
Now
this
is
still
not
fully
supported,
they're
still
missing
things
there,
but
the
ga
part
is
actually
from
a
client
to
Android.
Now
other
things
is
so.
We
need
to
create
a
new
listener,
obviously
in
UDP
for
quick
for
actually
P3,
and
another
thing
that's
really
important
is
that
we
can
introduce
HTTP
3
without
a
big
problem,
meaning
we
can
configure
both
listeners
with
the
same
port
and
actually
we
can
use
the
alt
Service
header
in
in
HTTP
2
with
where
we
can.
You
know,
let's
say
a
use
case.
A
A
So
here
is
an
example
of
configuration
of
a
configuration
allowing
HTTP
3..
So
if
we
take
a
look
at
Envoy,
I,
don't
know
if
you
guys
are
familiar
with
the
cast
with
the
configurations
now,
the
only
so
the
only
thing
you
have
to
do
is
to
create
a
new
listener
with
UDP
this
time
you
can
use
the
same
port
as
the
one
exposed
in
TCP
and
you
have
to
create.
A
You
know,
add
the
transport
socket
to
be
using
quick
and
then
you
have
to
provide
the
TLs
certificate,
but
in
this
full
example
here
we
see
that
we
have
again
another
filter,
another
listener,
sorry
that
is
also
on
that
is
on
TCP
this
time,
using
the
same
ports
and
again
as
I
mentioned
you
can
use.
You
know,
outservice
header,
to
let
your
client
know
that
the
same
service
is
available
on
HTTP
3
and
the
connect.
The
next
connection
can
be
HTTP
3
to
Envoy.
A
A
So
in
conclusion,
HTTP
3
works
over
quick,
which
is
based
on
UDP.
Tls1
is
embedded
within
the
protocol,
so
it
is
always
encrypted.
It
helps
the
security
posture.
It
helps
with
you
know
all
defectiveness
effectiveness
of
http1
tls13,
it's
more
performance
on
low
Network,
where
packets
are
lost,
and
it's
already
adopted
by
the
big
players
out.
There
is
Now
supported
in
an
Envoy,
so
give
it
to
give
it
a
shot.