足球资料库数据/孙祥/nba五佳球/足球直播哪个平台好 - cctv5今日现场直播

首頁 > 知識庫 > 正文

IAP:HTTP的替代者，更快、更豐富
2016-04-20 16:04:48   來源：Jakob Jenkov ，譯者 李建盛   評論：0 點擊：

現如今物聯網橫行天下，大家都在搶奪這塊地盤，技術當仁不讓，創新不斷，從操作系統、到各種層出不窮到嵌入式設備、再到云計算等等，那么是否協議就采用一萬年不變的 HTTP 了呢？

如果我們能夠將所有點今天一個行業的累積的知識來看當今的云計算平臺是什么樣子，但是隨著新技術的迎頭而上，過去的協議和技術能夠適應嗎？而且這些云平臺能夠支持下一代的互聯網－物聯網（IoE）嗎？

對于Jenkov Aps和Worpcloud 有限公司來說，我們也抱著相同的問題，但是我們將此當作一種激勵，并在去年的早些時候聯合起來開發了一個全新的項目：Vstack.co。在過去的2015年，我們分析了當前的大部分的技術棧，從高層次的架構視野，到具體的實際技術如數據庫、查詢語言、消息隊列、備份解決方案、分布式計算模型、乃至于網絡協議。

當然，分析和驗證概念是一個需要持續進行下去的工作，但是通過過去一年的努力，我們還是有了一些個階段性的結果的，即從現有的云平臺的技術棧看到了明顯的不同。事實上，我們發現今天的互聯網技術有多個是可以用更好的技術取代的。

我們的項目的最終結果是否能滿足我們的期望，現在下結論還言之過早，因為該平臺還沒有完全開發完畢。在開發的過程，我們更改過多次設計，并從中學習到了很多，但是，目前的設計算是穩定的了，我們認為是時候拿出來和開發者們一起討論下了。

我們無法在一篇文章中講所有的架構都描述清楚，也無法做到討論到所有的細節，因為甚至有些部分僅內部可見。因此，本文僅專注于我們的架構中的一個核心概念，IAP，即我們所建議的替代 HTTP 的協議！

IAP－互聯網應用程序協議

互聯網應用協議（IAP）意在為 Web 3.0 提供一個通用的網絡協議。我們認為互聯網應用協議的適當標準化對于應用程序來說就像是USB設備對于PC和外設這樣的結果，設備和應用所鏈接的網絡可通過鏈接到互聯網來進行互動。

IAP還尚在開發中，但核心部分已經可以正常工作了，IAP規范目前的版本可以從這里找到。

IAP 實現了 HTTP 在1.1版本中所忽略掉的一些用例，雖然確鑿無疑的是 HTTP 2.0 和 WebSocket 也實現了 HTTP 1.1所沒有實現的，但我們依然認為有必要再進行補充，關于具體原因，我們曾經在博客專門撰文解釋過：為什么 HTTP 2.0和 WebSocket 依舊不夠用？

IAP 是基于自由流動的消息的協議。通信的節點交換信息，一如 HTTP 的請求和響應機制，然后，IAP 對每個消息必須都得響應沒有要求，作為自由流動的協議，IAP 僅指定交換消息的節點。消息可以作為通信節點看到適合于通信的目的在網絡連接的兩個方向自由流動。我們在教程：IAP 消息流對核心的消息流有更為詳細的描述。

為了能夠推動 IAP 的順利完成，我們以為已經到了在社區征求大家的討論關于替代 HTTP的時機了，并希望能夠獲得一些解決方案的建議，實際上，本文將會聚焦于 ION，在 IAP 中使用的二進制對象符號，我們之所以這么做是基于下面三個原因：

首先，ION 的規范已經非常的接近穩定版了，相對于 IAP 的規范則還差很遠，因此從 ION 入手討論更有實際意義。

第二，ION 可以獨立于 IAP 之外使用，這也就是說用戶可以基于 HTTP 來使用 ION，相比于 HTTP／JSON 的組合性能會有所提升，當然這里指的是不是瀏覽器的通信。舉個實際的例子，如移動 app 和用戶的后端的通信，或者是后端對后端對通信。

