深入理解Tokio——架构设计篇

本文原版本为官方英文文档,详情见官方http://tokio.rs

网络程序一般分为以下几个层次:

Byte streams 层,处在最低层。这一层一般是提供TCP或者UDP Socket.这一层,一般操作byte buffer.TLS使用也是处在这一层。

Framing is taking a raw stream of bytes and breaking it up into meaningful units. For example, HTTP naturally has frames consisting of request headers, response headers, or body chunks. A line-based protocol consists of String frames that are delineated by new line tokens. At this point, instead of dealing with a stream of raw bytes, we are dealing with a stream of frame values. In Tokio, we sometimes refer to a full duplex stream of frames as a transport, which implements both the Stream and Sink traits.

Framing将一个原始的字节流,并分解成有意义的单位。例如,HTTP由请求头,响应头或主体块组成的帧。基于行的协议由换行标记描述的字符串frame组成。在这一点上,我们不是处理一个原始字节流,而是处理一系列的frame值。在Tokio中,我们有时将帧的全双工流称为transport,它实现了Stream和Sink特性。

request / response exchange generally is where application logic starts appearing. For a client, at this layer, a request is issued and a response for the request is returned. When the request is issued, it is turned into one or more frames and written to a transport. Then, at some point in the future, a response to the request will be read from the transport, and matched with the original request.

Request / Response应答层,一般是程序逻辑开始的地方。对于一个客户端,这一层,一个请求发出时,他会转换成一个或多个Frames,写入Transport。然后,从这个Transport中读取匹配原来请求的响应

At the application layer, the details of how requests and responses are mapped onto a transport don’t matter. A single application may be receiving and issuing requests for many different protocols. An HTTP server application will be receiving HTTP requests, and then in turn, issuing database requests or other HTTP requests.

应用层,不关心请求与响应如何映射到一个Transport中。一个应用程序也许通过许多不同的协议接收和发起请求。一个Http server应用程序会接收Http请求,然后发起数据库请求或其它http请求。

Each of these layers tend to be implemented in different libraries, and the end application will pull in the protocol implementations and just interact with them at the request / response exchange layer.

每一层都是在不同的库中实现的,最后,应用会将他们整合到协议实现中去,并在request / response应答中使用他们。

Tokio’s abstractions map onto these different layers.

Tokio对上述这些层进行一一抽象。

Byte streams

tokio-coreprovides the lowest level building blocks for writing asynchronous I/O code: anevent loopand theconcrete I/O types, such as TCP and UDP sockets. These primitives work on the byte level much like thestd::iotypes, except the Tokio types are non-blocking. Other sections describe bothhigh-levelandlow-levelAPIs for working with byte streams.

tokio-core提供最低层异步I/O代码:event loop和具体的I/O类型,如TCP和UDP。主要工作中byte层,类似于std::IO类型,但是Tokio类型都是非阻塞的。其它部分都是描述上层和低层的处理byte Stream的api。

Framing

Framing is done with Tokio by first defining a frame type, usually an enum, then implementing a transport as aStream + Sinkthat works with that frame type. The transport handles encoding and decoding the frame values to the raw stream of bytes. This can either be donemanuallyor using a helper likeframed.

Framing Tokio首先定义一个Frame类型,通常是一个枚举,然后实现了一个transport,实现Stream和Sink trait来处理这个Frame类型。Transport解码和编码这Frame值为byte stream.可以动手实现也可以使用framed helper.

Later sections coverworking with transportsandhandshakes in particular.

后面的章节包含处理transport和handshake

Request / Response

The request / response exchange layer is handled by Tokio’sServicetrait. TheServicetrait is a simplified interface making it easy to write network applications in a modular and reusable way, decoupled from the underlying protocol. It is one of Tokio’s fundamental abstractions. It is a similar abstraction to Finagle’sService, Ruby’s Rack, or Java’s servlet; however, Tokio’sServicetrait is abstract over the underlying protocol.

请求和应答层在Service trait中被处理。Service trait是一个简单的接口,非常容易以模块化和可重用的方式实现网络应用层,与底层的协议解耦。这是Tokio基础抽象之一,处在低层协议之上,类似于Finagle Service, Ruby Rack, Java servlet。

There are generally two ways to map request / responses to a stream of frames: pipelined or multiplexing. tokio-proto’s goal is to take a transport and handle the required logic to map that to an implementation ofService.

通常有两种方式将request / responses映射到一个帧流:pipelined或者multiplexing。tokio-proto的目标是将transport和处理所需的逻辑映射到一个服务实现。

A big advantage of having a standardizedServiceinterface is that it makes it possible to write reusable middleware components that add useful functionality.

标准的Service接口最大的优点是,可以写可重用的中间层组件。

Application

Generally, all the previously listed layers will be implemented in libraries. For example, an HTTP server implementation would implement an HTTP transport, then usetokio-prototo map that to aService. TheServiceis what the HTTP library would expose.

一般来说,所有之前列出的层都是在库中实现的。例如一个http服务实现在一个http transport中,然后使用tokio-proto将其转换成一个服务。

An application would depend on many different libraries, providing various protocol implementations exposed as services, and using thefutureslibrary to hook everything together.

一个应用依赖很多不同的库,提供各种协议。作为服务提供出来,使用futures库将所有东西结合在一起。

你可能感兴趣的:(深入理解Tokio——架构设计篇)