摘要：本文則主要總結(jié)了心悅俱樂部的接入層從文本協(xié)議到二進制協(xié)議迭代過程中的技術(shù)方案，包括協(xié)議規(guī)范安全性等方面的內(nèi)容。在心悅的文本協(xié)議方案中，采用的是對請求數(shù)據(jù)進行模式的加密。包括明文的協(xié)議包頭和密文的二進制流。

歡迎大家前往騰訊云+社區(qū)，獲取更多騰訊海量技術(shù)實踐干貨哦~。

作者：羅廣鎮(zhèn) | 騰訊移動開發(fā)工程師

App與后臺通信通常有采用json等文本協(xié)議或者采用二進制協(xié)議，本文則主要總結(jié)了心悅俱樂部App的接入層從文本協(xié)議到二進制jce協(xié)議迭代過程中的技術(shù)方案，包括協(xié)議規(guī)范、安全性等方面的內(nèi)容。

在移動客戶端開發(fā)中，基本都會需要與服務(wù)端進行數(shù)據(jù)交互。對于一般的App來說，通過http請求，采用json格式的文本協(xié)議進行數(shù)據(jù)通信也就基本滿足需求了。在業(yè)務(wù)不斷增加，用戶體量不斷增長之后，對用戶體驗的要求也越來越高。對于需要進行頻繁網(wǎng)絡(luò)請求的App來說，提高網(wǎng)絡(luò)傳輸性能則是提高App響應(yīng)速度，優(yōu)化用戶體驗的重要手段。因此往往會引入二進制協(xié)議，來減小數(shù)據(jù)包。本文則主要總結(jié)了心悅俱樂部App的接入層從文本協(xié)議到二進制jce協(xié)議迭代過程中的技術(shù)方案，包括協(xié)議規(guī)范、安全性等方面的內(nèi)容。

在http的數(shù)據(jù)請求中，一般會采用json或者xml形式的文本協(xié)議。特別是對于App或者web端的前后臺交互更多的會采用json格式，數(shù)據(jù)量相對xml較小，協(xié)議字段可以增刪改，比較靈活。

心悅App在前期，Native模塊與內(nèi)嵌H5和WEB管理端使用的都是統(tǒng)一的PHP框架后臺，采用的是http+json的文本協(xié)議接入層。

請求與響應(yīng)

App網(wǎng)絡(luò)層發(fā)起http請求時，一般會對http header做一些定制修改，來傳遞一些通用數(shù)據(jù)，通常會在User-Agent寫入一些App和手機的信息，例如操作系統(tǒng)版本、機型、App版本等等，在cookie中寫入登錄態(tài)。

例如：User-Agent：tgclub/4.1.0.63(OPPO R7;android 4.4.4;Scale/480;android;868979027609987)
在文本協(xié)議方案中，不同的網(wǎng)絡(luò)請求可以由不同的請求路徑區(qū)分，路徑格式如下：

http://xxx.xxx.com/xyapp/api/{mod}/{act}?c_ver={version}

version:協(xié)議版本號, 默認當前版本號碼為1.0

mod:模塊名稱

act:動作名稱

如，獲取游戲信息,接口名稱為 game/get_game_info，地址為：http://xxx.xx.com/xyapp/api/g...

請求響應(yīng)數(shù)據(jù)都包含在返回的JSON中，按照與后臺定義好的協(xié)議字段返回。一般建議包括本次操作的返回碼、錯誤碼和具體的業(yè)務(wù)數(shù)據(jù)。心悅App的響應(yīng) JSON 中，包含字段有： - status 返回碼，1成功 0失敗 - data 返回業(yè)務(wù)數(shù)據(jù)，當發(fā)生內(nèi)部錯誤時，會返回字段errcode，例如

{"status":0,"errcode":10002,"data":"簽名校驗錯誤"}：
可以看到，雖然json數(shù)據(jù)的格式已經(jīng)很簡潔了，但它依然把屬性名稱，比如 status和data， 以及大括號，引號這些用于表示數(shù)據(jù)格式的信息也進行傳輸了，數(shù)據(jù)存在較多冗余。

安全性

由于文本協(xié)議結(jié)構(gòu)清晰、意義明確，所以方便解讀，但也存在較大的安全風險。對于App后臺服務(wù)來說，也容易存在API泄漏，第三方客戶端偽造訪問服務(wù)器對我們的服務(wù)或者流程造成安全危害。因此需要一定的安全校驗和加密措施。

首先，接入層要驗證請求的合法性，心悅App文本協(xié)議方案中采用的是校驗簽名的方式來驗證發(fā)來的請求是否來自官方客戶端和是否有效。

HTTP調(diào)用需以GET形式傳遞一下兩個參數(shù)：簽名參數(shù)(sn)和時間戳(time_st)。