最后，ION 對于 IAP 最終的使用會有很大的影響，所以在 IAP 規范完成之前，理解了 ION 這樣基本的 IAP 消息結構會為用戶帶來足夠的理由和信心：對 IAP 最終的期待。

ION介紹

正如我們在上文提到過的，IAP 是一種基于消息的網絡協議。所有的 IAP 消息均為被編碼為一種稱之為 ION 的二進制格式中；即 IAP 對象符號的縮寫。使用二進制的理由是相比于文本數據格式如 XML 和 JSON ，能夠攜帶更多的消息和更加快速的解析速度。

ION 是一種 TLV （類型、長度、值）的格式。每個 ION 包都會包含它都類型、長度和值，我們在這里規范了 ION 編碼的更多細節。

對 ION 對編碼和對二進制表示的格式 CBOR 和 MessagePack 的編碼，但是 ION 在某些方面和它們這些完全是背道而馳的。首先，無論是 CBOR 還是 MessagePack 均是古老的設計為 JSON 的二進制表示，只是增加了攜帶裸的二進制數據的能力（比如：文件）。

ION 的被設計為通用目的數據格式，用于建模以下常見的數據結構:

  • 原始字節（文件）
  • 二進制原語（布爾、整型、浮點、UTF－8字符、UTC 日期）
  • 獨立值的流（未綁定）
  • 獨立值的數組（綁定）
  • 映射（鍵值對）
  • 對象
  • 循環引用對象圖
  • 表

這些結構是可以相互嵌套的，例如，你可以通過嵌套表來建模一個緊湊的對象樹。這些基本的數據結構可以建模為 JSON、XML、CSV 或者是裸的二進制數據，而且你可以實際的將至轉換為 JSON、XML、或 CSV為 ION，并且也還能夠再轉換回去。

表

在 ION 和 MessagePack／CBOR 之間最為顯著的區別的就是表格式數據的緊湊表示，例如：

  • 同一類型的對象數組
  • 數據庫表
  • CVS 文件

能夠代表表格式數據的緊湊的好處就是性能、帶寬和內存的使用情況。我們的測量表明，ION表的數據量往往比序列化到JSON對象數組相同的數據小50-80％，同樣的，典型的ION 表要比相應的 MessagePack 或 CBOR 編碼的數據要小上 25%～50%。多數的服務發送和接收列表的結果都是從網絡上進行的，所以這在常見的情形下能夠會影響到性能。

讀取和寫入 ION 表的速度 要比相應的讀取和寫入 Jackson／CBOR 的速度高出2.75倍，要比相應的讀取和寫入 Jackson／JSON 的速度高出5倍。

靈活的對象

ION 另外一個與 JSON、MessagePack、和 CBOR不同的是，ION 對象可以包含應用程序看到的適合的任意序列的 ION 字段。ION 對象，和 JSON一樣，可以包含名稱、值的屬性，但是它也可以包含其它混合序列的字段。舉例來說，一個 ION 對象包含了一個 UTF－8 的字段序列，而且 ION 對象字段中是XML文本節點與XML元素混合。

ION 對象只能限于屬性值，這樣的結果就是能夠非常緊湊的表示一個單一的對象，而且可以實現讀寫的速度匹配谷歌協議緩存（快寫、慢讀），但是卻擁有了釋放模式的優點還不需要對 Protobuf 的數據大小的原因說明。（Protobuf 承認其是一個對于文件等裸子節的編碼不是最好的）

欲使用 ION 對象只能包含屬性值需要你了解對象內部的字段序列，這或許對于公開的 API 不是一個好主意，但是對于緊耦合的、需要高性能的內部服務來說，此功能非常的有用。

任意層次的瀏覽

