quicker
quicker copied to clipboard
rmarx
Use with express.js?
Hello,
Thank you so much for your work! This is looking like a fantastic library.
My company would like to use QUIC with node.js. We're using express.js. Is there a way to integrate these to get QUIC support with express? I haven't been able to get it to work locally, although I have compiled the special node version and have the example working.
Thanks,
Aaron
Hello Aaron,
Thanks for your interest in this project. Good to hear you've been able to compile the custom node version and things are running!
When you say express.js, I'm assuming you want to use QUIC as a webserver to run HTTP to a normal webbrowser. That is currently impossible (even without express.js), since:
a) there is no HTTP/QUIC implementation in Quicker yet (not even in any of the other iQUIC implementations either, except for ngtcp2 with nghq (see https://github.com/bbc/nghq)).
b) no browser speaks HTTP/QUIC yet (which is substantially different from HTTP/1.1 and /2). Google Chrome only speaks the google version of QUIC (gQUIC), which is 100% incompatible with the standardized iQUIC version that Quicker implements.
The good news: I plan to start an HTTP/QUIC layer in Quicker soon and one of my coworkers will start an implementation in a custom version of chrome in september The bad news: it will take at least until somewhere (early) next year before this is ready for testing and even longer for actual end-user involvement.
If I've miss-assumed your intentions, please let me know, but if I haven't, there's little we can do at the moment :) If you do want to run QUIC in production right now, you should look at gQUIC implementations, available in the Chromium codebase (including toy server), with Akamai (though not publicly yet) and with Litespeed.
Thank you for your a quick reply!
We actually are not trying to go from express.js server to browser, but from express.js server to express.js server just using http as a standard protocol. It's the ease of GET/POST requests, etc. that we're after there. It's somewhat of a distributed system.
So if I'm understanding correctly, we wouldn't be hindered by your point b), but I guess we would still be blocked by your point a)?
I've looked at bbc/nghq. I have to admit, it's pretty well outside of my realm of experience as-of-yet bringing native applications together - you certainly don't have to hold my hand and guide me through it, but do you know if there's a way to bring that library into use with node.js?
Great to hear you're going to start working on HTTP/QUIC - it's an exciting technology and it looks like you're on the vanguard!
Hello Aaron,
Thank you for the clarification. You are correct in your assessment that only point a) is a problem for your use case.
As for integrating bbc/nghq, I personally think that would cost you about as much work to integrate into node as it would to just write the HTTP/QUIC logic yourself in Typescript... it should be easy enough to get nghq built with node and write the C++ wrappers (node has a system in place for native-code plugins that should work well for this), but then to integrate it with Express/streams and iron out the bugs could be quite complex, as nghq is also still in early alpha phase.
This is one of the reasons that I plan to just write the layer directly in Typescript. I expect to start on this soon and I hope to have a testable version somewhere (end of) August, so maybe it's an option for you to wait for that?
At the risk of telling you things you already know: isn't it an option to just use HTTP/2 for server-to-server? While QUIC provides various non-performance related advantages, it's not expected to improve performance that much on typical inter-server (non-lossy/high-bandwidth) networks and most of the performance advantages on those types of networks vs HTTP/1.1 can be gotten from HTTP/2 over TCP as well. If it's explicitly for using new security features, TLS1.3 is also compatible with HTTP/2 (though not all implementations might be up-to-date) and TCP fast open can help with 0-RTT data.
Please tell me more about your use case and I'll keep it in mind when developing the HTTP/QUIC layer.
Nghq doesn't support unicast HTTP/QUIC presently. We welcome contributions but it's a sizeable task to get done. It's also based on older draft 09, bringing it up to speed would require work and you'd have to start a QPACK header compression implementation :)
Hi @rmarx,
Hey, thanks a lot for your attention here, I really appreciate it!
We want to use QUIC for its speed. We will have many servers communicating with many servers, and we want the servers to be distributed all throughout the world. We have a lot of logic that depends on round trip transmission time, and we want a protocol that absolutely minimizes packet round trips from server to server.
We don't think we can use TCP fast open because we want to distribute our application to users, and so don't necessarily have access to the system layer I think we'd need access to for TCP fast open. That being said, I suppose it'd be a similar effort bringing in or writing a native module for that. There does appear to be a PR into libuv to get TCP fast open into node.js, but it's still open, so I do think it'd take effort to include it.
As for writing a QUIC layer in typescript, there actually is a project doing exactly that here. We're hesitant to use that because 1) It's very much a WIP, and 2) We'd like to gain the performance advantages of using a library written in c.
So as it turns out, it actually is not critical for us to have HTTP at all, which is something I learned between now and writing my original comment. So I guess the scope has changed a bit - we really just want fast, reliable UDP based communication. It doesn't need to be HTTP, it can look like sockets or whatever - we have total control over our application layer. We are just shy about using TCP because of all the round trips it requires, especially at the handshake phase.
I hope this all makes sense, I'm really just learning about this stuff now and hope I don't sound like I'm speaking out of anywhere other than my mouth!
So even though Nghq doesn't HTTP/QUIC, we still could use it. Although I am troubled that it's based on an older draft. At this phase of my career, I don't think attempting a QPACK header compression implementation is a terribly wise investment of time LOL.
Alright, I think I'm rambling, sorry. I realize now that we're past both point a) and point b) of your original comment. In fact, I'm wondering now if my needs may even be totally separate from the scope of quicker.
Thanks for taking the time to help me out with all this, it's extremely helpful to me!
Aaron
Thanks @LPardue for your input. A full-fledged implementation with QPACK is of course still a long ways of, a bare-bones HTTP/QUIC unicast implementation POC is what I'm aiming for (with some support for your usecases as well, of course ;))
Thank you for the description @Aaronik, it's a lot clearer now. TCP FO might indeed be a bit more difficult to distribute in this case. The QUIC typescript layer you mention seems to (for now) mainly target gQUIC and also doesn't have an HTTP-layer on top yet (thanks for the link, I wasn't aware of that project). I do have to note there: Quicker is also NOT written in C: most of the code is Typescript and we don't expect it to be anywhere near the performance of the other WIP implementations like ngtcp2 or quicly (at least not in terms of scaling horizontally).
If you don't need HTTP, there are a great many UDP-based algorithms and libraries available for various different purposes (mainly real-time/AV communication or gaming-related), most of them battle-tested. They do vary in what they support in terms of congestion/flow control and security, I think that's were most of the differences with QUIC will be. I think you can get better overall performance with one of those, as QUIC has a lot of stuff in it that you might not need for your usecase. If you do want to stick with QUIC, you can start testing the current implementations (https://github.com/quicwg/base-drafts/wiki/Implementations): most of them allow simple file transfer over HTTP/0.9 and have simple congestion control amenities setup.
I think it will pay of greatly in the long run for you/your company do some comparisons on the available main options before you commit to something. Usability of the interface (e.g., integration into expressJS) should, in my opinion, be one of the last things you look for, if performance is your main goal.
Best of luck with your project. If after a while you decide you want to continue trying quicker, let me know and maybe I can help.
@rmarx sorry my earlier comment was a little unclear. I was talking about any hypothetical improvements to nghq. Since this is the quicker repo, then its not really the home for such discussion.
@LPardue I don't mind a bit of crosstalk, since it's all QUIC related anyway. And I didn't mean nghq in particular but more broadly: it will be quite some time before ANYONE has a full featured HTTP/QUIC layer (I think) and was trying to make it clear to @Aaronik that he shouldnt' expect that from Quicker by the end of August :). Quicker will be aiming for bare-bones, QPACK-less hq support by the end of August, regardless of progress on nghq, that's what I meant.
@rmarx You've been incredibly helpful, thank you so much! Your help has been instrumental in my progress here. Listen, I don't want to spread it on too thick but it's folks like you that make the open source community so valuable!
I'm going to keep pushing towards our dream of having QUIC integrated into our servers. Maybe I'll swing back around in a couple months and see where you're at with quicker. Best of luck!
Aaron