►
From YouTube: Implementing HTTP/2 for Node.js Core by James Snell, IBM
Description
Implementing HTTP/2 for Node.js Core - James Snell, IBM
About James M. Snell
James has spent the majority of his career developing and promoting open and emerging technologies. Today he serves as IBM's Technical Lead for Node.js and as a member of the Node.js Core TSC.
A
Thank
you
very
much,
so
yeah
I
am
James.
Snell
I
am
on
the
the
node
core
team
involved
with
the
the
CTC,
the
TSC
bunch
of
little
acronyms.
Basically,
it's
the
team
that
just
you
know,
focuses
on
node,
full-time
I'm,
very
happy
to
that.
Ibm
pays
me
to
work
on
node
and
every
day,
I
get
to
have
my
hands
in
the
code
all
the
time,
and
this
is
actually
one
of
the
first
talks
in
about
a
year
and
a
half
two
years
right.
Just
get
to
talk
about
code.
A
I've
been
writing
for
the
past
couple
months,
which
I'm
super
excited
about.
I,
don't
have
to
talk
about
organizational
stuff,
which
is
which
is
fantastic,
so
I've
been
looking
at
implementing
HTTP
2
for
node
and
there's
a
number
of
reasons.
Why
we're
looking
at
this?
You
know,
part
of
it
is
just
none
of
the
relevancy
of
the
platform
you
know,
keeping
up
to
date
with
the
standards.
A
The
one
thing
that
I
will
make
clear
right
from
the
very
start
is
that
there
there's
been
no
final
decision
yet
on
the
part
of
the
core
team
that
HB
2
will
absolutely
get
into
core.
The
lot
of
the
effort
right
now
is
deciding
you
know,
trying
to
figure
out.
If
we
were
to
do
this,
what
would
it
look
like
like
how
it
operated?
What
are
the
issues
involved
with
with
actually
doing
an
implementation?
A
We
do
have
a
working
prototype
which
I'll
talk
about,
and
it
assumes
that
it's
going
to
be
in
core
right,
but
it
you
know
we
could
just
as
easily
take
it
out
and
put
it
out
at
the
native
module
out
on
NPM
as
well.
We
just
have
to
figure.
You
know
figure
that
out.
So
a
big
part
of
the
discussion
right
now
is
getting
feedback
from
the
ecosystem
on
what
the
requirements
should
be
and
how
we
should.
Actually,
you
know,
move
forward
with
this.
So
just
keep
that
in
mind.
A
So
node
is
always
has
been
primarily
platform
for
web
application
development,
and
this
is
the
primary
argument
for
why
we
would
do
this
right.
Hp
has
always
been
a
integral
part
of
what
node
is
getting
HP
to
support
in
there
is
is
something
that
just
just
makes
sense
from
that
point
of
view.
You
know:
node
has
this
small
core
philosophy:
it
doesn't
have
a
standard
library
really
the
ships
with
it.
A
Hp
one
support
in
node
right
now
is
very,
very
specific
to
that
protocol.
If
you
look
at
the
internals
you'll
see
like
you
know
in
the
response
object
for
you
know,
when
you
write
data
out,
it's
going
directly
out
to
the
socket
right.
If
you
look
at
the
HTTP
parser
that
we
use
it's,
you
know
it's
very
finely
tuned
to
parsing
the
text-based
protocol
that
HP
u1
is,
and
it's
very
difficult
to
repurpose
the
existing
code
to
support
HTTP,
2
and
I'll
get
into
a
little
bit
on.
That
is
why
that
is
HB.
A
2
is
extremely
different
protocol.
If
you
look
at
the
spec,
it
keeps
the
semantics
of
hb2
request
and
response.
You
have
the
headers
in
the
body,
and
you
know
your
status
codes,
all
the
it's
a
semantic
layer,
they've
preserved
as
much
as
they
could.
But
if
you
look
at
the
actual
the
transport
layer,
you
know
what's
actually
going
out
over
the
wire
hbg,
two
switches
to
a
binary
framing.
A
So
instead
of
using
you
know,
you
know
taking
a
line,
delimited
text
to
say:
okay,
here
are
that
you
know
here's
their
preamble
here
are
the
headers
here's
the
body
right.
What
it
does
is
it
fragments
the
protocol
control
data
and
the
the
request
and
response
payload
data
into
distinct
binary
frames.
Each
frame
has
a
header
and
a
payload.
The
header
is
like
something
like
9
bytes.
It
you
know
has
like
you
know
what
kind
of
thing
this
is
what
what
the
size
of
it
is.
A
A
We've
always
you
know:
we've
had
this
ability
to
pipeline
requests,
so
you
can
basically
queue
up
multiple
requests
and
you
have
to
process
those
in
a
particular
order
and
wait
for
the
responses
to
come
back
in
the
same
order,
and
we
end
up
with
what's
called
a
head
of
line,
blocking
issue
right
and
it's
a
major
performance
bottleneck
when
you're
actually
using
pipelining
with
hb2.
We
don't
have
that
issue
because
of
the
binary
framing.
A
It's
specifically
designed
to
allow
multiple
requests
and
response
flows
to
be
in
flight
simultaneously
without
any
head-of-line
blocking,
and
this
is
accomplished
by
fragmenting
the
data
and
using
a
priority
queue
to
basically
determine
which
bits
are
going
to
be
sent
over
the
wire
at
any
given
time.
Okay,
so
it's
a
very
different
protocol
and
under
the
covers,
there
is
also
other
things
that
hp-2
adds.
A
You
know
that
one
is
still
in
effect,
so
just
assume
that
that
one
is
still
being
used,
but
what
that
ends
up
being
meaning
is
that
HB
1
is
a
fully
stateless
protocol
right.
Hb
2
is
not
when
HTTP
2
sockets
are
long-lived.
You
have
header
state,
you
have
priority
State,
you
have
flow
control,
state,
a
significant
amount
of
additional
stuff,
that's
being
kept
around
for
a
longer
period
of
time.
For
this
connection,
there
is
a
string
prioritization
flow
control
that
operates
independently
of
the
TCP
level
flow
control
and
prioritization.
A
There's
new
extensibility
mechanisms
and
new
new
features,
such
as
push
requests
and
any
kinds
of
things
that
also
be
looked
at
and
taken
into
consideration.
The
bottom
line
is
that
there
are
a
lot
of
new
constraints
right
and
I.
Just
kind
of
went
through.
Some
of
these
I
tend
to
like
not
follow,
slides
very
well,
so
I'll
skip
ahead.
If
I,
do
you
know
it's
just
the
thing,
a
lot
of
new
constraints
that
HP
one
currently
doesn't
have
to
deal
with
a
node
right?
A
If
you
look
at
hv1
implementation
and
core
right
now,
we
have
the
HP
parser.
We
have
the
incoming
HP
response,
outgoing
response,
the
user
code.
Essentially,
when
it's
writing
data,
it's
essentially
writing
it
directly
out
to
the
socket
right.
It's
a
very
streamlined.
Very
you
know
highly
efficient
process
with
a
3-2.
It
gets
much
more
complicated
and
we
have
the
these
abstractions
of
an
HTP
session
and
HP
stream
and
there's
multiple
streams
per
session.
There
could
be
millions
of
streams
per
session
and
what
we
end
up
having
to
do.
A
Instead
of
allowing
a
user
code
to
write
directly
to
the
socket,
we
have
to
completely
isolate
that
socket
and
buffer
the
data
that's
being
written
and
read
to
and
from
the
user
code.
Alright,
so
there's
a
lot
of
additional
work.
That's
happening
under
the
covers
for
HP
to
you
know
the
the
node
would
have
to
manage
here
same
thing
on
the
client
side.
You
know
on
the
client
side,
you
open
it
up.
A
You
can't
write
directly
to
a
socket
and
expect
it
just
to
work
with
HP
to
you
know,
so
you
can't
just
open,
like
a
telnet
session,
for
instance
right
and
test
your
your
HP
server.
You
have
to
have
the
the
protocol
mechanisms
in
place
and
you
have
to
follow
this
sequence
of
this
priority,
sequencing
of
which
frames
are
being
sent
at
any
given
time
flow
control,
all
that
kind
of
thing.
A
So
the
goal
in
the
implementation.
What
all
this
basically
means
is.
We
have
to
write
brand-new
code
within
a
node
that
to
handle
all
this,
we
cannot
use
any
of
the
existing
HP
one
code
in
node
to
support
HP
two.
It's
a
brand
new
protocol,
brand-new
code
path
and
that's
what
we're
basically
working
on.
A
The
idea
is
to
have
two
distinct
supported,
API
levels
and
I'll
kind
of
get
into
this
a
little
bit,
there's
going
to
be
a
low-level
API
that
allows
us
to
work
with
these
sessions
and
the
streams
directly
without
the
HTTP
request/response
semantics.
The
reason
for
exposing
this
is
that
there
are
people
who
are
wanting
to
build
on
top
of
the
HP
the
framing
protocol,
but
have
it
be
other
things
other
than
HTTP?
You
know
ACP
like
like
alternatives
like
WebSockets,
or
you
know,
variations
on
push
streams
and
there's
other
things.
A
A
You'll
have
like
you
know,
HP,
to
create
server
right
now,
very
similar
to
what
users
are
doing
today
in
order
of
priority,
though
the
things
that
we're
really
looking
at,
we
need
the
performance
and
security
to
be
there
right
and
there's
a
lot
of
new
things
that
are
happening
in
in
the
protocol
that
we
really
have
to
look
at.
It's
going
to
take
us
a
while
to
get
this
get
this
right,
so
we
need,
you
know,
need
to
be
patient
with
it
expected
api
compatibility
is
a
huge
question.
A
A
Like
I
said,
it's
a
brand
new
code
path,
so
any
existing
code
continues
to
work
but
as
HP
to
need
to
work
like
HP
one
in
court
right
is
that
what
users
need
we're
still
trying
to
figure
out,
tease
out
those
questions,
the
last
the
lowest
priority
is
actually
exposing
the
new
features
like
if
we
cannot
reasonably
deliver
the
good
performance
or
have
a
good
API
experience
for
users
by
delivering.
You
know.
Having
these
new
features
then
will
delay
our
rolling.
A
You
know
exposing
those
new
features,
so
push
streams
you
know,
may
have
to
wait
while
we
work
on
everything
else,
right
majority
of
the
heavy
lifting
falls
on
the
ng
HP
to
the
library.
So,
if
you're
not
familiar
with
this,
this
is
the
same
HP
to
implementation.
That's
used
by
a
curl
and
in
quite
a
few
others
it
is
hands
down
the
best
implementation
of
HTTP
two
out
there.
It
is
extremely
well
tested,
it
does
almost
all
of
the
heavy
lifting
for
us
in
terms
of
the
state
management.
A
All
we
have
to
do
is
take
the
data
off
the
socket
pass
it
ng
ng.
It
does
most.
You
know
all
of
the
parsing
all
the
state
management,
and
then
it
calls
some
callbacks
for
us
to
tell
us
like
what
kind
of
headers
we
got
and
what
kind
of
body
you
know
what
our
data
is.
So
all
we
have
to
deal
with
are
the
callbacks
on
that
works
really
well
with
libuv
really
well,
with
the
with
the
existing
architect.
Note.
A
And
you
apologize,
this
is
kind
of
difficult
to
read
it's
kind
of
a
high-level
view
of
the
architecture,
we're
going
to
have
an
internal
native
layer,
which
is
where
most
of
the
work
is
happening
and
that
is
going
to
be
exposed
through
the
process
bindings.
It's
going
to
like
process
binding
on
HTTP
to
typically
those
are
unsupported
api's
in
core.
A
These
are
the
things
that
note
itself
depends
on
and
then
there's
going
to
be
a
bunch
of
stuff
written
out
in
jeaious,
which
is
the
higher
level
and
the
high
level
API
as
it
users
will,
will
rely
on
and
build
on.
It's
actually
quite
similar
to
the
way
that
HP
is
currently
structured
in
in
node
it.
It's
not
a
huge
departure.
It
should
be
very
familiar
unless
we
go
down
this
path.
A
Quick
example,
like
I,
said
we
have
a
working
server
right
now,
we're
still
working
on
the
client
bits,
but
the
server
itself
is
very
similar
to
what
node
users
already
do
right.
So,
instead
of
we
require
each
HP
and
leaving
at
that
and
then
doing
HP
create
server
it'll
just
be
create,
secure
server
or
great
server
and
on
using
HP
Mott
HP
to
module.
Now
this
creates
secure.
Server
is
interesting.
A
Http
to
the
spec
does
not
require
TLS
all
right,
but
the
client
of
limitations
in
Chrome
and
Firefox
the
browsers
they
require
to
us.
They
will
not
connect
to
an
HP
2
server
that
is
not
secured
with
TLS,
so
it
becomes
a
practical
requirement.
The
default
position
is
just
it's
a
secured
connection,
all
right,
and
there
are
a
number
of
reasons
for
that.
But
what
this
basically
means
is
you
know
in
in
node,
you
know
the
the
server
will
by
default
be
a
secure
server
right.
A
You
will
be
able
to
create
a
plaintext,
but
that's
not
going
to
be
the
recommended
path,
but
it's
very
similar-
and
you
know
this-
this
boils
it
down.
Just
to
the
basics
like
I
said,
push
stuff
gets
a
lot
more
complicated.
So
for
you
know,
this
is
API
is
temporary,
but
just
create
a
push
stream
and
and
pushes
things
out.
If
you
look
at
performance-
and
this
is
a
just-
a
peak
load
benchmark
a
thousand
requests
as
quickly
as
possible
to
the
server
you
know,
spread
across
50
clients.
A
Eight
eight
worker
threads
right,
the
existing
HP
one
implementation
was
able
to
do
21,000
requests
per
second
under
this
test,
but
the
caveat
of
that
is
that
there
was
a
15
percent
failure
rate
15%
of
the
HP.
One
request,
just
simply
were
not
served
by
note,
and
this
is
like
with
no
changes
to
what's
in
the
core
today.
So
you
know
21,000
requests
per
second,
yes,
but
15
percent
failure
rate
is
pretty
high
with
the
HTTP
you
HP
to
implementation.
This
is
a
third
column
right
here.
A
We're
able
to
get
about
18,000
requests
per
second,
but
a
hundred
percent
success
on
this,
so
we're
handling
more
concurrent
transactions,
slightly
less
transactions
per
second,
the
the
second,
the
second
or
fourth
columns
is,
if
we're
using
cluster,
this
tiny
little
blip
right
here.
Just
by
comparison,
if
you
go
out
on
NPM
today,
there
is
the
HTTP
2
module.
That's
out.
There
is
a
pure
JavaScript
implementation
of
the
protocol
running
this
test.
I
was
able
to
get
about
250
requests
per
second
slight
difference.
A
A
This
is
this
is
why
we're
doing
over
doing
docker?
Ok,
all
right!
So
if
we
look
at
more
on
a
performance
profile,
header
compression,
why
why
are
we
doing
this
right?
Five
minutes
left.
So
this
is
the
orange
column.
Is
the
total
number
of
bytes
sent
on
you
know
through
this
test
right
in
the
first
column,
you
know
we
see
it
with
HP
one.
It's
a
very
chatty
protocol
right
when
you're
sending
a
lot
of
headers
there's
a
lot
of
duplication
in
these
requests.
A
A
The
third
cluster-
that's
the
header
data
that
was
sent
in
this
test
for
HP
to
write,
because
essentially
we
send
those
headers
once
and
we're
using
them
over
and
over
and
over
again
right
wherever
there's
a
duplication,
we're
saving
a
significant
something
like
90
I,
think
I'd,
like
a
96
percent
savings
in
just
the
amount
of
header
data
being
sent,
which
is
significant.
So
there
is
a
trade-off
with
using
staple
header
compression
introducing
state
into
the
protocol,
but
we're
sitting
we're
using
that
connection
far
more
efficiently
than
what
HP
one
can
currently
do
again.
A
This
just
speaks
to
the
motivation
of
why
we
would
do
this.
It
will
make
using
HP
to
in
node
or
using
hm8
HP
in
general
EndNote
far
more
efficient.
Allow
us
to
do
more
with
a
single
with
a
single
instance
right.
So
you
know
just
just
some
details
on
that
with
HP
one
we
were
using
keep
alive
I,
like
I
said
it
may
be
nicely
percent
savings
in
the
in
the
data
header
data.
A
The
these
numbers
is
this
is
a
development
image
like
I've
been
working
on
is
for
two
months,
there's
a
lot
of
optimization.
It
can
be
done
so
we
need
to
just
you
know,
continue
to
to
optimize
this
there's
a
lot
of
things
you
know
in
the
pipeline,
like
I,
said,
there's
a
lot
of
buffering.
That
needs
to
happen.
So
as
we're
going
through
this,
we
need
to
optimize,
and
hopefully
the
numbers
will
continue
to
improve.
A
A
There's
you
know
the
HP
to
has
upgrade
mechanisms
where
you
can
basically
run
HP,
one
and
HP
to
on
the
same
port
right
and
you
negotiate,
which
one
your
you're
actually
using
just
there's
that
there's
client
work,
which
I'm
very
happy
to
say
Google,
is,
is
jumping
in
to
help
with
some
of
that
performance.
Optimization
performance,
testing,
there's
all
kinds
of
stuff.
So
please,
please,
if
you
have
an
interest
in
this,
come
come
help.
We
have
the
repo
no
js'
HP.
A
It
is
a
clone
of
master
of
node
core
I'm
doing
this
as
a
separate
code
stream
right
now,
because
again,
because
the
decision
hasn't
been
made,
whether
this
will
definitely
get
into
into
core
I'm
doing
it
this
way,
so
we
can
at
least
you
know,
get
a
build.
We
can
get
development
images
with
this
support
in
there
and
play
around
with
it
and
develop
it.
So
I
would
love
additional.
You
know
eyes
on
this
and
you
know
folks
helping
out
and
that's
that's
it.
C
A
A
B
A
I
think
that
there
is
still
a
lot
to
be
proven
out
about
the
protocol
right
and
it's
it's
going
to
be
a
while
before
we
can
really
say
you
know
what
aspects
of
it
are
really
going
to
have
a
positive
impact
on
what
aspects
are
just
going
to
be
a
pain
to
deal
with
right.
So
it's
still
very,
very
young,
very
mature,
but
I
think
I
think
we're
heading
in
the
right
direction
for
that
kind
of
stuff.
So,
okay,
okay,.
D
Yeah
on
your
graphs,
I
know,
you
said
the
performance
was,
you
know
early
on,
it's
going
to
change,
but
obviously
http/2
looks
lower
was
using
less
data,
but
requests
per
second
result
is
that
because
those
experiments
were
just
sending
that
request
the
same
way,
HTTP
one
does
and
not
using
these
like
stream
or
push.
Do
you
expect
that
it
you're
going
to
leverage
those
additional
features
in
order
to
surpass
the
RPS
of
HTTP
work?
So.
A
In
this
particular
test,
it
was
basically
just
let's
see
how
many
gets
we
can
do
like
concurrently
on
the
HP
2
test.
Specifically
I
was
basically
throwing
I.
Think
per
per
client
was
12,500
concurrent
streams
over
a
single
socket
right,
just
happening
all
at
all.
At
the
same
time,
the
performance
bottleneck
happens
in
the
context,
switching
that
has
to
happen
between
processing
the
the
individual
data
frames
for
those
individual
requests.
You
have
control
data
frames.
Like
the
header
frames,
you
have
the
data
frames
themselves.
A
You
have
flow
control,
there's
prioritization
I,
think
things
are
happening
each
each
one
of
these
managing
the
context.
Switching
that
has
to
occur
when
you're
multiplexing.
All
of
those
introduces
an
additional
bottleneck
that,
like
node
currently
doesn't
have
to
deal
with
with
HP
one,
and
that's
really
where
the
performance
hit
is
occurring.
We
can
tune
the
performance
based
on
the
number
of
concurrent
streams
that
can
be
opened
at
any
given
time.
A
So
if
I
say
the
max
is
100,
we
get
a
much
different
performance
profile
than
when
I
say
the
max
is
you
know,
12,500
right
and
it
really
comes
down
to
how
quickly
your
server
can
process
the
individual
frames
of
data
and
that's
the
part
that
we're
working
on
optimizing
right
now.
So
hopefully
that
answers
the
question.
Okay,
all
right.