二進制協議與文本協議

二進制協議 VS 文本協議

前言

最近因爲工做上的須要（一方面是與底層與傳感器進行數據交互，另外一方面是對RabbitMQ的AMQP協議的學習），接觸了一些網絡協議相關的內容。正好就二進制協議與文本協議的一些問題簡單說一些。

二進制協議（binary protocol）

概念

協議：就是一組你們約定俗成的契約，你們都遵照。而計算機領域的協議，大多指的就是網絡協議。

網絡協議：計算機網絡中進行數據交換而創建的規則、標準或約定的集合。說直白點，就是你們約定XXX網絡協議下的數據怎麼接收，怎麼處理，怎麼發送等。

二進制協議（Binary protocol）：

Wiki: A binary protocol is a protocol which is intended to be read by a machine rather than a human being, as opposed to a plain text protocol such as IRC, SMTP, or HTTP/1.1. Binary protocols have the advantage of terseness, which translates into speed of transmission and interpretation.
Binary protocol is also used in the context of a protocol between exactly two parties, in contrast to a multi-party protocol. Binary protocol, or binary collaboration have been used in the terminology of standards such as EbXML, HTTP/2 and EDOC.[1] An interface in UML [2] may also be considered a binary protocol.

簡單來講，就是二進制協議在進行網絡傳輸時，傳輸的並非相似JSON這樣的文本文件，而是相似BSON這樣的二進制數據。
（Java中字節流採用的是ASCII碼，而字符流採用的是Unicode碼）

優勢

• 空間佔用小（包括內存，帶寬等）
• 運算規則簡單（如加密就方便）（畢竟來來回回就0和1）
• 可靠性高（不是0就是1，還有校驗和等技術實現驗證。文本協議與之對應的就是數字簽名）
• 部分技術場景實現方便（典型的底層硬件，如傳感器。由於底層本就是0和1構成的數據，不須要轉換）

缺點

• 可讀性差（由此延伸出記憶困難等問題，畢竟位數太多了，還全是0和1，就是機器碼啊。因此協議的每條命令都要有對應的文檔進行細緻說明，包括二進制文件採用的是哪一種編碼方式等）
• 擴展性差（並非不能夠進行消息的擴展，而是已經肯定的數據解析順序，是不能夠改變的）
• 沒法跨處理器（聽說是因爲嚴格的內存到對象的轉換。我的的理解是，因爲不一樣處理器架構存在數據存儲的大端小端問題而致使的。）
• 部分技術場景實現複雜（例如，原先只要經過JSON，就能獲取所需數據。而如今，你首先要獲取二進制流，可能還須要進行拆包與粘包工做，從而得到二進制數據。再根據協議，一條條地解析命令字與數據域。不要問我爲何這麼清楚，說多了，都是淚。以後有機會，會講解一下的）

舉個栗子

TCP：一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議，由IETF的RFC 793定義。

首先，咱們從網絡模型的角度來考慮。TCP位於傳輸層，接收上一層的數據，對數據進行必要的分割，並將數據交給網絡層，且保證這些數據的準確到達（三次握手）。因此，做爲傳輸層的協議，TCP主要任務是傳輸與數據分割。那麼很明顯，採用二進制數據進行傳輸時最好的選擇。傳輸層可以充分發揮二進制協議空間佔用小（帶寬消耗低），可靠性高（提升數據傳輸的可靠性），運算規則簡單（便於數據的分割等工做）等優勢。並因爲傳輸層特性，下降了其缺點所帶來的影響。說到這裏，不得不說層次架構是個好東西，其典型表明的網絡模型，更是如此。其次，瞭解TCP報文結構的朋友想象一下。若是TCP不是二進制協議，而是一個文本協議，那麼其中的TCP Flags，Checksum等的實現會不會變得冗餘，繁瑣。因此，TCP是一個二進制協議。與此同時，TCP協議也是二進制協議的一個典型表明。

其餘：UPD，IP，PPP，Protobuf，MQTT，AMQP等典型例子類比分析便可，再也不贅述。

使用場景

相對於文本協議而言，二進制協議的自定義更具區分度，數量也更多。緣由也很簡單，正如以前所說，二進制協議相對文本協議擴展性更差，可讀性更差，這也就形成其複用性不好。每每不一樣產品，項目間的二進制協議差異也許不大（原本就是比較底層的東西，沒有過高的複雜性），但就是不能共用（也許就是協議中，數據的標示符，命令字等區域位置，長度有所不一樣）。因此，二進制協議的自定義較爲常見。

以自身爲例，我負責的物聯網項目中的終端程序須要與不一樣傳感器進行交互。而大多第三方的硬件廠商並不會採用諸如MQTT這樣的網絡協議，他們每每會自定義一個二進制協議，來與上層通訊（畢竟硬件實現MQTT這樣的標準化協議，也是須要成本投入的）。例如我解決交互的第一個傳感器526，其實經過串口通訊（這個，有點古老）。它的數據幀是這樣的：

