WebSockets support over HTTP/2

core
1

I just read this article on Hacker News and learnt that WebSockets support has been added to HTTP/2 in RFC 8441, which was just published last September (2018).

This sounds like something that could be implemented in Meteor that would significantly improve webapp responsiveness.

Support for RFC8441 was introduced into the module nghttp 1.34, which was incorporated into Node.js v10.12.0.

9 Likes
2

Sounds like if we upgrade to Meteor 1.9 we’ll have a version of Node that supports HTTP/2. so, how would we go about testing it?

2 Likes
3

Should hopefully be as simple as replacing:

import { createServer } from 'http';

with

import { createServer } from 'http2';

I’ll give it a shot in a local project and see how it goes

EDIT: Doesn’t crash, but only returns 503 Unexpected error.
EDIT2: Might have something to do with https, since no browser supports http2 without TLS…
EDIT3: Also looks like the Http2Server class doesn’t emit upgrade events, which SockJS needs for websocket support, so all of DDP will be out without a fix…

2 Likes
4

@coagmano did you make that change in webapp_server.js? line 3?

I am new to the Meteor repo so I dont know my around that well. Is there any write ups on the repo structure or anything like that? I would like to compile some notes and make them available if not

Maybe something like if you are looking for X look here or if your looking for y look here. Could make it like a FAQ maybe

5

Yeah, I just looked in packages/webapp since that’s the one responsible for the web server and sure enough a http server is created there.

Although now after searching the codebase for any import or require, the meteor tool starts a http proxy that forwards requests in dev mode, so you don’t have issues when webapp is restarted on a rebuild of server code

So that might have something to do with it too.

Not that I’ve seen anywhere, but I find it fairly self-explanatory.
All the “framework” code that gets pulled into your project is in packages/, and corresponds 1-1 with the packages shown in your local .meteor/versions
It would be nice to see a dependency tree to visualise how they all relate to each other (or not, so you can see what can be safely removed!)

All the build tooling, CLI commands, scaffolds, etc are in the tools/ folder.
I find myself checking tools/static-assets/skel-* from time to time to see what the recommended new config for projects are. These folders are just what you’re given when you run meteor new

Anything else I just use find-all

6

you mean like a nicer meteor list --tree?

thats what i wanted to make, take that output and make a nice diagram that is pleasing to look at haha.

And your right about the repo. Its like packages are self explanatory. And then you have the scripts and tools directory. And I am looking around in the tools directory for now. That and Ive been trying to pay attention to the work being done to watch what gets updated and where. I’ll get the hang of it someday

2 Likes
7

I just mean a diagram of all core meteor packages and how they relate to each other, so it’s easier for community to understand how they inter-relate

8

yea i agee. that would be awesome. I think if i start with meteor list -tree and take some notes from that output i could make something decent. let me give that shot and see what comes of it

1 Like
9

I’d like to bump up this topic again, since we are now on a road to Meteor 2.0 and I’d like to bring this back into discussion.

Would it make sense to integrate this at least in the Roadmap?

3 Likes
10

The way I read what HTTP/2 can do it seems rather unlikely that changing HTTP to HTTP/2 (with websocket support) would make Meteor snappier, quicker, or more responsive. As the linked article states,

The WebSocket connection itself is unchanged between HTTP/2 and HTTP/1 except that the WebSocket frames are wrapped in HTTP/2 data frames (providing the stream id and flags specific to HTTP/2). The only differences are in how the WebSocket connection is established.

…and adds finally:

[Users] should however notice the improved performance in general now that a single HTTP/2 connection can multiplex requests and WebSockets.

There is just one WebSocket connection (per client) in a Meteor application; making the initiation a little quicker would not be noticable. And since there’s just one connection, multiplexing would not happen.

Browsers will simply choose to use HTTP/2 WebSockets if the server advertises support.

For this to happen Meteor needs to advertise HTTP/2 on the server side, but as I said, it is very unlikely to result in a performance gain.

11

For production apps every millisecond counts, so a few milliseconds faster initialization is worth it. Also there is a chance that in apps there might be additional web sockets from third-party packages/implementations, so multiplexing might be useful in those cases. For example Meteor app with native implementation of GraphQL subscriptions without Meteor integration will produce two web sockets. One for Meteor the other for the GraphQL subscription.

Also there is already HTTP/3. A bit early for that one, but good to keep it on radar.

2 Likes