Quic protocol support

[6D65]

Any plans for supporting QUIC?

It seems that currently QUIC doesn't have a lot of changes over HTTP2(same HPACK, same semantics) layer, instead its main focus it's to improve upon TCP, by replacing it with UDP. I wonder if you've thought about it? I'm searching for a high performance QUIC/HTTP2 webserver.

I guess, ideally, it would be only a matter of swapping the TCP under the current HTTP implementation, with QUIC's UDP replacement. But I guess it isn't that easy? Isn't it?

How would you do it if you were to work on it?

Thanks.

[kazuho]

That's an interesting question! If I were to work on the issue, I might do like as follows:

1. to lib/http2/connection.c, add if statements surrounding h2o_socket_read / h2o_socket_write to switch bet. TCP and QUIC
2. perform all the UDP reads on a dedicated thread and dispatch them to the worker threads by using h2o_multithread_queue_t (a good example of the interthread messaging system can be found in lib/common/hostinfo.c)
3. the sending function should run within each worker thread (by obtaining a lock) directly calling sendto, or push data onto a send queue if the send buffer is full (i.e. after a partial write or EWOULDBLOCK)
4. the event loop should start polling for write when the send queue becomes non-empty, and write the data in queue when the socket becomes ready

[indeyets]

https://github.com/devsisters/libquic

[kazuho]

Thank you for the info! Looks interesting.

[futursolo]

http://tools.ietf.org/html/draft-tsvwg-quic-protocol-00

The first version of QUIC draft has released.

[kazuho]

Now that the protocol implementation has become a standalone library (see https://github.com/google/proto-quic) it would be easier to integrate it to H2O.

[zwoop]

The QUIC libraries based on Google's Chromium code are not thread safe though. Does that cause a problem for you ?

[kazuho]

@zwoop That's an interesting point. Thank you for bringing it up.

I think we need a dedicated thread (or threads, if proto-quic permits) receiving incoming UDP packets and then dispatch them to the connection handlers running on different threads, considering the fact that in QUIC it is impossible to bind incoming packets to the threads that accepted the connection (the way we do for TCP).

[bradjonesca]

FYI: A QUIC server implementation in pure go (under heavy development) https://github.com/lucas-clemente/quic-go

[GuacheSuede]

@kazuho any further progress on this ?

[Lennie]

Maybe I'm mistaken, but I don't think it would be wise to implement QUIC now. Many parts of the QUIC experiment have been standardized by the IETF now in TLS/1.3. What I think will happen is Firefox is planning to deploy the TLS1/3 standard (draft 18) by default in the upcoming version next month. Chrome has already done so or will do that soon. I could be wrong, but I believe there are only 2 SSL/TLS libraries which support TLS/1.3 right now: BoringSSL (which Chrome/Chromium uses) and the NSS (which Firefox uses). BoringSSL is a fork of OpenSSL. Currently h2o supports building with OpenSSL and LibreSSL. I do not know if the browsers are only able to use TLS/1.3 over TCP or if they also support TLS/1.3 over UDP (Datagram TLS / DTLS) yet. TLS/1.3 over UDP is similar to the experimental QUIC protocol.

Someone needs to go check the facts on everything I mentioned. But it should give you an idea of where we are right now.

[Lennie]

Just found out a few things: at the IETF they also called it QUIC. But it's not the same protocol. It's like the differences between SPDY and HTTP/2.

[GuacheSuede]

@Lennie do you have a source for that ?

[TheDecryptor]

Currently QUIC only uses TLS for the handshake, the actual encryption is done differently. Just being able to run TLS over UDP only gets you a (very small) part of the way.

And H2O is using picotls for TLS 1.3 support, which I think is designed to allow for QUIC support in the future.

[19h]

Any updates to this? QUIC support would be an ineffable improvement to users who have limited bandwidth. Is there any road block that can be helped with?

[TheDecryptor]

There's no QUIC spec/draft to implement yet, the base protocol is still in flux, let alone the HTTP mapping on top of it.

https://github.com/quicwg/base-drafts

They're making good progress on it (Rather interesting to follow), and I think the aim is to be at the draft implementation stage within the next few months. There's also the older "GQUIC" version that Chrome uses, but I think they've already diverged pretty far.

[19h]

I guess that justifies holding off until the protocol specification has materialized -- going with premature Google "experiments" isn't exactly sustainable, looking at SPDY. Thanks for the heads-up!

[xm74]

QUIC became as proposed IETF standard already
https://datatracker.ietf.org/doc/draft-ietf-quic-transport/
So, can we are wait it in H2O soon?

[19h]

It appears to me that @kazuho is working on an implementation: https://github.com/h2o/quicly

[kazuho]

Yes. Quicly is the IETF-QUIC implementation that is going to be used in H2O. We plan to release H2O with IETF-QUIC support (using quicly) as the protocol matures.

The development is going well. We continue to have a good interoperability with other implementations.

[tdtgit]

Can't waittttt. Too excited! But do you have ETA of this release?

[inductor]

Any update? :) @kazuho

[rektide]

News note, HTTP-over-QUIC is now going to be HTTP/3.

[eugene-bright]

Related issue (duplicate): #1910.
I think pull request #1846 should be marked as closing #275 automatically.

[kazuho]

@eugene-bright 👍 done.

[jobs-git]

Collection of some issues about Quic/http3

QUIC lower bandwidth performance than HTTP2
https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/6DxYp9UxkYQ

QUIC High Hardware usage vs TCP+TLS
https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46403.pdf