►
Description
Dirkjan Ochtmann takes us on a ride
to the future of Rust serverside
to learn what async fate we will have to await
Meanwhile let us Rust far and wide!
Once HTTP/2 was standardized in 2015, the IETF started work on an even faster iteration of HTTP, based on QUIC: the Quick UDP Internet Connections protocol. The QUIC community is getting ever closer to standardizing it. While we have great HTTP and HTTP/2 implementations in Rust already, this talk discusses an effort to implement QUIC in pure Rust, based on the futures ecosystem.
(Limerick by @llogiq)
https://paris.rustfest.eu/sessions/a-quic-future-in-rust
A
B
Better,
yes,
it's
not
just
about
a
server
site.
It's
a
client
site
as
well.
Yeah
gotta
have
two
sides
to
any
connection,
so
I'm
here
to
talk
about
quick,
it's
a
new
protocol.
The
ITF
is
currently
working
on
first,
a
little
bit
about
me,
so
I've
been
using
rust
for
about
two
years
in
my
spare
time,
mostly
or
really
only
and.
B
B
It's
called
quick,
UDP,
internet
connections
or
just
quick,
and
basically
the
the
large
companies
are
working
on
internet
stuff.
This
started
at
Google,
but
a
number
of
companies
are
working
at
now
and
are
in
the
working
group
together,
trying
to
standardize
it
and
what
they
want
to
do
in
the
end
is
to
replace
TCP
and
TCP
is
sort
of
this
core
part
of
the
internet
stack.
B
You
might
have
heard
you,
you
might
just
think
of
it
as
TCP
and
IP,
where
basically,
you
shove
data
bytes
into
a
stream,
and
you
get
it
out
on
the
other
side.
So
what
it's
trying
to
do
is
reliable
in
order
delivery
across
the
Internet,
and
this
has
been
working
for
about
four
years
and
there
have
been
some
extensions
to
make
it
better,
but
it
turns
out.
We
have
learned
a
few
things
about
doing
internet
scale
things
in
40
years,
so
they
think
they
can
do
better
than
TCP.
B
Even
with
extensions,
and
they
started
at
Google
in
2012
and
in
2016
they
went
to
the
ITF,
hopefully,
by
the
end
of
the
year
it
will
be
standardized
and
though,
there's
still
a
number
of
things
to
be
fixed,
and
recently
there
was
this
week
there
was
a
proposal
which
might
slow
it
down
for
I,
think
nine
months.
The
estimate
it
so
well,
no,
no,
when
it
comes
really
to
to
a
standard
but
I
think
as
forward-looking
people
are
in
the
rest
community.
B
First
I
want
to
talk
a
little
bit
about
the
problem
or
one
of
the
main
problems
that
we're
trying
to
solve
with
quake,
and
that
is
head-of-line
blocking
and
I've
tried
to
make
an
animation
to
make
this
a
little
bit
clearer.
So
you
see
data
flowing
from
the
application
through
the
transfer
layer
through
the
network
and
at
some
point
a
packet
is
going
to
go,
get
dropped
in
a
network
side
and
the
packets
that
come
after
that,
after
that,
packets
have
to
wait
to
be
delivered
back
to
the
application.
B
These
are
the
goals
that
are,
as
stated
by
the
working
group
Charter
to
minimize
latency,
both
in
the
connection
establishment,
as
well
as
in
the
data
transfer.
As
you
might
know,
TCP
connections
are
a
bit
slow
to
set
up,
often
because
you
have
to
do
multiple
around
and
if
you
also
DTLS,
that's
even
worse,
to
provide
multiplexing.
B
So
that's
sort
of
wedging
together
multiple
streams
by
taking
chunks
of
each
stream
and
serializing
them
into
a
single
stream,
but
with
quick,
it
better
understands
how
you're
doing
multiplexing,
so
the
application
layer
can
influence
that
and
it
allows
you
to
get
rid
of
this
head-of-line
blocking
problem
change
is
limited
to
path
endpoints.
So
what
they're
saying
is
they
don't
want
the
whole
internet
to
have
to
change,
to
be
able
to
do
quick,
so
what
they
do
is
they
use?
B
Udp
UDP
is
sort
of
the
simple,
simple
sibling
to
TCP,
which
basically
means
you
take
an
IP
packets,
you
stuff,
two
port
numbers,
a
checksum
and
a
length
field
in
it,
and
then
you
just
shove
it
on
the
wire,
and
so
that
means
you
don't
get
in
order
or
reliable.
But
you
can
do
this
sort
of
more
fine-grained
stuff
and
leave
the
inorder
reliability
to
something
closer
to
the
application
layer,
which
also
means
it's
easier
to
evolve
over
time.
B
B
Quick
is
split
up
currently
in
six
documents.
It's
nice
because
it
makes
it
a
bit
easier
to
get
to
the
parts
you
find
interesting
or
to
maybe
at
some
point
do
more
modular
protocol
implementations.
First,
one
is
invariants,
so
they
try
to
document
stuff.
That
cannot
change
across
versions
so
that
that
helps,
if
you're
doing
good
version
negotiation
or
you
want
to
try
to
be
robust
against
future
protocol
changes.
Transport
is
like
the
core
protocol
logic,
so
it
has
all
the
stuff
about
the
handshake
and
how
the
data
is
transferred.
B
Recovery
is
all
about
loss,
detection
and
congestion
control.
So
if
packets
get
lost,
how
do
you
detect
it?
What
do
you
do
when
you
detect
it
that
sort
of
thing
or
if
the
flow
of
the
network
is
restricted?
What's
the
best
way
to
handle
that
and
all
of
a
lot
of
these
algorithms
are
algorithms
are
described
in
the
special
specification
TLS.
So
that
is
how
is
that
promise
of
security
realized?
B
So
what
they
do
is
use
the
TLS
spec,
that's
already
out
there,
which
we
have
implementations
for
but
make
it
use
it
in
a
slightly
more
efficient
way
because
it
can
integrate
into
the
quick
layer
and
then
in
order
to
do
HTTP
on
top
a
quick
there's,
two
other
things
so
queue
back.
You
might
know
that
in
HTTP,
two
there's
something
called
H
pack,
which
is
a
way
of
trying
to
do
a
binary
sort
of
compression
encoding
of
the
headers,
both
header
names
and
header
values.
B
So
you
can
do
being
more
efficient
at
HTTP
data
transfer,
making
it
almost
look
like
some
really
smartly
encode
its
binary
protocol
and
for
quick.
They
have
slightly
different
needs,
so
they
also
have
to
do
with
different
encoding
of
the
confession
scheme
and
then
HTTP
to
HTTP
is
sort
of
the
same
thing
where
it's
really
based
on
HTTP
too,
and
it's
quite
similar.
But
a
lot
of
the
details
are
different
to
accommodate
the
quic
semantics.
B
So
sort
of
this
core
idea
in
quic
is
that
of
streams.
So
I
had
to
think
of
some
nice
analogy
and
what
the
core
concept
is
that
you
have
any
and
hardly
hardly
limited
number
of
streams.
You
can
have
I
think
two
to
the
power
62
or
something
so
it
should
be
enough
for
most
people
and
they
have
four
different
types
of
streams.
Streams
are
either
client
initiated
or
server
initiated,
and
they
are
either
by
directional
or
unidirectional.
B
So
this
again
helps
you
do
prevent
head
of
line
blocking
type
problems
and
because
you
have
a
very
clear
ordering
in
your
packet
numbers
in
terms
of
transmission
order,
that
also
makes
it
easier
to
detect
I.
Could
loss
TCP
actually
allows
you
to,
in
some
cases,
go
back
on
acknowledging
packets,
which
is
called
reneging?
B
Finally,
there
is
an
explicit
correction
for
delayed
acknowledgment.
So
as
a
sender,
you
might
well
as
a
receiver,
you
might
well
choose
not
to
ACK
to
send
acknowledgments
directly
for
any
package
that
you
receive
because,
for
example,
it's
more
efficient
to
group
acknowledgments,
but
that
makes
it
harder
for
the
sender
to
determine
the
round-trip
time
because
you're
fiddling
with
the
timing
of
the
X,
so
in
quick,
the
delay
between
receiving
the
packet
and
sending
the
acknowledgment
for
it
can
be
made
explicit
so
that
you
can
reliably
estimate
the
round-trip
time
for
our
packets.
B
So
TLS
is
just
TLS
1.3
handshake
with
a
custom
extension.
The
extension
is
used
to
announce
transport
parameter.
So
this
is
things
like
as
a
receiver,
you
announce
how
much
data
you
can
hold
in
your
buffers
until
you've
acknowledged
it
or
how
many
streams
you
allow
to
be
open.
So
this
really
also
makes
it
possible
to
scale
down.
Implementations
do
not
need
a
lot
of
memory,
and
the
nice
part
of
doing
this
in
the
till
SN
1.3
handshake.
Is
that
both
you
get?
B
B
Negotiated
cipher
suite
and
secrets
from
TLS,
but
you
don't
actually
use
the
TLS
protocol
anymore.
So
instead
of
wrapping
every
data
transport
stuff
in
TLS
record
since
you're
less
managed
messages
that
doesn't
happen.
You
just
encrypt
your
packet
payloads
with
the
handshake
or
the
stuff
that
you
got
from
the
handshake,
not
sure
if
the
slides
are
going
to
come
back.
This
time
doesn't
look
like
it
yeah,
and
so
this
week
there
was
an
announcement.
C
B
The
design
dust
there's
a
stream,
zero
design
team
stream
zero
is
the
stream
that
carries
the
TLS,
handshake
and
and
further
messages,
and
it
looks
like
the
stream
zero
design
team
has
a
lot
of
ideas
about
how
to
improve
stream
zero
or
that
there
are
still
problems
with
the
current
design
of
stream
0.
That
is
what
might
cause
a
bunch
of
extra
delays,
because
this
now
means
that
all
the
TLS
implementations,
so
open,
SSL
or
in
my
case
Russell's,
will
have
to
be
updated
to
support
that
kind
of
stuff.
C
B
Quick
HTTP
is
negotiated
as
a
application
layer
during
the
application
layer
protocol
negotiation.
That's
part
of
the
TLS
handshake
that
works
today.
It's
used
for
HTTP
2
as
well.
For
example.
In
this
case
you
just
say
you
can
say
just
HQ
to
say:
hey
I
supports
HTTP,
quick,
/,
quick.
You
can
also
do
things
like
saying
I
support
HQ
on
this
particular
port,
so
you're
a
regular
HTTP
1
web
server
can
in
its
TLS
handshake,
say.
B
If
you
go
to
this
other
port,
you
can
talk
to
me
over
quick
and
it
can
also
mention
the
quick
version
support
it
so
that
that's
quite
nice
and
prevents
you
from
having
to
do
more
round
trips
to
do
all
that
figure.
All
of
that
out
and
as
I
mentioned,
quick
HTTP
is
built
on
HTTP
2.
So
it's
really
similar
semantically.
But
a
lot
of
the
bits
on
the
wire
are
slightly
different.
I.
B
Have
a
interoperability
matrix,
it's
a
really
nice
visual
with
coloured
cell
cells
and
a
lot
of
letters
on
it.
So
really
what
they
do
in
the
working
group
is.
You
might
know
that
the
IETF
is
big
around
the
motto,
rough
consensus
and
running
code,
and
this
really
represents
a
running
coat.
Part
of
it
so
I
think
they're,
like
15
people
or
groups
that
are
trying
to
implement
quick
and
this
matrix
has
15
clients
on
the
on
the
left,
side
and
15
servers
on
the
top
side
and
then
for
each
combination.
B
B
B
So
that's
basically
stuff
that
I
used
in
my
implementation
first
thing
that
I
used
is
Russell's,
so
big
thanks
to
Joe
for
making
it
and
also
supporting
me
with
code
reviews,
while
I
was
putting
some
quick,
specific
stuff
in
there.
So
there's
one.
The
transport
parameters
extension
that
I
implemented
and
I
have
some
extensions
traits
added
to
the
client
session
and
server
session
type
with
which
you
can,
during
the
setup
or
construction
of
a
session
type.
B
B
So
this
is
a
feature
where
you
can
specify
an
environment
variable
and
that
will
dump
the
TLS
session
secrets
to
a
file
which
is
really
useful
when
you
want
to
debug,
what's
happening
in
your
TLS
connection
and
is,
for
example,
supported
by
browsers
and
NSS
and
open
SSL
and
Russell's
didn't
have
support
yet,
but
it
does
now.
If
you
use
master
now,
I
can
see
my
own
slides
anymore.
So
it.
B
C
B
B
Ssl
is
used
there,
so
it's
I
think
it's
really
trustworthy
stuff,
even
though
it
might
not
be
as
mature
as
your
open
SSL,
but
in
terms
of
security,
I'm,
not
sure
which
horse
I
would
bet
on,
and
so,
if
you
get
a
handshake
complete
in
Russells,
then
there's
a
method
you
can
call.
It
I
think
it's
called
get
negotiated,
cipher
suite
and
it
basically
gives
you
access
to
all
the
algorithms
in
ring.
So
that's
really
nice
for
something
like
the
quick,
current
design
of
stream
zero.
B
Anyway,
where
you
can
then
do
the
packet
payload
encryption
separately
without
relying
on
the
internals
of
city,
less
stuff,
I
also
made
use
of
futures
Tokyo
and
H
H
is
the
HTTP
implementation
based
on
futures
in
Tokyo?
I
had
worked
before
with
futures
in
Tokyo
I
met,
but
it
was
relatively
simple
because
they
were
just
futures
that
pulled
their
internal
futures
for
the
networking
stuff.
But
I
was
looking
at
how
H
implemented
their
API.
B
You
know
how
it
exposes
sort
of
the
fake
multiplexing
that
HTTP
2
does
to
the
API
user
and
what
they
do
is
there's
a
streams
object,
that's
part
of
a
connection
and
they
give
a
clone
of
that
to
the
API
user.
And
then,
if
you
send
some
bytes
through
that
streams
object,
the
streams
object,
will
notify
the
connection
and
make
sure
it
sends
it
off
over
the
connection.
B
B
Stole
an
idea
from
Russells
where
it
has
a
codec
trait,
which
knows
or
provides
an
API
for
encoding
and
decoding
types,
2,
bytes
and
I.
Try
to
or
I
looked
at
how
it
was
done
in
Russells
and
also
in
other
crates,
and
they
were
using
the
buff
and
buff
new
traits
and
that's
a
really
neat
way
of
sort
of
keeping
track
of
where
you
are
in
a
buffer
and
putting
bytes
in
or
getting
bytes
out.
B
B
B
It's
named
after
a
character
from
a
science-fiction
book
which
I've
done
with
other
projects
as
well.
The
goals
for
this
foundation
were
to
first
to
implement
the
specification
faithfully,
and
so
we
can
fill
up
that
interoperability
matrix,
which
I'll
just
quickly
show
to
you.
So
you
have
an
idea
of
what
it
looks
like.
B
A
second
to
have
clear,
abstractions
and
concepts
so
that
there
will
be
a
good,
API,
I
think
earlier.
It
was
said
that
libraries,
without
or
with
with
bad
documentation,
aren't
really
that
useful.
Currently,
there
is
no
documentation
yet
so
in
that
sense,
this
is
not
a
very
useful
library
but
I'm
trying
to
get
score.
Some
points
on
interoperability
before
I
get
to
documentation
and
it's
fully
futures
based,
there's
no
polling
going
on
and
I
like
to
leverage
the
type
system
for
all
that
stuff.
B
Since
we
have
this
good
type
system
might
as
well
well
make
use
of
it.
So
there's
no
boolean,
so
it's
all
like
enums,
that's
our
say.
The
direction
for
this
stream
is
Uni
or
by
die,
and
instead
of
it
having
some
kind
of
boolean
that
says,
false
or
true.
I
was
really
satisfied
with
my
85%
coverage
until
Tyler
came
along
and
spoiled
all
my
hopes
for
that.
So
now,
I'll
have
to
do
a
bunch
more
stuff
to
make
it
better.
B
B
So
for
a
server
there's
just
one
socket,
but
you
have
to
manage
a
bunch
of
connections,
so
I've
chosen
to
keep
this
connection
state
object,
separate
and
keep
the
sockets
in
the
client
or
server
instead,
and
that
also
is
actually
nice
for
testing,
because
you
can
just
sort
of
do
all
your
protocol
interactions
without
having
to
deal
with
network
stuff
and
then
there's
the
parameters
module
which
deals
with
the
transport
parameters.
There's
the
stream
stuff
that
has
the
strange
object.
Tls
is
fully
abstract
in
the
sense
that
the
rest
of
the
implementation
doesn't
know
about.
B
B
Draft
12
was
released
this
week,
so
people
will
move
on
soon,
but
I
think
there's
another
interoperability
event.
First,
so
for
that
event,
people
will
mostly
stick
to
draft
11
the
clients,
my
clients,
the
Queen
client,
can
handshake
with
other
servers,
pretty
good,
pretty
well
other
clients
with
Queen
server,
not
as
well,
because
I
made
some
simplifying
assumptions
that
were
turn
out
to
be,
and
not
so
interoperable.
B
Most
implementations
don't
have
much
in
the
way
of
actual
quick
HTTP.
Yet
so
they're,
just
throwing
HTTP
one
over
one
of
the
streams
or
multiple
of
the
streams
and
in
order
to
be
able
to
test
sort
of
the
lower-level
bits
of
the
protocol,
I
hope
to
keep
this
implementation
moving
forward.
That
depends
a
bit
on
my
free
time.
B
It
is
a
big
job
because
there's
a
lot
of
stuff
to
deal
with,
which
you
may
expect.
If
you're
sort
of
dealing
with
this
whole
thing
that
transfers
bytes
across
the
internet-
and
it's
not
just
doing
the
job
of
TCP
but
also
a
sort
of
reimplementation
of
HTTP
to
so
it
feels
sort
of
like
fractal
complexities
everywhere
you
go
into
detail,
there's
more
to
deal
with,
but
I've
just
been
taking
it
from
the
start
of
the
connection
and
that's
seems
a
workable
approach.
B
There's
one
other
rust
implementation
by
Benjamin,
Saunders
I
had
not
found
it
when
I
started,
my
implementation
or
I
may
have
reconsidered
doing
so.
He
uses
open
SSL
instead
of
Russell's
and
I,
think
he
spent
way
more
time.
Hacking
open,
SSL
to
support
the
extra
stuff
or
the
open,
SSL
bindings
to
Russ
to
support
extra
stuff.
Then
I
spent
on
fixing
Russell's.
So
at
some
point,
I
want
to
consider
whether
it
makes
sense
to
share
more
code.
He
has
a
sort
of
networking,
less
less
core
and
then
a
small
Tokio
layer
on
top
of
it.
B
B
So
if
you
are
looking
for
a
fun
product
project
to
contribute
to
then
consider
this
one
I've
put
some
issues
in
the
repository,
even
if
you
don't
have
much
experience
with
rust
or
networking
protocols,
I'm
happy
to
help
you
get
stuff
done
and
I'll
be
here
it
at
the
conference
for
the
rest
of
the
comfort
for
the
weekend
and
also
the
imple
days
or
if
you
want
to
contribute
some
funding
to
be
able
to
use
this
in
a
real
setting.
Then
I'd
also
be
very
interested
in
talking
to
you.
That's
all
I
have
thanks.