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

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

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

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

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

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

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

請(qǐng)求與響應(yīng)

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

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

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

version:協(xié)議版本號(hào), 默認(rèn)當(dāng)前版本號(hào)碼為1.0

mod:模塊名稱(chēng)

act:動(dòng)作名稱(chēng)

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

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

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

安全性

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

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

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

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

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

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

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

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

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

請(qǐng)求與響應(yīng)

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

請(qǐng)求協(xié)議

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

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

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

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

安全性

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

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

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

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

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

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

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