hyper-ish 2021 in review
In January 2021, Carl Lerche and I presented a talk for re:Invent, Next Gen networking infrastructure with Rust and Tokio. It gives a good overview to someone who isn’t already using Rust.
The very first commit of the year to hyper was the initial C API, but I’ll save more about that for its own section. The number of unique contributors grew 10% from 2020, with a total of 47 humans helping fix code, examples, and documentation in 2021. We introduced two new core members working on hyper-related projects.
All those contributors helped with 14 hyper releases. Those releases includes HTTP/2
CONNECT support. The client can now understand HTTP/0.9 responses. There were performance improvements adjusting HTTP/2 adaptive window pings, and the memory used with the flatten write buffer strategy.
I’ve been working on a plan and vision for hyper, and that should be finalized in January 2022. 1.0 is coming!
hyper in curl
We started working on a C API for hyper in 2020, to allow curl to use hyper as an HTTP backend. At the start of 2021, the core of that API was merged. We hosted a webinar explaining why and how it was working, and I wrote a bit more about the effort on the AWS Open Source blog. As I said then:
Considering how much curl is used, this was an opportunity to make the internet safer.
We’ve since added a few more features and knobs to the C API of hyper. The documentation is now rendered. And we got an RFC for
cargo rustc --crate-type approved, and there’s now nightly support. This will allow turning on the C library at command-line time, instead of being always-on in the
In curl, the number of test cases left to port keeps shrinking. A couple need some future work in hyper, but most just need some help updating curl’s internals. Whittling this list down to zero is an important step in getting curl built with hyper into people’s hands. It’s so close!
Also as mentioned before, we’ve been working on an HTTP/3 library in the similar vein as
h2, which is generic over any QUIC implementation.
At the end of 2020, we had a working-ish client example. Thanks to the hard work of Jean-Christophe Begue, we now have a working server example. The client example fully works. The project updated to Tokio 1.0, and quinn 0.8: working with “final” version of the h3 specification. It gained proper control stream support, and reduced copies when reading from the transport.
Look forward to an initial release in early 2022, and exploratory support in reqwest.
Tower is a library of modular and reusable components for building robust networking clients and servers. At its core is the
Service trait, which just an abstraction of an async function turning a request into a response. You can describe a lot of things with this trait. And it’s been our goal for years that the ecosystem can swap out HTTP implementations by just being generic over any HTTP
Tower is more than just that one trait, however. With that basic abstraction in place, Tower includes a lot of middleware that is useful in all kinds of networking, regardless of protocol, whether server or client.
David Pedersen jumped into the fray to help make Tower so much more. The blog post “Inventing the Service trait” helps explain the why: why have a
Service trait, and why does it look the way it does. Afterwards, the tower-http library, which was just a few HTTP-specific middleware with rough edges, was expanded, polished, and shined to a nice finish.
Then came Axum. Axum is a Rust server framework designed to extend from Tower and Tower-HTTP. While warp was always able to work with Tower, it’s main
Filter API was very opinionated, and felt foreign to those less-used to functional programming. Axum lives next to warp, more fully embracing the
Service, and using a much more common
In the second half of 2021, several of us worked a lot on a really exciting tool that will help debug asynchronous applications. In December, we launched the first release of the Tokio Console. It’s built on top of some familiar technologies, such as
tonic), and a scheme for any runtime to report events about tasks and resources.
It should be especially useful for service developers, such as those using hyper for their server, as it will provide insight into how the async tasks and resources (mutexes, semaphores, channels, sockets, etc) are behaving. It can help find tasks that are stuck, or slow, or inefficient.
hyper-ish, if you will. ↩︎