网络优化对于移动端App产品的用户体验至关重要，也与公司的运营和营收息息相关。
网络性能对于用户体验的影响，将非常直接地反馈到业务的运营上。
而且，移动网络固有的弱网问题、DNS问题、连接性能等等都无法跟传统的固定网络相比。所以，优化移动端网络，显的尤其必要。
对于即时通讯应用（IM、消息推送）的开发者来说，无论是短连接还是长连接优化，都会直接体现在APP的体验上，必竟IM或类IM应用都是用户使用频度很高的场景，网络有关的体验问题稍有懈怠，就会被用户无限放大，所以回避也不是解决问题的正确之道。
有鉴于此，即时通讯网整理收集了相当多有关移动弱网的文章（包括本篇），希望能为你移动端网络优化带来一些启发。
内容概述
如何防止网络通信被劫持？
如何提升用户页面打开速度？
老板反馈页面打不开时你该怎么办？
问题现状
在讨论解决方法之前，我们来梳理一下，在移动网络请求过程中，主要都出现了哪些最常见的问题？
▼ 首先：是网络不可用问题。主要由以下几种原因导致：
1）GFW的拦截，原因你懂的；
2）DNS的劫持，端口的意外封禁等；
3）偏远地区网络基础设施比较差。
▼ 其次：是网络加载时间长问题。这些原因包括：
1）移动设备出于省电的目的，发出网络请求前需要先预热通信芯片；
2）网络请求需要跨网络运营商，物理路径长；
3）HTTP请求是基于Socket设计的，请求发起之前会经历三次握手，断开时又会进行四次挥手。
▼ 最后：是HTTP协议的数据安全问题。具体的原因有：
1）HTTP协议的数据容易被抓包；
2）Post包体数据经过加密能够避免泄露，但协议中的URL和header部分还是会暴露给抓包软件（HTTPS也面临相似的问题）；
3）运营商数据恶意篡改严重。
当然，上述问题并非我们凭空想象。在美团点评，监控团队开发了基于端到端的客户端监控平台。这里要先解释一下“端到端”的含义：是指请求从客户端发出到服务端响应返回的整个过程。它区别于后台服务监控，是一种从用户角度观察到的真实体验监控。
短连接优化方案1：域名合并
面对上节中提到的网络问题，我们首先在HTTP短连请求中进行了一些优化尝试。
随着开发规模逐渐扩大，各业务团队出于独立性和稳定性的考虑，纷纷申请了自己的三级域名。
App中的API域名越来越多，如下所示：
… ...
App中域名多了之后，将面临下面几个问题：
1）HTTP请求需要跟不同服务器建立连接，增加了网络的并发连接数量损耗；
2）每条域名都需要经过DNS服务来解析服务器IP。
如果想将所有的三级域名都合并为一个域名，又会面临巨大的项目推进难题。因为不同业务团队当初正是出于独立性和稳定性的考虑才把域名进行拆分，现在再想把域名合并起来，势必会遭遇巨大的阻力。即时通讯聊天软件 app 开发可以加蔚可云的 v：weikeyun24 咨询
所以我们面临的是：
1）既要将域名合并；
2）又要提升网络连接效率；
3）又不能改造后端业务服务器。
该方案具有如下优势：
1）域名得到了收编，减少了DNS调用次数，降低了DNS劫持风险；
2）针对同一域名，可以利用Keep-Alive来复用Http的连接；
3）客户端业务层不需要修改代码，后端业务服务也不需要进行任何修改。
短连接优化方案2：IP直连
经过域名合并方案，我们已经将所有的域名都统一成了“api.dianping.com”。针对这唯一的域名，我们可以在客户端架设自己的DNS服务。
方案很简单：
1）程序启动的时候拉取“api.dianping.com”对应的所有的IP列表；
2）对所有IP进行跑马测试，找到速度最快的IP（后续所有的HTTPS请求都将域名更换为跑马最快的IP即可）。
IP直连方案有下面几大优势：
1）摒弃了系统DNS，减少外界干扰，摆脱DNS劫持困扰；
2）自建DNS更新时机可以控制；
3）IP列表更换方便。
此外，如果你的App域名没有经过合并，域名比较多，也建议可以尝试使用HttpDNS方案。
进一步提升端到端成功率：长连通道的建设
接下来要想进一步提升端到端成功率，就要开始进行长连通道建设了。
HTTP/2在客户端与服务器之间建立长连通道，将同一域名的请求都放在长连通道上进行。
这种拓扑结构有如下一些缺点：
1）请求基于DNS，仍将面临DNS劫持风险；
2）不同域名的请求需要建立多条连接；
3）网络通道难以优化：客户端与服务器之间是公网链路，如果在多地部署服务器，成本消耗又会很大；
4）业务改造难度大：部署HTTP/2，需要对业务服务器进行改造，而且使用的业务服务器越多，需要改造的成本也越大；
5）网络协议可订制程度小。
代理长连的模式
与HTTP/2相区别，我们这里推荐另一种代理长连的模式。
基本思路为：
1）在客户端与业务服务器之间架设代理长连服务器；
2）客户端与代理服务器建立TCP长连通道；
3）客户端的HTTP请求被转换为了TCP通道上的二进制数据包；
4）代理服务器负责与业务服务器进行HTTP请求，请求的结果通过长连通道送回客户端。
与HTTP/2模式对比，代理长连模式具有下面一些优势：
1）对DNS无依赖：
客户端与代理服务器之间的长连通道是通过IP建立的，与DNS没有关系。客户端的HTTP请求被转换为二进制数据流送到代理服务器，也不需要进行DNS解析。代理服务器转发请求到业务服务器时，都处于同一内网，因此可以自己搭建DNS服务，减少对公网DNS服务的依赖。从这个层面上说，代理长连模式天生具有防DNS劫持的能力。
2）不同域名的请求可以复用同一条长连通道；
3）通道易优化：
与部署业务服务器相比，部署代理长连服务器的代价就小了很多，可以在全国甚至全世界多地部署代理长连服务器。客户端在选择代理长连服务器时，可以通过跑马找到最快的服务器IP进行连接。另一方面，代理服务器与业务服务器之间的网络通道也可以进行优化，通过架设专线或者租用腾讯云等方式可以大大提升通道服务质量；
4）对业务完全透明：
客户端的业务代码只要接入网络层的SDK即可，完全不用关心网络请求使用的是长连通道还是短连通道。代理服务器将客户端的请求还原为HTTP短连方式送到业务服务器，业务服务器不需要进行任何改造。
5）网络协议完全自定义。
自建代理长连模式的过程
自建长连建设大概可以分为以下几个周期。
由于客户端的请求都放在TCP通道上进行，当代理长连服务器需要升级或者由于极端情况发生了故障时，将会造成客户端的整体网络服务不可用。
为了解决这个问题，我们准备了Failover降级方案——当TCP通道无法建立或者发生故障时，可以使用UDP面向无连接的特性提供另一条请求通道，或者绕过代理长连服务器之间向业务服务器发起HTTP公网请求（本文的后面章节将展示Failover机制的实际效果）。
在全国多地部署代理长连接入点。客户端与接入点建立长连通道时，可以选择最快的服务器就近接入，从而大大降低通道连接速度并提升通信质量。 我们在近两年的网络优化实践中，将客户端的网络通道服务整理成了一个独立的SDK，SDK包含了自建的长连通信服务。
网络通道SDK包含了三大通信通道：
1）CIP通道：
CIP通道就是上文中提到的自建代理长连通道。CIP是China Internet Plus的缩写，为美团点评集团的注册英文名称。App中绝大部分的请求通过CIP通道中的TCP子通道与长连服务器（CIP Connection Server）通信，长连服务器将收到的请求代理转发到业务服务器（API Server）。由于TCP子通道在一些极端情况下可能会无法工作，我们在CIP通道中额外部署了UDP子通道和HTTP子通道，其中HTTP子通道通过公网绕过长连服务器与业务服务器进行直接请求。CIP通道的平均端到端成功率目前已达99.7%，耗时平均在350毫秒左右；
2）WNS通道：
出于灾备的需要，腾讯的WNS目前仍被包含在网络通道SDK中。当极端情况发生，CIP通道不可用时，WNS通道还可以作为备用的长连替代方案；
3）HTTP通道：
此处的HTTP通道是在公网直接请求API Server的网络通道。出于长连通道重要性的考虑，上传和下载大数据包的请求如果放在长连上进行都有可能导致长连通道的拥堵，因此我们将CDN访问、文件上传和频繁的日志上报等放在公网利用HTTP短连进行请求，同时也减轻代理长连服务器的负担。
推送方案：在网络通道拓扑图的右上角，有个Push Server。它是考虑到TCP通道的双工特性，为网络通道SDK提供推送的能力。利用通知推送，可以在服务器数据发生变化时及时通知客户端。推送方案可以替换掉代码中常见的耗时低效的轮询方案。