本文原版本為官方英文文檔，詳情見(jiàn)官方http://tokio.rs

網(wǎng)絡(luò)程序一般分為以下幾個(gè)層次:

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將一個(gè)原始的字節(jié)流，并分解成有意義的單位。例如，HTTP由請(qǐng)求頭，響應(yīng)頭或主體塊組成的幀?；谛械膮f(xié)議由換行標(biāo)記描述的字符串frame組成。在這一點(diǎn)上，我們不是處理一個(gè)原始字節(jié)流，而是處理一系列的frame值。在Tokio中，我們有時(shí)將幀的全雙工流稱(chēng)為transport，它實(shí)現(xiàn)了Stream和Sink特性。

A?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應(yīng)答層，一般是程序邏輯開(kāi)始的地方。對(duì)于一個(gè)客戶(hù)端，這一層，一個(gè)請(qǐng)求發(fā)出時(shí)，他會(huì)轉(zhuǎn)換成一個(gè)或多個(gè)Frames，寫(xiě)入Transport。然后，從這個(gè)Transport中讀取匹配原來(lái)請(qǐng)求的響應(yīng)

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.

應(yīng)用層，不關(guān)心請(qǐng)求與響應(yīng)如何映射到一個(gè)Transport中。一個(gè)應(yīng)用程序也許通過(guò)許多不同的協(xié)議接收和發(fā)起請(qǐng)求。一個(gè)Http server應(yīng)用程序會(huì)接收Http請(qǐng)求，然后發(fā)起數(shù)據(jù)庫(kù)請(qǐng)求或其它http請(qǐng)求。

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.

每一層都是在不同的庫(kù)中實(shí)現(xiàn)的，最后，應(yīng)用會(huì)將他們整合到協(xié)議實(shí)現(xiàn)中去，并在request / response應(yīng)答中使用他們。

Tokio’s abstractions map onto these different layers.

Tokio對(duì)上述這些層進(jìn)行一一抽象。

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類(lèi)型，如TCP和UDP。主要工作中byte層，類(lèi)似于std::IO類(lèi)型，但是Tokio類(lèi)型都是非阻塞的。其它部分都是描述上層和低層的處理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首先定義一個(gè)Frame類(lèi)型，通常是一個(gè)枚舉，然后實(shí)現(xiàn)了一個(gè)transport，實(shí)現(xiàn)Stream和Sink trait來(lái)處理這個(gè)Frame類(lèi)型。Transport解碼和編碼這Frame值為byte stream.可以動(dòng)手實(shí)現(xiàn)也可以使用framed helper.

Later sections coverworking with transportsandhandshakes in particular.

后面的章節(jié)包含處理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.

請(qǐng)求和應(yīng)答層在Service trait中被處理。Service trait是一個(gè)簡(jiǎn)單的接口，非常容易以模塊化和可重用的方式實(shí)現(xiàn)網(wǎng)絡(luò)應(yīng)用層，與底層的協(xié)議解耦。這是Tokio基礎(chǔ)抽象之一，處在低層協(xié)議之上，類(lèi)似于Finagle Service, Ruby Rack, Java servlet。

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

通常有兩種方式將request / responses映射到一個(gè)幀流：pipelined或者multiplexing。tokio-proto的目標(biāo)是將transport和處理所需的邏輯映射到一個(gè)服務(wù)實(shí)現(xiàn)。

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

標(biāo)準(zhǔn)的Service接口最大的優(yōu)點(diǎn)是，可以寫(xiě)可重用的中間層組件。

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.

一般來(lái)說(shuō)，所有之前列出的層都是在庫(kù)中實(shí)現(xiàn)的。例如一個(gè)http服務(wù)實(shí)現(xiàn)在一個(gè)http transport中，然后使用tokio-proto將其轉(zhuǎn)換成一個(gè)服務(wù)。

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

一個(gè)應(yīng)用依賴(lài)很多不同的庫(kù)，提供各種協(xié)議。作為服務(wù)提供出來(lái)，使用futures庫(kù)將所有東西結(jié)合在一起。