很明顯，這樣的規定非常「死板」，Java中，經過RXTX監聽對應串口，並接收數據數組（這裏可能涉及到數據的粘包，拆包工做。固然，若是數據接收頻次不高，而且不是連續數據，能夠經過sleep或wait等來暫停一下，確保數據接收完畢）。以後，根據第三方廠商所給數據幀格式，對命令，數據域進行解析（這裏就必須很死板地根據對應位置讀取對應數據，另外數據域可能採用BCD碼）。最後根據命令字，對數據進行相關操做。

這個時候，咱們再看一下，同一廠商下同一產品線，型號略有不一樣的產品826，它的數據幀與前面的526其實差不過。

可是，二者的區別在於，前者數據域的每一個數據都是三個字節的，然後者則是四個字節的。因此得重寫。固然，若是接入的第三方自定義協議越多，就越好作抽象，從而達到必定的複用（固然，效果確定是不能和文本協議相比較的）。

文本協議（Text-based protocol）

概念：

文本協議（Text-based protocol）：

Wiki:A text-based protocol or plain text protocol is a communications protocol whose content representation is in human-readable format.
The immediate human readability stands in contrast to binary protocols which have inherent benefits for use in a computer environment (such as ease of mechanical parsing and improved bandwidth utilization).

簡單來講，就是文本協議在進行網絡傳輸時，傳輸的是相似JSON，XML這樣的文本文件，而不是二進制文件（就是0和1）

概念擴展：

通常來講，這個時候，就該有人要擡槓了。通常能夠分爲兩種，這裏咱們就HTTP這一文本協議爲例子討論。第一種，有人提出HTTP協議的底層依舊是0和1，它怎麼就是文本協議了。答案就是一個協議是否是文本協議，與它在網絡模型的上下層協議無關，只與自身相關。第二種，有人提出HTTP能夠用來傳輸圖片（寫過相似NODE.JS服務器原始請求，就是返回值類型，須要專門指定。會明白圖片傳輸是採用二進制的），那麼HTTP還能算文本協議嘛。答案就是它是否是文本協議，取決於它是否可以利用文本的格式來進行通訊，很明顯它能夠，因此它是文本協議。這也避免有人拿telnet能進行二進制通訊來擡槓。固然，國外也有人提出是否是文本協議不取決於它可否對二進制數據進行編碼（UTF，ASCII），而是取決於協議是圍繞數據結構，仍是文本字符串。最後，上述HTTP協議是指HTTP1.1，而HTTP2是二進制協議（根據這點，國外那位的觀點，須要稍做修改：在傳輸的數據是否具有數據結構）。

優勢&缺點

二進制協議的優缺點轉換一下就OK了，不在贅述。

舉個栗子

HTTP1.1：基於請求-響應模型，無狀態，無鏈接的應用層協議。

其餘：FTP，TELNET等。

使用場景

乍一看，貌似平時你們開發的協議貌似大可能是二進制協議，什麼RPC，AMQP，就連Kafka都是基於TCP自寫的二進制協議。不過以前就說了，二進制協議缺少複用性，因此可能是確定的嘛。可是用得最多的仍是HTTP這樣的文本協議。平時先後端進行的交互，就是基於HTTP的，也就是文本協議的。通常來講，咱們直接用的都是文本協議，即便涉及二進制協議，也是對二進制協議進行了必定封裝（如kafka的java API，AMQP的API)後的調用。

總結

多數狀況下，不少人能夠寫了好幾年都碰不到幾次二進制協議，可是一旦進了二進制協議的坑（一方面是物聯網中與硬件交互，另外一方面是研究什麼MQ的通訊協議啊），而後就只能說一句，真香。

好吧，開個玩笑。其實兩種協議各有利弊，沒有銀彈，只有適用場景。說幾個主要的考慮點，首先從成本（包含學習成本，時間成本等）來看，文本協議確定是優於二進制協議的，不然，也不會那麼多人不瞭解二進制協議了。其次從效率（包括帶寬等資源消耗，數據處理等）來看，二進制協議確定是優於文本協議的，不然，也不會那麼多MQ採用二進制協議了。而後從可讀性來看，文本協議確定是因爲二進制協議的，固然這也帶來了學習成本（包括熟悉二進制協議，如數據幀等）。最後從擴展性與安全性來看，二進制協議雖然有必定擴展性，致使開發的時間成本上升。但我認爲若是數量較多，造成協議族效果，其實成本也就沒那麼高了（畢竟二進制協議中不少工具是通用的，數量優點也能夠完成良好的抽象）。安全性方面，二進制協議有天生的優點（全是0和1），其編碼規則只有收發雙方瞭解，加解密也方便。