簽名參數(shù)的生成方式：首先對http請求中的所有參數(shù)按照參數(shù)名的字典順序排序，參數(shù)名和參數(shù)值拼接成字符串，再用每個設(shè)備獨有的簽名密鑰sn_key對該字符串取md5值得到簽名參數(shù)(sn)的值。其中簽名密鑰sn_key，由后臺根據(jù)用戶設(shè)備id生成，通過簽名注冊接口從服務(wù)器獲取，后臺和客戶端分別存儲。簽名注冊接口則用預(yù)先與App約定好的初始密鑰進行簽名校驗，保證簽名安全性。簽名的參數(shù)包括所有的get參數(shù)和post參數(shù)。后臺收到客戶端請求后用同樣的簽名方式計算sn參數(shù)，與請求中的參數(shù)一致才對請求進行處理。此外，對于時間戳參數(shù)，服務(wù)器會拒絕一定時間范圍之外的請求，防止請求重放攻擊。

例如請求request為：?param_b=1¶m_a=2&time_st=123，sn_key=aaa

那么簽名參數(shù)sn = md5("param_a2param_b1time_st123aaa")

其次，若要保證請求數(shù)據(jù)中的敏感內(nèi)容不被泄露，需要對文本協(xié)議內(nèi)容進行加密傳輸活采用https協(xié)議。在心悅App的文本協(xié)議方案中，采用的是對請求數(shù)據(jù)進行CBC模式的AES加密。AES加密是一種對稱加密算法，同一個密鑰可以同時用作信息的加密和解密。加密密鑰pub_key可以通過簽名注冊接口和sn_key一并返回，后臺和客戶端分別存儲pub_key用于加密解密。簽名注冊接口可以使用客戶端和服務(wù)器約定初始密鑰加密解密，并且這個密鑰只在簽名注冊接口用一次。

經(jīng)過簽名校驗和數(shù)據(jù)加密之后，基本上可以保證文本協(xié)議網(wǎng)絡(luò)請求的安全性。

二進制協(xié)議在網(wǎng)絡(luò)傳輸中也有廣泛使用，具體的協(xié)議也有很多，例如公司自研的jce協(xié)議，谷歌的Protocol buffer等等。
為優(yōu)化App的網(wǎng)絡(luò)請求速度和減小數(shù)據(jù)包大小，并配合接入層后臺往C++框架改造，心悅App的接入層網(wǎng)絡(luò)數(shù)據(jù)傳輸協(xié)議切換成了二進制協(xié)議。協(xié)議數(shù)據(jù)包的定義統(tǒng)一采用協(xié)議頭+業(yè)務(wù)包體(協(xié)議內(nèi)容)的方式，協(xié)議頭中用若干比特位定義協(xié)議版本號、數(shù)據(jù)包長度等信息。

請求與響應(yīng)

在二進制協(xié)議方案中，不同的網(wǎng)絡(luò)請求使用同一域名，后臺根據(jù)請求結(jié)構(gòu)體中的命令字參數(shù)進行路由轉(zhuǎn)發(fā)。由于客戶端的數(shù)據(jù)集合需求比較多樣，后臺則一般為服務(wù)化接口，因此需要支持多命令字請求合并，數(shù)據(jù)一并返回。此外，為進一步減小網(wǎng)絡(luò)傳輸數(shù)據(jù)包，協(xié)議可以考慮進行壓縮，同時為保證數(shù)據(jù)安全性，數(shù)據(jù)加密也必不可少。綜上，心悅App在進行二進制協(xié)議改造時，制定了如下格式的二進制協(xié)議格式：

請求協(xié)議

響應(yīng)協(xié)議

請求協(xié)議的協(xié)議頭中包含業(yè)務(wù)標志、協(xié)議版本號和數(shù)據(jù)包長度，服務(wù)端只處理以業(yè)務(wù)標志開頭的數(shù)據(jù)包。截取協(xié)議頭后，用PkgReq結(jié)構(gòu)體解析協(xié)議頭中指定長度的數(shù)據(jù)包。PkgReq包括明文的協(xié)議包頭PkgReqHead和密文的二進制流。PkgReqHead中會包括客戶端生成的請求序列號，密文的加密方式、壓縮方式等信息，用這些信息解開加密壓縮過的PkgReqBody。PkgReqBody包含通用請求數(shù)據(jù)ReqHead和業(yè)務(wù)請求數(shù)據(jù)ReqBody數(shù)組。ReqHead中主要包括用戶的設(shè)備信息、App版本信息、賬號信息、網(wǎng)絡(luò)環(huán)境等等基礎(chǔ)信息，ReqBody則是具體請求命令字和業(yè)務(wù)請求結(jié)構(gòu)體的封裝。若是多個命令字的合并請求則會有多個ReqBody，而ReqHead只需要有一份。后臺路由層根據(jù)ReqBody中的命令字cmdid將ReqBody中的businessReqBody字段轉(zhuǎn)發(fā)到具體的后臺服務(wù)進行處理。并且ReqHead中設(shè)計了guid字段，后臺會存儲用戶的設(shè)備信息并且給用戶分配唯一的guid，客戶端拿到guid之后，后續(xù)的請求就不需要上報不變的設(shè)備信息字段，只需要上傳guid，后端可以根據(jù)guid按需獲取用戶設(shè)備信息，減小請求數(shù)據(jù)量。

