b8eab381c0
## Motivation
Currently, the `tracing` spans for the client and server handshakes
contain the name of the I/O type. In some cases, where nested I/O types
are in use, these names can be quite long; for example, in Linkerd, we
see log lines like this:
```
2022-03-07T23:38:15.322506670Z [ 10533.916262s] DEBUG ThreadId(01) inbound:accept{client.addr=192.168.1.9:1227}:server{port=4143}:direct:gateway{dst=server.echo.svc.cluster.local:8080}:server_handshake{io=hyper::common::io:⏪:Rewind<linkerd_io::either::EitherIo<linkerd_io::sensor::SensorIo<linkerd_io::prefixed::PrefixedIo<linkerd_io::either::EitherIo<tokio_rustls::server::TlsStream<linkerd_io::either::EitherIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>, linkerd_io::prefixed::PrefixedIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>>>>, linkerd_io::either::EitherIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>, linkerd_io::prefixed::PrefixedIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>>>>>, linkerd_transport_metrics::sensor::Sensor>, linkerd_io::sensor::SensorIo<linkerd_io::either::EitherIo<tokio_rustls::server::TlsStream<linkerd_io::either::EitherIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>, linkerd_io::prefixed::PrefixedIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>>>>, linkerd_io::either::EitherIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>, linkerd_io::prefixed::PrefixedIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>>>>, linkerd_transport_metrics::sensor::Sensor>>>}:FramedWrite::buffer{frame=Settings { flags: (0x0), initial_window_size: 65535, max_frame_size: 16384 }}: h2::codec::framed_write: send frame=Settings { flags: (0x0), initial_window_size: 65535, max_frame_size: 16384 }
```
which is kinda not great.
## Solution
This branch removes the IO type's type name from the spans for the
server and client handshakes. In practice, these are not particularly
useful, because a given server or client instance is parameterized over
the IO types and will only serve connections of that type.
H2
A Tokio aware, HTTP/2 client & server implementation for Rust.
More information about this crate can be found in the crate documentation.
Features
- Client and server HTTP/2 implementation.
- Implements the full HTTP/2 specification.
- Passes h2spec.
- Focus on performance and correctness.
- Built on Tokio.
Non goals
This crate is intended to only be an implementation of the HTTP/2 specification. It does not handle:
- Managing TCP connections
- HTTP 1.0 upgrade
- TLS
- Any feature not described by the HTTP/2 specification.
This crate is now used by hyper, which will provide all of these features.
Usage
To use h2, first add this to your Cargo.toml:
[dependencies]
h2 = "0.3"
Next, add this to your crate:
extern crate h2;
use h2::server::Connection;
fn main() {
// ...
}
FAQ
How does h2 compare to solicit or rust-http2?
The h2 library has implemented more of the details of the HTTP/2 specification than any other Rust library. It also passes the h2spec set of tests. The h2 library is rapidly approaching "production ready" quality.
Besides the above, Solicit is built on blocking I/O and does not appear to be actively maintained.
Is this an embedded Java SQL database engine?
No.