在早些時候提到過的基準測量是在 Java 對象中讀取 ION 的速度，以及寫 Java 對象到 ION中，然而為了達到最大的速度，取代 ION 解析為 Java對象，我們建議直接在二進制的表單中消化數據，記住，ION 就是被設計為如此用的模式的。

所有的 ION 字段都包含了以字節表示的字段值的長度。首先，以字節的方式知道 ION 字段可以讓從二進制數據中提取值變得更加的快速和容易。你不需要去檢查（解析）值的每個字節來看它在哪里結束，就如在諸如 XML 或 JSON 的文本格式所做的那樣。第二，知道字段值的字節長度可以讓不打算處理需要忽略的任何字段都更加的容易和快速。

任何的 ION 字段都可以包含帶有同樣包含其值的字節長度的ION 字段（諸如對象、表、以及數組 ），這可以讓忽略掉一整個對象樹的“分支”更加的容易和快速，還毋需解析內部的字段。這就是我們所說的“任意層次的瀏覽”的含義：你可以快速而輕松的內外瀏覽類樹的數據結構。

任意層次的瀏覽是 ION 所提供的明顯比 MessagePack 和 CBOR 改進的一塊內容，從編碼來說僅僅是很細微的不同。在 MessagePack 中，元素可以包含嵌套的元素列表包含元素內的元素數量 － 不是字節的數量。所以若是在 MessagePack 或 CBOR 中要忽略掉嵌套元素中的元素的話，你需要遍歷整個嵌套的元素直到找到所包含的元素。

我們曾經創建了一個簡單的讀取－使用的基準，來展現使用之前的解析 ION 數據為對象和直接在二進制表單中使用 ION 數據的不同速度。此基準讀取一個擁有10個對象的表，每個對象的屬性就是類型的長度，計算它們的和。

第一個版本的基準是在一個 Java 對象樹（通過我們的 Java 反射 API）中讀取 ION 數據，這是在計算長度屬性的和之前。第二個版本的基準是直接從裸的 ION 數據中計算長度屬性的和。

直接從裸的 ION 數據中計算長度屬性的和要比通過基于反射 API 先解析到 Java 對象快10倍。大約比使用谷歌協議緩存（其亦會解析 Protobuf 消息為 java 對象）快3倍，大約比使用解析 JSON 為 java 對象和使用對象（使用 Jackson 的基于反射的 API）快15到40倍。

另外，基準使用了所有的 ION 數據樹，如果計算器僅使用了部分的對象樹的話，在解析二進制數據到對象和直接使用二進制數據之間的性能改進可能更加的令人膛目結舌。

ION 即文件格式

ION 雖被設計為用于網絡消息的數據格式，但是也可以用作文件的格式。在 VStack.co ，我們不僅將 ION 用于數據文件還用于日志文件。對于我們來說使用單一的數據格式讓我們和數據打交道更加的容易。網絡消息可以寫入磁盤以便于以后用于分析或回復，而且來自文件的數據可以很容易的被包含進網絡消息中。

更多關于 ION 和其它的數據格式的對比內容

我們對 ION 在串行化長度和讀寫的性能方面做過一個基準的細節報告。

我們還做了 ION 和其它數據格式的對比，更多詳情請移步：ION vs 其它數據格式。

IAP 消息結構

IAP 消息是編碼過的一個單一的 ION 對象字段。兩個節點通過 IAP 的交換 ION 對象字段來進行通信，ION 對象字段包含了嵌套的 ION 字段。嵌套的字段組成了消息頭和消息體。

因為 IAP 消息均是 ION 對象字段，一個服務收到一 IAP 消息就會知道此消息的開始的16子節，以及第一個4字節到5字節，整體的消息到底有多長。這就讓服務器很容易去為小型的消息分配合理的內存，激活服務接收大量的小型的消息，最好是利用好其內存。

每個 IAP 消息就是一個 ION 對象字段對于當一個完整的消息到達時更加容易跟蹤。一旦接收到了由 ION 對象字段宣稱的字節數量，就知道了消息的全部已經接收完畢。

