客户端与服务端实时通信结合实际场景，求助解决方案~~

场景：               
        1.服务端不定时的同时给多个Android客户端推送数据(数据最大的约为10K)  
        2.客户端每隔半个小时或者一个小时向服务端上报数据
        3.遇到特殊事件立即上报，后端要立刻做出响应。
        4.为以后考虑设计的服务端至少要支撑10W--20W客户端，7*24小时在线，还有支持客户端和客户端的通信。
               
遇到的问题：
        1.随着业务逐渐复杂，客户端与服务端的交互越来越频繁，之前设计的HTTP轮询方式压力就大了。。。终究不是长久之计
        2.移动推送服务使用无线移动网络，网络质量不稳定。
        3.部分设备在电梯中，网络奇差！

目前设计方案还没确定下来。。。。望各位大佬给点意见。小弟感激不尽。

你这个场景有几个特点：
1）数据来往不密集；
2）网络环境不优越（或者说有的客户端处于非常极端的情景中（）；
3）需要双向实时通信；
4）并发在线数也不算小。

我个人建议你优先考虑UDP协议：
1）它很经济，必竟数据来往 不密集，心跳包可以放的长一些，这样包括客户自已在内，流量、电量消耗都比较经济，而且服务端也轻松一些；
2）能解决极端网络的情况（虽不完美，但肯定不会比TCP差，或者极端情况下，tcp是搞不定的）；
3）唯一要纠结的是，udp最大包长度可能没法达到10K（《UDP中一个包的大小最大能多大》、《
不为人知的网络编程(六)：深入地理解UDP协议并用好它》）。

不过第3点可以进行规避，比如推的并不是全量内容而是一个指令（客户端收到指令后，自已用http短连接拉一次）。

以上只是我的建议，仅供参考。

你直接研究一下群主的 MobileIMSDK吧，自已造轮子太难弄了~~~

引用：JackJiang 发表于 2018-12-20 18:28
你这个场景有几个特点：
1）数据来往不密集；
2）网络环境不优越（或者说有的客户端处于非常极端的情景中 ...

非常感谢您的建议
您这个接收指令，HTTP在去拉信息就很灵性了。之前是自己脑子死板了，没想到变通。

引用：Shahala 发表于 2018-12-20 21:30
你直接研究一下群主的 MobileIMSDK吧，自已造轮子太难弄了~~~

是的，群主的MobileIMSDK还是很厉害的。

引用：Joseph 发表于 2018-12-21 11:25
非常感谢您的建议  
您这个接收指令，HTTP在去拉信息就很灵性了。之前是自己脑子死板了，没想 ...

嗯嗯，移动端都这么玩。