iOS直播间开发经验小结

1.房间内的信令消息应该是由后台进行分发,而不是客户端自己分发

1.1假如客户端进行分发会怎么样?

  • 客户端谁来发信令消息?
    • 按照业务上的区分逻辑。我们很容易想到如踢人禁言禁麦这种控制性信令只能由房主或管理员身份来触发。发文字消息或者发图片这种普适性信令可以由发起者触发。初看,这套逻辑没问题,但实际上,隐患很大。如下
    • 客户端存在被破解的可能性
      客户端进行加密? 我拦截你的加密消息 原模原样的再发一遍呢? 那你就得校验唯一性。
      只校验唯一性也有问题,还得在加上时间戳的校验。因为我们的信令消息id一般都是实时保存在内存中的,不会做本地保存。有可能被人拿杀死进程前的信息来重发一遍。【比如礼物类消息】,如果消息id做本地保存的话,也会有新的问题,时间你要保存多久?空间你要保存到多大后删除呢?
      攻击者还可以不用管你的任何加密方式,直接把客户端内存值的数量进行修改,比如上报给接口数量是1个礼物,但客户端发信令消息的时候给你篡改成99个。如果客户端校验不仔细,就会有此漏洞。
  • 维护成本巨大
  • 工作量大,安卓和iOS各需要写一遍发信令的逻辑。
  • 在版本迭代中,很容易遇到信令消息字段新增,修改或者弃用的场景。如果由客户端进行维护,那需要严格保持iOS和安卓版本的一致性。而且由于安卓的新版本更新率远低于iOS,经常会有iOS为了兼容安卓的老版本,不断的发旧信令消息。
  • 线上出问题了,没办法及时做处理。
    如笔者遇见过,在房间内发特殊的阿语字符,安卓房间收到后会瞬间崩溃。如果文本消息由后台进行分发,遇上此情况,就可以迅速屏蔽该字符避免崩溃。
  • 其他问题
    多人抢麦,A,B,C三个客户端同时发起了抢麦,从逻辑上来讲,这三个人信令消息发出的时候,必定时间戳是不同的,有大小之分。但是其他客户端并不知道。假如真实的点击时间最早是A,其次B,最后C。很可能到达E这个客户端的顺序是B,A,C。到达F这个客户端的顺序是C,A,B。这样就引起了多台手机麦位上人员显示不一致的问题。【当时受困于客户端自己瞎搞的逻辑,折中成是先收到谁的消息,麦位就先显示谁,在一定时间内,比如5s内收到了其他的上麦消息,对比时间戳,若更早,则替换麦上的人】这样的体验并不是很好,在房间人多时,麦位上会先显示一个人,往往又会马上显示另外一个人。而如果由后台控制谁才可以上麦,则完全没有上述问题。
    以上逻辑,客户端还会掺杂着时间戳问题。有恶意的用户,他可以先断网,在触发断网强制退出回调前,恢复网络,因为这时还未拉到麦位信息,所以麦位可进行点击,此时用户进行点击,并同时把手机时间戳往前调到一个合适的时间。这样无论他怎么操作,他都可以把原来的麦位进行替换掉【笔者曾遇到过的问题,大R被反复恶意下麦】。注意,这种场景下,时间戳仅在App启动时候的一次修正并不能解决任何问题。需要每次实时修正。当然,我们有更简单的判断,未拉取到数据之前,直接不允许用户进行点击操作。
    为了坚持让客户端去发信令消息,我们当然还可以做以下尝试
    本地客户端可以通过一些方式来增加被攻击的门槛,但是性价比低。
    混淆与加固:
    笔者混淆过一段时间 但有一次审核时来被苹果发现了,审核被拒,警告不允许再混淆。
    安卓应用360进行加固和混淆的,据了解,一样可以被专业人士直接破解
    内存保护:
    增加业务复杂度,因为每当客户端发消息的时候,都需要内存比对一下信息,看是否篡改。当有正常业务逻辑触发用户信息修改的时候,还需额外同步其他地方修改。
    或者应用一些其他的高级防护技术【防调试,防止反编译,代码变现,代码乱序,指令替换等】以上自己实现,工作量大,容易引起各种各样其他Bug,产出回报小。如果直接用成熟的SDK,比如爱加密,则会加大成本费用(基础版防护SDK几万起步)。
  • 以上所有问题的根源在于,客户端没有一个真实性参考平台。本地的一切信息都有可能会被造假。而将造假后的信息发送给其他客户端,很容易引起各种各样无休止的问题,客户端会陷入无尽的折磨之中,只能去被动防御。而当线上真遇到此问题时,从用户反馈到客服,客服反馈到测试,开发讨论分析,定出解决方案,到进行修改,通过测试,上架成功,用户更新。等这一系列流程走完后,最少过去三四天了,平台的口碑早就受到了影响。综上,如果一条信令消息被篡改后,可能会影响其他客户端,那么这类消息必须由后台进行分发。

2.房间锁问题

  • 房间锁,无论在什么情况下,接口都不应该直接返回锁的密码值,让客户端进行比对密码是否正确,哪怕是进行加密后的。对于密码是否正确的判断一定是由后台判断,前端只负责提交用户进入时输入的密码。
  • 房间锁,一般我们会设计成纯数字的形式。注意:当客户端采用纯数字键盘时,需要后台对阿语下的数字进行额外处理,或客户端自定义纯阿拉伯数字键盘(有的大R会不喜欢这样的键盘,他们就喜欢用自己的语言数字),或客户端本身进行阿语判断,转换为阿拉伯数字后在上传。

3.目标用户人群的定位

• 将印度人和中东人放一起 会产生大量矛盾和文化冲突
• 印度人喜欢一些印度特殊的礼物 比如拖鞋 会觉得很嗨
• 阿拉伯人瞧不起印度人 觉得印度人又穷又闹

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,843评论 6 502
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,538评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,187评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,264评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,289评论 6 390
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,231评论 1 299
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,116评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,945评论 0 275
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,367评论 1 313
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,581评论 2 333
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,754评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,458评论 5 344
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,068评论 3 327
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,692评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,842评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,797评论 2 369
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,654评论 2 354

推荐阅读更多精彩内容