我們目前所實現的 IAP 服務器在單核單線程的主機上每秒可以回聲（ping－pong）200K（36字節），其中客戶端是4臺和服務器一樣的物理主機。服務器是常見的硬件盒子，4核的 CPU，Hashwell 架構，內存是 DDR 3。客戶端發送一條消息過來，然后服務端再回復一條。當客戶端接收到了來自服務端的回復后，接著發送下一條，然后服務端再回復，如此反復。

若客戶端將消息管道化了，然后服務端運行4核而非單核的話，我們可以在每秒鐘達到100萬條消息。

因為 ION 對象字段是緊湊的而且容易解析，所以 ION 還比較適應 CPU 和內存有限的小型設備。這一特點讓 IAP 不僅適應典型的 Web 應用和后端服務，還適合物聯網。

IAP 語義協議

嘗試去定義一個單一的網絡協議去適應當前的和未來的用例是困難的，但不是不可能。我們以實際行動去做了，IAP 被設計為由多個較小的協議組成，且可以組合起來使用。這些協議被分為一組核心的協議和一組語義協議。

核心協議規范了通用功能的實現，諸如接受消息、緩存等是如何工作的。此功能在網絡協議中有著廣泛的用途，提供了跨協議的功能。

語義協議交付了具體的用例實現，諸如文件交換、流、聊天室、VoIP等等，IAP 將會定義一組標準的語義協議，但是更多是會是會用戶提供更加靈活的可自定義的、自己的語義協議。

所有的核心和語義協議都將會使用相同的基本消息結構。很多的語義協議也將會使用相似的通信模式。這也就意味著應該實現一個單一的消息面向用來最多的服務器平臺。如果不是全部，則是核心和語義協議。

核心和語義協議目前為止均為完成實現，但是重大的設計決策已經敲定。我們將會在這兩協議均穩定后在發布。

IAP 傳輸協議

因為一個消息的交換模式或者是單一的協議是無法滿足每一個用例的，那么一個傳輸協議也不能滿足所有。因此 IAP 被設計為運行在 TCP 和 UDP 之上。最終看起來會是什么樣的情形，現在還無從得知，但是我們正在努力的實現。

IAP 常見的問題

對于我們來說，此文并非是第一次和廣大的開發者們討論 IAP的，下面的幾個小節是一些個原來我們收到的反饋和回復。

一個二進制的協議是難以調試的

這是實話，一點都沒有錯。但是，首先，多數都數據庫都使用專有的、二進制的協議來在數據庫服務器和客戶端 API 之間傳輸數據，為什么就沒有聽到任何的人們抱怨這些數據庫？

第二，ION 是可以被轉換為 XML ，且逆向也是可行的，還不回丟失任何的數據，這也就意味著你可以將 ION 消息轉換為 XML，然后使用文本編輯器將其打開，甚至在修改過后再將之轉換為 ION ，用于單元測試、調試之類的，至于 ION 和 XML 之間的互通目前暫時還沒有實現，我們期望能在今年的第一個季度將此功能實現了。

當使用 ZIP 來壓縮數據時緊湊與否已經無關緊要

一個比較普遍反對緊湊數據的是你可以只需在線路中使用 ZIP 壓縮即可。然后，因為 CRIME 和 BREACH 攻擊的原因，目前建議不要在加密的線路中（TLS／SSL）中使用數據壓縮。從這個角度來講，ION 的緊湊表編碼做了很明顯的差異。

即便是這樣，如果所有的這些 JSON 字節都做 ZIP 壓縮，它們最終還是需要解壓縮并做解析的，這都是需要消耗 CPU 的。ZIP 壓縮可能會降低數據的傳輸時間，但是它會增加解析的時間。即使是增加的量較小，但仍然是不必要的。

IAP 以及 ION 還沒有達到可用于生產或成熟可用階段

嗯，目前 IAP 和 ION 并沒有大規模的使用，就像 HTTP 或 JSON 那樣被實際證明是可行的。盡管如此，我們還是決定將內部的應用使用 IAP 來替代了 HTTP，所有 VStack.co 平臺核心數據的出入都將會基于 IAP，如果 IAP 或 ION 有什么問題的話，我們肯定能第一時間發現。

