1.房間內(nèi)的信令消息應(yīng)該是由后臺進行分發(fā)，而不是客戶端自己分發(fā)

1.1假如客戶端進行分發(fā)會怎么樣？

• 客戶端誰來發(fā)信令消息？
  • 按照業(yè)務(wù)上的區(qū)分邏輯。我們很容易想到如踢人禁言禁麥這種控制性信令只能由房主或管理員身份來觸發(fā)。發(fā)文字消息或者發(fā)圖片這種普適性信令可以由發(fā)起者觸發(fā)。初看，這套邏輯沒問題，但實際上，隱患很大。如下
  • 客戶端存在被破解的可能性
    客戶端進行加密？ 我攔截你的加密消息 原模原樣的再發(fā)一遍呢？ 那你就得校驗唯一性。
    只校驗唯一性也有問題，還得在加上時間戳的校驗。因為我們的信令消息id一般都是實時保存在內(nèi)存中的，不會做本地保存。有可能被人拿殺死進程前的信息來重發(fā)一遍?！颈热缍Y物類消息】，如果消息id做本地保存的話，也會有新的問題，時間你要保存多久？空間你要保存到多大后刪除呢？
    攻擊者還可以不用管你的任何加密方式，直接把客戶端內(nèi)存值的數(shù)量進行修改，比如上報給接口數(shù)量是1個禮物，但客戶端發(fā)信令消息的時候給你篡改成99個。如果客戶端校驗不仔細(xì)，就會有此漏洞。
• 維護成本巨大
• 工作量大，安卓和iOS各需要寫一遍發(fā)信令的邏輯。
• 在版本迭代中，很容易遇到信令消息字段新增，修改或者棄用的場景。如果由客戶端進行維護，那需要嚴(yán)格保持iOS和安卓版本的一致性。而且由于安卓的新版本更新率遠(yuǎn)低于iOS，經(jīng)常會有iOS為了兼容安卓的老版本，不斷的發(fā)舊信令消息。
• 線上出問題了，沒辦法及時做處理。
  如筆者遇見過，在房間內(nèi)發(fā)特殊的阿語字符，安卓房間收到后會瞬間崩潰。如果文本消息由后臺進行分發(fā)，遇上此情況，就可以迅速屏蔽該字符避免崩潰。
• 其他問題
  多人搶麥，A，B，C三個客戶端同時發(fā)起了搶麥，從邏輯上來講，這三個人信令消息發(fā)出的時候，必定時間戳是不同的，有大小之分。但是其他客戶端并不知道。假如真實的點擊時間最早是A，其次B，最后C。很可能到達(dá)E這個客戶端的順序是B，A，C。到達(dá)F這個客戶端的順序是C，A，B。這樣就引起了多臺手機麥位上人員顯示不一致的問題?！井?dāng)時受困于客戶端自己瞎搞的邏輯，折中成是先收到誰的消息，麥位就先顯示誰，在一定時間內(nèi)，比如5s內(nèi)收到了其他的上麥消息，對比時間戳，若更早，則替換麥上的人】這樣的體驗并不是很好，在房間人多時，麥位上會先顯示一個人，往往又會馬上顯示另外一個人。而如果由后臺控制誰才可以上麥，則完全沒有上述問題。
  以上邏輯，客戶端還會摻雜著時間戳問題。有惡意的用戶，他可以先斷網(wǎng)，在觸發(fā)斷網(wǎng)強制退出回調(diào)前，恢復(fù)網(wǎng)絡(luò)，因為這時還未拉到麥位信息，所以麥位可進行點擊，此時用戶進行點擊，并同時把手機時間戳往前調(diào)到一個合適的時間。這樣無論他怎么操作，他都可以把原來的麥位進行替換掉【筆者曾遇到過的問題，大R被反復(fù)惡意下麥】。注意，這種場景下，時間戳僅在App啟動時候的一次修正并不能解決任何問題。需要每次實時修正。當(dāng)然，我們有更簡單的判斷，未拉取到數(shù)據(jù)之前，直接不允許用戶進行點擊操作。
  為了堅持讓客戶端去發(fā)信令消息，我們當(dāng)然還可以做以下嘗試
  本地客戶端可以通過一些方式來增加被攻擊的門檻，但是性價比低。
  混淆與加固：
  筆者混淆過一段時間 但有一次審核時來被蘋果發(fā)現(xiàn)了，審核被拒，警告不允許再混淆。
  安卓應(yīng)用360進行加固和混淆的，據(jù)了解，一樣可以被專業(yè)人士直接破解
  內(nèi)存保護:
  增加業(yè)務(wù)復(fù)雜度，因為每當(dāng)客戶端發(fā)消息的時候，都需要內(nèi)存比對一下信息，看是否篡改。當(dāng)有正常業(yè)務(wù)邏輯觸發(fā)用戶信息修改的時候，還需額外同步其他地方修改。
  或者應(yīng)用一些其他的高級防護技術(shù)【防調(diào)試，防止反編譯，代碼變現(xiàn)，代碼亂序，指令替換等】以上自己實現(xiàn)，工作量大，容易引起各種各樣其他Bug，產(chǎn)出回報小。如果直接用成熟的SDK，比如愛加密，則會加大成本費用（基礎(chǔ)版防護SDK幾萬起步）。
• 以上所有問題的根源在于，客戶端沒有一個真實性參考平臺。本地的一切信息都有可能會被造假。而將造假后的信息發(fā)送給其他客戶端，很容易引起各種各樣無休止的問題，客戶端會陷入無盡的折磨之中，只能去被動防御。而當(dāng)線上真遇到此問題時，從用戶反饋到客服，客服反饋到測試，開發(fā)討論分析，定出解決方案，到進行修改，通過測試，上架成功，用戶更新。等這一系列流程走完后，最少過去三四天了，平臺的口碑早就受到了影響。綜上，如果一條信令消息被篡改后，可能會影響其他客戶端，那么這類消息必須由后臺進行分發(fā)。

2.房間鎖問題

• 房間鎖，無論在什么情況下，接口都不應(yīng)該直接返回鎖的密碼值，讓客戶端進行比對密碼是否正確，哪怕是進行加密后的。對于密碼是否正確的判斷一定是由后臺判斷，前端只負(fù)責(zé)提交用戶進入時輸入的密碼。
• 房間鎖，一般我們會設(shè)計成純數(shù)字的形式。注意：當(dāng)客戶端采用純數(shù)字鍵盤時，需要后臺對阿語下的數(shù)字進行額外處理，或客戶端自定義純阿拉伯?dāng)?shù)字鍵盤（有的大R會不喜歡這樣的鍵盤，他們就喜歡用自己的語言數(shù)字），或客戶端本身進行阿語判斷，轉(zhuǎn)換為阿拉伯?dāng)?shù)字后在上傳。

3.目標(biāo)用戶人群的定位

? 將印度人和中東人放一起 會產(chǎn)生大量矛盾和文化沖突
? 印度人喜歡一些印度特殊的禮物 比如拖鞋 會覺得很嗨
? 阿拉伯人瞧不起印度人 覺得印度人又窮又鬧