iOS直播間開(kāi)發(fā)經(jīng)驗(yàn)小結(jié)

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

1.1假如客戶端進(jìn)行分發(fā)會(huì)怎么樣?

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

2.房間鎖問(wèn)題

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

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

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

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

推薦閱讀更多精彩內(nèi)容