本文原版本為官方英文文檔，詳情見官方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)頭或主體塊組成的幀绎橘⌒菜铮基于行的協(xié)議由換行標(biāo)記描述的字符串frame組成。在這一點(diǎn)上称鳞，我們不是處理一個(gè)原始字節(jié)流涮较，而是處理一系列的frame值。在Tokio中冈止，我們有時(shí)將幀的全雙工流稱為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)答層熙暴，一般是程序邏輯開始的地方苫亦。對(duì)于一個(gè)客戶端，這一層怨咪，一個(gè)請(qǐng)求發(fā)出時(shí)屋剑，他會(huì)轉(zhuǎn)換成一個(gè)或多個(gè)Frames，寫入Transport诗眨。然后唉匾，從這個(gè)Transport中讀取匹配原來請(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)用程序也許通過許多不同的協(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)行一一抽象荚恶。
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 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類型，通常是一個(gè)枚舉善榛，然后實(shí)現(xiàn)了一個(gè)transport辩蛋，實(shí)現(xiàn)Stream和Sink trait來處理這個(gè)Frame類型。Transport解碼和編碼這Frame值為byte stream.可以動(dòng)手實(shí)現(xiàn)也可以使用framed helper.
Later sections coverworking with transportsandhandshakes in particular.
后面的章節(jié)包含處理transport和handshake
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é)議之上钮呀，類似于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)是蚁署，可以寫可重用的中間層組件。
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.
一般來說蚂四，所有之前列出的層都是在庫(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)用依賴很多不同的庫(kù)久妆，提供各種協(xié)議。作為服務(wù)提供出來跷睦，使用futures庫(kù)將所有東西結(jié)合在一起筷弦。
