In recent days, QUIC is hot. As the following blog posts describe, the standardization of QUIC is now in the final stage and h3-29 (HTTP/3 over QUIC of draft 29) is out there:
- Chrome is deploying HTTP/3 and IETF QUIC
- How Facebook is bringing QUIC to billions
- A Last Call for QUIC, a giant leap for the Internet
These blog posts motivated me to explain my plan for "Haskell QUIC" to the Haskell community. As I described in "Implementing HTTP/3 in Haskell" and "Developing QUIC Loss Detection and Congestion Control in Haskell", Haskell QUIC servers can communicate with Firefox Nightly and Chrome via HTTP/3. Also, as you can see in "IETF QUIC Interop Matrix", the interoperability has been tested with many other QUIC implementations.
After QUIC drafts will be published as a set of RFCs, I will release several Haskell libraries in the following order:
- tls to provide the
Netork.TLS.QUICmodule - http2 to provide necessary functions for QPACK and HTTP/2 client library
- quic to provide QUIC core features
- http3 to provide HTTP/3 client/server libraries and QPACK
- warp-quic to glue QUIC with WAI (Web Application Interface)
- mighttpd2 to provide HTTP/3 server
I expect that this would happen in April 2021. For the 2nd half of Japan fiscal year of 2020 (Oct 2020 - Mar 2021), I'm planning to tackle the followings (in no particular order):
- Error handling -- the current error handling is really poor
- QPACK encoding with the dynamic table -- the current implementation only makes use of the static table
- Generic Segmentation Offload (GSO) -- see "Accelerating UDP packet transmission for QUIC" and "Can QUIC match TCP’s computational efficiency?"
- Improving the performance of AES-GCM in cryptonite -- see "fusion AES-GCM engine"
- And more testing!