響應(yīng)協(xié)議與請求協(xié)議的整體結(jié)構(gòu)類似，由于響應(yīng)需要返回錯誤碼或返回碼給客戶端，并且存在合并請求，因此設(shè)計了兩層返回碼。在RspHead中有整體返回碼iRet，作為路由層整體的處理結(jié)果；每個RspBody中還有ret，作為該命令字對應(yīng)的后臺服務(wù)的返回結(jié)果。每個RspBody中的businessRspBody在iRet和ret同時有效時才能用該命令字對應(yīng)的響應(yīng)結(jié)構(gòu)體進行解包。

此外，命令字需要定義在枚舉中，命令字命名與協(xié)議中業(yè)務(wù)請求結(jié)構(gòu)體和業(yè)務(wù)響應(yīng)結(jié)構(gòu)體命名保持對稱，如GetSettingRequest對應(yīng)GetSettingResponse，命令字為命令字為GetSetting=1001，便于用命令字進行反射匹配出請求和響應(yīng)。具體的Request結(jié)構(gòu)體和Response結(jié)構(gòu)體示例：

安全性

二進制協(xié)議方案與文本協(xié)議方案類似，都需要考慮數(shù)據(jù)安全性的問題。二進制協(xié)議由于傳輸?shù)臄?shù)據(jù)包是二進制流，抓包并不能直接看到結(jié)構(gòu)體，例如我們采用的jce協(xié)議，必須知道完整的數(shù)據(jù)格式才能解析出原始數(shù)據(jù)。在我們的方案中還采用了https、對協(xié)議中的內(nèi)容數(shù)據(jù)PkgReqBody/PkgRspBody進行先壓縮后加密等操作保證安全性。

在心悅App的二進制協(xié)議方案中，采用的也是AES加密，與文本協(xié)議不同的是采用AES的GCM模式。AES作為一種分組對稱加密算法，需要對明文進行分組，分組長度可為128或256bits，有ECB，CBC，CTR等多種模式，這里不做具體介紹。GCM模式可以提供對消息的加密和完整性校驗，具體原理這里不作詳細介紹，可以參考文章 什么是 AES-GCM加密算法。AES-GCM加密也需要密鑰key、初始向量iv，并且加密之后除了得到密文，還會得到消息校驗碼。在數(shù)據(jù)接收方可以通過這個校驗碼校驗密文是否有篡改。在具體實現(xiàn)中，為增強安全性，iv由請求序列號和key按照一定規(guī)則動態(tài)生成，并將加密得到的校驗碼填寫在協(xié)議包頭PkgReqHead/PkgRspHead中，在解密時需要作為驗證條件。

在安卓客戶端，對數(shù)據(jù)進行加密、壓縮的操作封裝在了NDK代碼中，通過提供so庫的方式給Java層調(diào)用，并且校驗App簽名、應(yīng)用包名，防止反編譯，可以進一步保證了安全性。

對于App和后臺接入層的數(shù)據(jù)交互，不管是長鏈接還是短鏈接，其數(shù)據(jù)協(xié)議都可以存在文本協(xié)議和二進制協(xié)議兩種類型。文本協(xié)議直觀、描述性強，容易理解、便與調(diào)試，并且協(xié)議修改方便，但是數(shù)據(jù)冗余較多，安全性稍差；二進制協(xié)議格式精簡、冗余數(shù)據(jù)少，竊聽成本更高，但是數(shù)據(jù)不直觀、調(diào)試略微復(fù)雜，使用、升級維護都需要約定好規(guī)則，各有優(yōu)劣，因此可以根據(jù)不同的使用場景確定不同的方案。

問答
DevMaster與DevOps區(qū)別與作用?
相關(guān)閱讀 
移動互聯(lián)網(wǎng)IM之協(xié)議設(shè)計
http超文本協(xié)議，讓http不再難懂
http超文本協(xié)議，讓http不再難懂(二)

此文已由作者授權(quán)騰訊云+社區(qū)發(fā)布，轉(zhuǎn)載請注明文章出處

原文鏈接：https://cloud.tencent.com/dev...