一種實現并不能滿足所有的需求

當然不能，這也是我們為什么將 IAP 設計為簡單點核心消息架構可擴展的，用來適應不同的語義協議。

你看過或比較過其它的格式嗎？

我們收到很多關于此問題相關的內容。我們將 ION 和 JSON、MessagePack、CBOR、以及 Protobuf等均作了比較，更進一步，我們從 Cap’n Proto、Avro、Thrift 等身上學習了很多。編碼本身并沒有不同，所以速度需要去比較，而且更多的是依賴于實現而不是格式。

然而，我們為 ION 所做的一個不同于其它的如 Cap'n Proto 或 Protobuf 等的地方在于 ION 是自描述的。這也就意味著你直接從 ION 文件中得到具體意義而無需特定的模式。這對于能夠讓 ION 的消息路由到并不知道消息的模式的中間節點很有必要。

自我描述的特性讓 ION 消息有一點點大還有解析起來還有一點點慢，但是它讓 ION 更加的容易使用。你可以賦予數據和日志文件意義而無需知道日志消息寫入到何種格式。你毋需擔心丟失模式，或是將模式存放在文件的頭部來防止丟失。你甚至可以將 ION 消息轉換為文本格式以及再轉換回來，根本就不需要知道模式。

更進一步，如果你需要進一步增加傳輸速度，你可以精簡 ION 的元數據，這樣你的消息的大小就非常接近需要模式（例如，Protobuf）的數據格式了。即便如此，你依然可以賦予 ION 消息中數據以意義，因為每個領域仍明確標記為二進制數據。

IAP 工具

我們就和 IAP 及 ION 打交道的開放的 API 叫做 IAP 工具。目前為止，我們僅實現了 Java 的版本，我們正在開發 D 和 C＃ 語言的 IAP API，如果事實證明這些是成功的話，我們會再考慮遷移到其它語言。

你可以從這里下載到針對Java到IAP工具。

代碼目前還不能用于生產環境，但是已經足夠可以讓用戶在自己的系統中能夠和 ION 打交道并作前期的評估了。我們期望能夠在今年的第一季度交付 ION 相關的代碼。至于 IAP 的部分則需要稍長一些時間。

另外一個被認為是支持 ION 的工具包是：QBit（由 Rick Hightower 所牽頭），QBit 是一個高速的微服務工具包，QBit 服務的內部通信通過消息來完成，如今，QBit 服務通常使用 JSON 來作為消息的格式，使用 ION 來替代 JSON 將會獲得更小的消息、更快的讀／寫以及更加靈活的數據結構選擇。

我們需要你的反饋

我們非常希望能夠聽到你對新的協議的看法。我們已經收到很多開發者們對于HTTP的抱怨；請告訴我們你為什么這么認為，以便于我們開發的IAP能夠解決你的問題。

一個新的網絡協議意味著需要寫很多新的軟件，但是它也能夠開辟許多新的可能性－尤其是如果我們可以做出比HTTP更加通用的網絡協議的話。

關于作者

Jakob Jenkov 是一名承包商、作家、亦是一名開發者，他是Jenkov Aps(http://jenkov.com)的創始人兼CEO，同時也是VStack.co（http://vstack.co）的創始人兼CTO，他的站點（http://tutorials.jenkov.com）包含了750多篇關于技術的文章。

Jakob從1997年就開始了自己的Java程序編寫生涯，他是在哥本哈根的IT大學里獲得的信息技術學士學位的。

查看英文原文：IAP: Fast, Versatile Alternative to HTTP

相關熱詞搜索：IAP Fast HTTP Alternative 數據科學 XML JSON 標識語言 Java HTTP W3C

上一篇：Hadoop Summit 2016會場回顧（二）
下一篇：如何為你的開源項目選擇一個具有品牌效應的名稱

分享到： 收藏