關注上方藍字關注咱們html
理清頭腦混沌，覺醒心智天地node
Async HTTPweb
async-std 團隊的主要開發者yoshuawuyts，聯合「 協議實驗室」 和 「微軟」的另外兩人，共同發佈了 async http 套件。api
主要分爲三個庫：緩存
1. async-h1 ：流式的HTTP/1.1客戶端和服務器協議實現服務器
2. http-types ：從http服務器（Tide）和客戶端框架（Surf）中提取的可重用http類型，是爲了共享抽象，減小維護多套代碼。微信
3. async-native-tls ：流式TLS客戶端和服務器實現，同時支持async-std和tokio。app
項目看點框架
看點一： 流式設計。像處理「水流」同樣來處理數據流。異步
1. 基於 chunked 來實現了流式傳輸。
Transfer-Encoding: chunked
2. 得益於 Rust 的流處理模型。
在同步Rust中，核心流抽象是迭代器（Iterator）。它提供了一種按順序 出讓（yield）每一項（item），並阻塞了它們。經過將迭代器傳遞到其餘迭代器的構造器（constructors）中來完成組合，從而使咱們可以在不費吹灰之力的狀況下就將全部內容都組合在一塊兒。
在異步Rust中，核心流抽象是流（Stream）。它的行爲與 Iterator 很是類似，可是它不會阻塞每一個 item 的 出讓（yield），而是容許其餘任務在等待時運行。
另外，異步Rust 具備 AsyncRead 和 AsyncWrite 形式的同步讀寫。這些trait 的目的是表示未解析的字節，一般直接來自IO層（例如來自套接字或文件）。
Rust流具備其餘語言的一些最佳特性。例如：經過利用Rust的 trait 系統，它們避免了 Node.js 的 Duplex 流中出現的繼承問題。可是它們還實現了背壓（back pressure，意思是在數據傳輸過程當中有一大堆數據在緩存以後積壓着）和延遲迭代（lazy iteration），從而提升了效率。最重要的是，Rust流容許使用相同的類型進行異步迭代。
參考：
1. https://blog.yoshuawuyts.com/rust-streams/
2. https://nodejs.org/api/stream.html#stream_class_stream_duplex
看點二： AsRef/AsMut 模式應用於多個類型轉換（http-types），來自於web-sys中的實踐。
在 web-sys 中，能夠經過 .as_ref 方法來獲取任何一個 父 class 的引用
而在 async-h1 中，對於全部的Request也實現了AsRef<Url>, AsRef<Headers>。這種 「AsRef 模式」讓咱們能夠實現「近似於OOP那樣的」繼承關係。
看點三： 專門權衡開發體驗和性能的API設計。
看點四： 將 HTTP 狀態碼和錯誤類型相關聯。
對於「分裂生態」言論的迴應
介於Rust社區有人一直在說「async-std vs tokio」致使生態分裂的言論，該文章裏也有迴應：
-
在公共領域分享發現並非分裂行爲 -
async-std團隊只是在嘗試和改進新的解決方案 -
然而，用 「 咱們vs他們 」 的言辭煽動爭議纔是「分裂社區」 -
感謝 hyperium/http 團隊的貢獻，async-h1使用了優秀的httparse庫。 和他們走上不一樣的道路，async-std有足夠的理由，就算有競爭，也是健康的競爭。
（我的觀點：只是多種解決方案而已，不表明分裂，由於它們仍是共同秉持着 Rust 的理念和原則。async-std 和 tokio 都是不錯的表明。）
下一步動做
1. 討論 async-h2 中。
2. 等待 tide 發佈 1.0 。tide 是一個基於 async-std 的異步 Web 開發框架，目前tide 已經 0.6 版本了。
武漢加油，中國加油，你們加油
本文分享自微信公衆號 - 覺學社（WakerGroup）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。