弱网优化（弱覆盖优化）

本文目录一览：

• 1、一个简单的弱网搞死了组内前端
• 2、移动网络优化实践
• 3、弱网下移动端网络连接处理策略
• 4、安卓手机怎么设置wifi信号弱的问题

一个简单的弱网搞死了组内前端

最近上线了一个 React Native 外访项目，用户为公司外访员，外访员根据公司业务去实地考察，收集记录一些资料，考察记录资料的过程全部用公司配的专用手机，里面安装了当前外访项目APP。目前项目试运行阶段，还没有正式交付。APP项目上线后，在用户真实使用中遇到一些各种各样的问题，有些问题处理时也比较棘手（如弱网情况），这次主要复盘APP在实际场景中的弱网（或网络不稳定）相关的问题。

前提：开发测试人员在网络在正常情况和无网情况APP功能正常，但是在试运行阶段，国内部分地区用户（如四川）实际会有大量网络信号弱的地方，如地下车库，或老城区等位置操作APP时会有功能异常，表现为：

项目试运行模式是先由北京区用户试运行三天，北京区试运行通过后，再慢慢放开国内其他地区用户。北京区用户正式试用的三天中，白天工作时间北京的研发中心开发测试人员轮流跟访，有疑问现场指导，APP在北京区用户试运行期间，没有发现弱网相关问题，有功能进行优化微调，试用国内其他地区后，有个别用户反馈过功能出现异常情况，直到四川地区用户开始试用后，一周内反馈了大量APP功能异常的问题，通过和四川地区用户沟通，发现是四川地区部分地方网络信号弱导致的。

在功能开发人员内网测试OK通过情况下，测试人员使用 Charles 抓包工具，设置弱网参数，单独测试发现APP核心流程正常操作受影响，从技术实现层分析如下

整体总结为三个方面的原因

为什么总是前端在高频加班?

我能有什么办法，管理层及非前端开发选手认为前端的工作简单，修改功能也是前端简单前端改，后端涉及业务和逻辑，不能轻易动，产品UI设计认为前端什么都能实现，不用后端参与，前端开发可以基于UI库随便改，网上随便看到的功能前端也能快速实现，总体认为前端工作简单，薪资也不用多给，有问题前端改也都是很快就能搞定的

移动网络优化实践

网络优化对于App产品的用户体验至关重要，与公司的运营和营收息息相关。这里列举两个公开的数据：

“ 页面加载超过3秒，57%的用户会离开。 ”

“ Amazon页面加载延长1秒，一年就会减少16亿美金营收。 ”

首先是网络不可用的问题。主要由以下几种原因导致：

GFW的拦截，原因你懂的。

DNS的劫持，端口的意外封禁等。

偏远地区网络基础设施比较差。

其次是网络加载时间长。原因包括： * 移动设备出于省电的目的，发出网络请求前需要先预热通信芯片。 * 网络请求需要跨网络运营商，物理路径长。 * HTTP请求是基于Socket设计的，请求发起之前会经历三次握手，断开时又会进行四次挥手。

最后是HTTP协议的数据安全问题。原因有： * HTTP协议的数据容易被抓包。Post包体数据经过加密能够避免泄露，但协议中的URL和header部分还是会暴露给抓包软件。HTTPS也面临相似的问题。 * 运营商数据恶意篡改严重。如下图中，App的网页中就被运营商插入了广告。

3

面对上述网络问题，我们首先在HTTP短连请求中进行了一些优化尝试。

1. 告别 DNS，直接使用 IP 地址

如果是首次发送基于 HTTP 协议的网路服务，第一件事就是进行 DNS 域名解析，我们统计过 DNS 解析成功率只有 98%，剩下 2% 是解析失败或者运营商 DNS 劫持（Local DNS 返回了非源站 IP 地址），同时 DNS 解析在 3G 下耗时 200 毫秒左右，4G 也有 100 毫秒左右，延迟明显。我们基于 TCP 连接，直接跳过了 DNS 解析阶段，使用内置 IP 列表的方式进行网络连接。

 App 内置了一组 Server IP 列表，同时每个 IP 具备权重。每次建立新连接，会选择权重最高的 IP 地址进行连接。App 启动时，IP 列表的所有权重是相同的，此时会启动一组 Ping 的操作，根据 Ping 值的延迟时间来计算 IP 的权重，这么做的原理是 Ping 值越小的 IP 地址，连接后的网络传输延迟也应该相对更小。业界也有使用 HTTP DNS 方式来解决 DNS 劫持问题，同时返回最合适用户网络的 Server IP。然而 HTTP DNS 的开发和部署需要不小的开发成本，我们目前没有使用。

内置 Server IP 列表也会被更新，每次 App 启动后会有个 Mobile Config 服务（支持 TCP 和 HTTP 两种网络类型服务）更新 Server IP 列表，同时支持不同产品线的 Server IP 列表更新。因此，传统 DNS 解析能够解决多 IDC 导流的功能也可以通过此方法解决。

2. Socket 连接优化，减少连接时间

和 HTTP 协议中的 Keepalive 特性一样，最直接减少网络服务时间的优化手段就是保持长连接。每次 TCP 三次握手连接需要耗费客户端和服务端各一个 RTT（Round trip time）时间才能完成，就意味着 100-300 毫秒的延迟；TCP 协议自身应对网络拥塞的  Slow Start  机制也会影响新连接的传输性能。

App 使用了长连接池的方式来使用长连接，长连接池中维护了多个保持和服务端的 TCP 连接，每次网络服务发起后会从长连接池中获取一个空闲长连接，完成网络服务后再将该 TCP 连接放回长连接池。我们没有在单个 TCP 连接上实现 Pipeline 和 Multiplexing 机制，而是采用最简单的 FIFO 机制，原因有二：

简化 Mobile Gateway 的服务处理逻辑，减少开发成本；

在服务端同时返回多个响应时，如果某个响应报文非常大，使用多个长连接方式可以加快接收服务响应报文速度。

如果发起网络服务时长连接池中的 TCP 连接都正在被占用，或者 TCP 长连接的网络服务失败，则会发起一个 TCP 短连接实现网络服务。这里长连接和短连接的区别仅仅是服务完成后是否直接关闭这个 TCP 连接。

附： Pipeline 和 Multiplexing 是有区别的，如 HTTP/1.1 支持 Pipeline，客户端能否同时发送多个请求，但是服务端返回响应时也要按照请求的发送次序来返回响应；SPDY 和 HTTP/2 协议支持 Multiplexing，即支持响应报文的乱序返回，发送请求和接收响应互不干扰，因此避免了 HTTP/1.1 Pipeline 也没能完全解决的 Head of line blocking 问题。

3. 弱网和网络抖动优化

App 引入了网络质量参数，通过网络类型和端到端 Ping 值进行计算，根据不同的网络质量改变网络服务策略：

调整长连接池个数：例如在 2G/2.5G Egde 网络下，会减少长连接池个数为 1（运营商会限制单个目标 IP 的 TCP 连接个数）；WIFI 网络下可以增加长连接池个数等机制。

动态调整 TCP connection、write、read 的超时时间。

网络类型切换时，例如 WIFI 和移动网络、4G/3G 切换至 2G 时，客户端 IP 地址会发生变化，已经连接上的 TCP Socket 注定已经失效（每个 Socket 对应一个四元组：源 IP、源 Port、目标 IP、目标 Port），此时会自动关闭所有空闲长连接，现有网络服务也会根据状态自动重试。

4. 数据格式优化，减少数据传输量和序列化时间

传输数据量越小，在相同 TCP 连接上的传输时间越短。携程 App 曾经使用自行设计的一套数据格式，后来和 Google ProtocolBuffer 对比后发现，特定数据类型下数据包大小会降低 20-30%，序列化和反序列化时间可以降低 10-20%，因此目前核心服务都在逐步迁移到到 ProtocolBuffer 格式。另外 Facebook 曾分享过他们使用  FlatBuffer 数据格式 提高性能的实践，我们分析后不太适合携程的业务场景因而没有使用。

5. 引入重试机制，提升网络服务成功率

受 TCP 协议重传机制来保证可靠传输的机制启发，我们在应用层面也引入了重试机制来提高网络服务成功率。我们发现 90% 以上的的网络服务失败都是由于网络连接失败，此时再次重试是有机会连接成功并完成服务的；同时我们发现前面提到的网络服务生命周期处于 1 建立连接、序列化网络请求报文、发送网络请求这三个阶段失败时，都是可以自动重试的，因为我们可以确信请求还没有达到服务端进行处理，不会产生幂等性问题（如果存在幂等性问题，会出现重复订单等情况）。当网络服务需要重试时，会使用短连接进行补偿，而不再使用长连接。

实现了上述机制后，携程 App 网络服务成功率由原先的 95.3%+ 提升为如今的 99.5%+（这里的服务成功率是指端到端服务成功率，即客户端采集的服务成功数除以请求总量计算的，并且不区分当前网络状况），效果显著。

6. 其他网络服务机制 Tricks

携程 App 也实现了其他一些网络服务机制方便业务开发，如网络服务优先级机制，高优先级服务优先使用长连接，低优先级服务默认使用短连接；网络服务依赖机制，根据依赖关系自动发起或取消网络服务，例如主服务失败时，子服务自动取消。

开发过程中我们也发现一些移动平台上的 TCP Socket 开发 tricks：

iOS 平台上的原生 Socket 接口创建连接并不会激活移动网络，这里原生 Socket 接口是指 POSIX Socket 接口，必须使用 CFSocket 或者再上层的网络接口尝试网络连接时才会激活网络。因此携程 App 启动时会优先激活注册一些第三方 SDK 以及发送 HTTP 请求来激活移动网络。

合理设置 Socket 的几个参数：SO_KEEPALIVE 参数确保 TCP 连接保持（注：此 KeepAlive 是 TCP 中的属性，和 HTTP 的 KeepAlive 是两个场景概念），SO_NOSIGPIPE 参数关闭 SIGPIPE 事件，TCP_NODELAY 参数关闭 TCP Nagle 算法的影响。

由于 iOS 要求支持 IPv6-Only 网络，因此使用原生 Socket 必须支持 IPv6。

如果使用 select 来处理 nonblocking IO 操作，确保正确处理不同的返回值和超时参数。

保持 TCP 长连接可用性的心跳机制：对于非 IM 类应用而言，心跳机制的作用不大，因为用户会不断触发请求去使用 TCP 连接，尤其在携程业务场景下，通过数据统计发现使用心跳与否对服务耗时和成功率影响极小，因此目前已经关闭心跳机制。原先的心跳机制是 TCP 长连接池中的空闲 TCP 连接每 60 秒发送一个心跳包到 Gateway，Gateway 返回一个心跳响应包，从而让双方确认 TCP 连接有效。

Hybrid 网络服务优化

携程 App 中有相当比例的业务是使用 Hybrid 技术实现的，运行在 WebView 环境中，其中的所有网络服务（HTTP 请求）都是由系统控制的，我们无法掌控，也就无法进行优化，其端到端服务成功率也仅有 97% 左右（注：这里指页面中业务逻辑发送的网络服务请求，而非静态资源请求）。

我们采用了名为『TCP Tunnel for Hybrid』的技术方案来优化 Hybrid 网络服务，和传统 HTTP 加速产品的方法不同，我们没有采用拦截 HTTP 请求再转发的方式，而是在携程 Hybrid 框架中的网络服务层进行自动切换。

如图所示，该技术方案的流程如下：

如果 App 支持 TCP Tunnel for Hybrid，Hybrid 业务在发网络服务时，会通过 Hybrid 接口转发至 App Native 层的 TCP 网络通讯层，该模块会封装这个 HTTP 请求，作为 TCP 网络服务的 Payload 转发到 TCP Gateway；

TCP Gateway 会根据服务号判断出是 Hybrid 转发服务，解包后将 Payload 直接转发至 HTTP Gateway，此 HTTP 请求对 HTTP Gateway 是透明的，HTTP Gateway 无需区分是 App 直接发来的还是 TCP Gateway 转发来的 HTTP 请求；

后端业务服务处理完成后，HTTP 响应会经 HTTP Gateway 返回给 TCP Gateway，TCP Gateway 将此 HTTP 响应作为 Payload 返回给 App 的 TCP 网络通讯层；

TCP 网络通讯层会再将该 Payload 反序列化后返回给 Hybrid 框架，最终异步回调给 Hybrid 业务调用方。整个过程对于 Hybrid 业务调用方也是透明的，它并不知道 TCP Tunnel 的存在。

采用该技术方案后，携程 App 中 Hybrid 业务的网络服务成功率提升至 99% 以上，平均耗时下降了 30%。

海外网络服务优化

携程目前没有部署海外 IDC，海外用户在使用 App 时需要访问位于国内的 IDC，服务平均耗时明显高于国内用户。我们采用了名为『TCP Bypass for Oversea』的技术方案来优化海外网络服务性能，主要是使用了 Akamai 的海外专属网络通道，同时在携程国内 IDC 部署了局端设备，使用专用加速通道的方式来提升海外用户体验。

海外用户启动 App 后先通过 Akamai 定制域名获取 Server IP，所有网络服务优先走 Akamai 通道；如果 Akamai 通道的网络服务失败并且重试机制生效时，会改走传统 Internet 通道进行重试。相比只用传统 Internet 通道，在保持网络服务成功率不变的情况下，使用 Akamai 通道 Bypass 技术后平均服务耗时下降了 33%。

其他网络协议探讨

过去两年我们的网络服务优化工作都是基于 TCP 协议实现的，基本达到了优化目标。不过这两年来新的应用层网络协议 SPDY 和 HTTP/2 逐步迈入主流，基于 UDP 的 QUIC 协议看起来也非常有趣，值得跟进调研。

SPDY HTTP/2

SPDY 是 Google 基于 TCP 开发的网络应用层协议，目前已经停止开发，转向支持基于 SPDY 成果设计的 HTTP/2 协议，HTTP/2 协议的核心改进其实就是针对 HTTP/1.x 中影响延迟性能的痛点进行优化：

Header 压缩：压缩冗余的 HTTP 请求和响应 Header。

支持 Multiplexing：支持一个 TCP 连接上同时实现多个请求和响应。

保持长连接（比 HTTP/1.x 更彻底）：减少网络连接时间。

支持推送：可以由服务端主动推送数据到客户端。

官方性能测试结果显示使用 SPDY 或者 HTTP/2 的页面加载时间减少 30% 左右，不过这是针对网页的测试结果，对于 App 中的网络服务，具体优化效果我们还在进行内部测试，不过其优化手段看和目前我们使用 TCP 协议的优化手段类似，因此性能优化效果可能不会很显著。

QUIC

QUIC 是 Google 基于 UDP 开发的应用层协议，UDP 协议无需连接，不存在重传机制，因此应用层需要保证服务的可靠性。目前国内腾讯有针对弱网络尝试过 QUIC 协议，我们也在进行测试，最终是否会采用还需要看测试的结果。

综述

技术只是手段，最终还是要反映在业务效果上。我们已经实现除静态资源等需要访问 CDN 的网络请求外，其他 App 网络服务使用统一的 TCP 通道，从而具备更好的性能调优和业务监控能力。携程目前基于 TCP 协议的各种 App 网络服务优化，也是各种技术方案的平衡，虽然目前 HTTP/2 等新协议逐步成熟，但是 TCP 协议自身的灵活性支持有针对性的性能优化，还是具备其特别的优势，希望我们的实践总结能对国内无线技术从业者有一些借鉴价值。

弱网下移动端网络连接处理策略

一、背景

如何度量和模拟“弱网络”对移动APP的开发有着重大的意义，比如：节约测试成本、易于问题重现、加快产品上线等。

一般的方法是使用“丢包率”和“网络延时”来定义和衡量“弱网络”。

二、手机接入服务器的流程

要讲这个问题，首先要来了解下手机接入服务器的流程。

首先，手机要通过无线网络协议，从基站获得无线链路分配，才能跟网络进行通讯。

无线网络基站、基站控制器这方面，会给手机进行信号的分配，已完成手机连接和交互。

获得无线链路后，会进行网络附着、加密、鉴权，核心网络会检查你是不是可以连接在这个网络上，是否开通套餐，是不是漫游等。核心网络有SGSN和GGSN，在这一步完成无线网络协议和有线以太网的协议转换。

再下一步，核心网络会给你进行APN选择、IP分配、启动计费。

再往下面，才是传统网络的步骤：DNS查询、响应，建立TCP链接，HTTP GET，RTTP RESPONSE 200 OK，HTTP RESPONSE DATA，LAST HTTP RESPONSE DATA，开始UI展现。

这是手机通过无线网络接入服务器的全过程。整个过程当中有几个困扰开发者的问题：

无线网络是怎么给手机分配到无线链路的？

核心网络有接入点（APN），这里的CMNET和CMWAP有什么区别，仅仅是协议不同吗吗？数据转发又有什么区别？一个数据包在不同网络上传输有不同吗？

用户怎么最快的找到正确的服务器？内容怎么快速有效的加载，在第一时间显示出来？

这几个问题的重点在于其中的几个连接点：

3.2 一秒钟法则

根据以上情况，就形成无线网络的一大特点：秒级状态管理，秒级状态转换。这两个操作都在几百ms到几秒之间进行，对于维持连接来说时间太短，对于从无连接到有连接的转换来说时间又太长。

相比之下，有线网络的状态管理如ip分配、tcp连接释放，都是分钟级，而状态转换则是毫秒级。

这些通讯机制，同时加上无线网络的高延迟、高丢包。如何保证移动互联网的产品提供稳定的、可预期的服务质量，成为非常大的挑战：

2G网络上无线部分数据传输的延迟有几百ms，4G网络上无线部分传输延迟减少到几十ms，核心网状态转换、协议转换30~100ms，IP骨干网上的延迟又跟物理距离以及运营商互联互通质量有关，跨运营商50-400ms，同运营商5-80ms，这个还要取决于网络拥塞的情况。

无线网络误码率比有线高两个数量级，在不同时间段的波动也非常巨大。

怎么基于移动网络的特性去优化服务？

这就是我们总结的一秒钟法则：在一秒内要完成的规定动作。

1,2g网络：1秒内完成dns查询、和后台服务器建立连接

2,3g网络：1秒内完成首字显示（首字时间）

3,wifi网络：1秒内完成首屏显示（首屏时间）

4,这些指标需要在终端度量，必须跟用户体验相关：首字时间、首屏时间都必须是用户可以直观感受到的。

四、优化思路

4.1 服务保证原则

从以上分析可知，如何保证移动互联网的产品提供稳定的、可预期的服务质量，具有非常大的挑战。以下几点原则可能会有帮助：

1), 接口设计优化 ，接口的优化理论上不属于APP弱网络的优化，但是这个的API性能的问题，确实在网络条件不好的情况下才暴露无遗。大家都在谈论服务器的好坏，设备的性能高低，其实，对于一个良好的Server来说，绝大部分拖延请求速度的地方都是在IO上。包括，磁盘读写的IO，SQL查询的IO等等。常用的优化点：慢查询监控 、多次查询优化、常用接口cache等。

2) 图片相关策略。

1）使用更快的图片格式，严格说也不算弱网下的优化，但一个更快的图片格式真的很重要！这里建议采用WebP格式。（WebP格式，谷歌（google）开发的一种旨在加快图片加载速度的图片格式。图片压缩体积大约只有JPEG的2/3，并能节省大量的服务器带宽资源和数据空间。但WebP是一种有损压缩。相较编码JPEG文件，编码同样质量的WebP文件需要占用更多的计算资源。）

2）、不同网络的不同图片下发。如（对于原图是600X480的图片）：2/3G使用低清晰度图片——下发300X240，精度为80的图片、4G普通清晰度图片——下发600X480，精度为80的图片、WiFi高清晰度图片（最好根据网速来判断，wifi也有慢的）——下发600X480，精度为100的图片。

3) 断线重连 。这可能是最重的一个特性，因为在无线网络中有太多的原因导致数据连接中断了。这里可以使用CDN。（CDN 是构建在数据网络上的一种分布式的内容分发网。 CDN 的作用是采用流媒体服务器集群技术，克服单机系统输出带宽及并发能力不足的缺点，可极大提升系统支持的并发流数目，减少或避免单点失效带来的不良影响。）

4)由于创建连接是一个非常昂贵的操作，所以应尽量 减少数据连接的创建次数 ，且在一次请求中应尽量以批量的方式执行任务。如果多次发送小数据包，应该尽量保证在2秒以内发送出去。在短时间内访问不同服务器时，尽可能地复用无线连接。

5), 优化DNS查询 。应尽量减少DNS查询、避免域名劫持、DNS污染，同时把用户调度到“最优接入点”。

6), 减小数据包大小和优化包量 。通过压缩、精简包头、消息合并等方式，来减小数据包大小和包量。

7),控制数据包大小不超过1500， 避免分片 。包括逻辑链路控制（Logic Link Control）分片、GGSN分片，以及IP分片。其中，当数据包大小超出GGSN所允许的最大大小时，GGSN的处理方式有以下三种：分片、丢弃和拒绝。

8), 优化TCP socket参数 ，包括：是否关闭快速回收、初始RTO、初始拥塞窗口、socket缓存大小、Delay-ACK、Selective-ACK、TCP_CORK、拥塞算法(westwood/TLP/cubic)等。做这件事情的意义在于：由于2G/3G/4G/WIFI/公司内网等接入网络的QoS差异很大，所以不同网络下为了取得较好的服务质量，上述参数的取值差异可能会很大。

9), 优化ACK包 。在弱网络的情况下，TCP协议中的ACK包是非常昂贵的，延时甚至能够达到秒级别，而TCP协议的拥塞控制、快速重传、快速恢复等特性都非常依赖接收端反馈的ACK包。可想而知，如果发送端接收到的ACK包延时太长，会严重影响TCP协议的效率。但是如果发送ACK太多又会占用宝贵过多的无线资源。在移动网络下通信，“在可靠的连接上，如何在减少ACK包的情况下，降低数据包的延时”是研究的热点。基本的思想：平衡冗余包和ACK包个数，达到降低延时，提高吞吐量的目的。例如SGSN和GGSN之间的通信实现：二者之间通过UDP协议通信，发送者在无新的数据包的情况下，每隔一定的时间重试已发送的包，达到最大重试次数后，则丢弃该包。

10), TCP的拥塞控制算法 是以“丢包意味着网络出现拥塞”为假设设计的，很明显这个假设在无线网络环境下是不合适的。但是在无线网络环境下，在设计可靠UDP协议时是否能够完全丢弃拥塞控制呢？这里有其它的文章中提出了几种在无线网络环境下的TCP友好的拥塞控制算法，有兴趣可以自行查阅。

11), 灵活使用长连接/短连接 ，支持不同协议（TCP/UDP, http、二进制协议等），支持不同端口等。

12), 让用户觉得快 。到这里已经不能算是技术层面的方法了，属于一种心理层面的博弈，一种改善用户体验的方式。比如：

1）、不从0开始的进度条。不管网页的加载进度如何，不管网络条件如何，加载进度始终是从50%起，并且停留在大约98%进度左右的地方。

2）、先显示文字在加载图片。同样是在Webview之中，图片或者多媒体的加载速度肯定是远远慢过文字的加载速度的。由于不同的webview显示和渲染效果不同，我们可以先让webview先显示文字，在显示图片。给用户一种可以先预览整个网页概况的感觉。

4.2 接入调度优化

接入调度优化首先要考虑的是减少DNS的影响。移动网络的DNS有如下特点：

1)骨干网无法识别移动用户在哪个城市，东西南北各个地方的调度没有充分调用。目前有一部分全国范围的DNS承载了超过40%的全网用户

2),很多山寨机的终端local dns设置是错误的

3),另外还有一些有线网络也一样会遇到的问题，如终端DNS解析滥用、域名劫持、DNS污染、老化、脆弱等。不过对于这些问题，桌面的自愈性会比较好，而在手机上则比较难以解决。

对于DNS的问题，有两条主要的解决思路：

1),减少DNS的请求、查询、更新，也就是做DNS缓存

2),在终端配置server list，直接访问IP，不用DNS

但仅仅这么做还不够，因为用户可能来自国内外不同的运营商，还需要进一步优化调度策略：

1),DNS缓存需要多建立接入点，用不同域名区分

2),IP列表需要更新以适应不同网络情况，要做到主动调度。好比最早我们只服务好移动用户就行，保证移动用户的接入质量优先，因为绝大多数用户集中在移动；现在国内有三个运营商，用户分布的比例在慢慢接近，要区分清楚；智能手机会用wifi，接入的是电信、联通还是哪个运营商，不知道，所以你不可能预先设置场景再if then，必须通过后台调度能力来解决。

再进一步优化，就产生一种融合的方式：

1),先做域名解析，客户端直接连接解析的IP，可以用http协议，也可以用tcp socket

2),多端口、多协议组合：不同协议有不同的限制，有些只能http，有些只能tcp socket，各种环境都要适应，客户端不能只支持一种协议

3),终端测速：接入点越来越多，接入哪个合适，要选择，可以通过终端测速来选择最快的。你当然可以每一次新建连接都做测速，但是这样建立连接时间可能会很长；我们可以给用户先建立连接后，在后台根据长期速度监控、当前测速的结果，来做动态调度。也就是说，第一次连接可能不是最优，连接建立后动态测速，再转移到最快接入点。更进一步就是建立网络profile，终端学习的思路。

关于测速采样的粒度，移动互联网取IP段是没用的，比较好的粒度是到网元级别，比如广东有20多个wap网关，每一个网关的情况都不一样，这就是一个比较合适的粒度。

最后强调一个所有的接入调度原则：不要把调度逻辑写死在客户端，一定要由后台完成。

4.3 协议优化

协议参数优化这块就简单列一下，是长期运营过程中总结的一些经验，在启动移动互联网服务时作为运营的规范，可以少走很多弯路：

1,关闭TCP快速回收

2,Init RTO不低于3秒

3,初始拥塞控制窗口不小于10。因为大部分页面在10kB以下，很多请求在慢启动阶段已经结束，改为10可以降低小页面资源传输时延。内容越大，这个选项的效果就比较不明显。

4,Socket buffer 64k

5,TCP滑动窗口可变

6,控制发包大小在1400字节以下，避免分片

协议优化的原则总结下来是这么几条：

1,连接重用

2,并发连接控制

3,超时控制

4,包头精简

5,内容压缩

6,选择更高效率的协议。无论是TCP、HTTP、UDP、长连接、GZIP、SPDY、WUP还是WebP，每一种协议、方案都有其道理，没有最优，只有是否适合你的产品和服务特点，需要大家在运营过程验证和取舍。

4.4 WAP接入点优化

关于WAP接入点优化，可能有些人会说，我们的App是高端大气上档次的应用，是不是就不用做WAP优化？实际上我们的统计显示，目前有5%-20%的用户选择的接入点是＊WAP（CMWAP、3GWAP、CTWAP），这甚至包括一些iPhone终端。实际上，WAP网关本质是个代理，不完全是落后的东西，随着技术的进步也在演进，以后在组网架构中可能有综合网关、内容计费网关来取代目前的WAP网关，所以建议也要一并考虑。以下是做WAP优化需要注意的一些问题：

1,资费提醒页面

2,302跳转处理

3,X-Online-Host使用与处理

4,包大小限制

5,劫持与缓存

6,正确获取资源包大小

4.5 业务逻辑优化

1, 简化逻辑 ：交互繁琐的内容尽量用标识更新。举一个例子，我们在老版的手机QQ上做过一个测试：假如我有100个好友，用手机QQ完成登陆，完成好友列表更新一遍，需要3.5分钟。这肯定是不合理的。建议用信令状态来通知是否需要更新，同时合理利用缓存。在比如玩游戏，好友给你送了很多星星，是让用户一次一次点还是批量点？从优化的角度肯定是批量点，从用户体验的角度这也更加舒服。

另一方面，延长域名图标的缓存时间也可以有效地优化访问次数。我们把手机腾讯网图标的缓存时长从120分钟延长到2天后，访问次数优化了差不多35%。

2, 柔性可用 ：这个意思就是在网络质量好的时候给高清大图，不好的时候先给用户看小图，点一下再拉取原图。举一个极端的例子，比如万一地震了，基站毁掉20%，用户要给家人报平安，这时候产品上就必须优化，比如只发送文字，合理降3, 低网络消耗 。另外在响应很慢的时候，需要给用户一些合理的页面提示，比如提示用户再过5秒会发送，所以你不要一直刷屏，这也可以减少访问对后台服务、对网络的冲击。

上面说了那么多，这里就给出一个实例帮助大家更直观的理解。

这里给出一个DNS系统设计来实现最优调度。其拓扑结构如下：

TGCP SDK的职责：

1,用HTTP的Get/Post方法从DNSvr获服务器和DNSvr本身的最优接入点列表。Get/Post方法的查询参数包括uin/openid、客户端版本号、IP列表的MD5（注意IP顺序）、域名列表、VIP、ServiceID等。

2,缓存访问服务器和DNSvr的IP列表，以及其它元数据（比如IP列表等），且以APN为主键。

3,满足一定的条件下，要主动更新缓存的IP列表，例如缓存过期。

Tconnd的职责：

1,路由查询请求给活动的DNSvr；

DNSvr的职责：

1,根据静态和动态策略来决定客户端的“最优接入点”。静态策略：根据uin/openid、客户端版本号或者强制规则来决定IP列表；动态策略：灯塔根据测速数据动态决定用户的服务器接入点。

2,支持以手动或自动的方式拉黑某些IP。自动方式：由服务器的接入tconnd向DNSvr上报其是否存活（需要向多个点上报，包括用公网IP上报），如果在一定时间内没有接收到上报或者上报消息中明确所有的逻辑服务器已经挂掉，则自动拉黑相应的IP。如果业务恢复，则自动激活相应的IP。如果项目组接入TGW，对于某个IP和端口是否可用，则需要考虑进程与VIP的映射关系。

3,在tcaplus中缓存灯塔的计算结果。此时要求DNSvr能够根据客户端IP判断所属的国家、省份、运营商和网关（可以通过访问MIG的IP库实现）。如果缓存了灯塔的计算结果，当缓存超时后，要重新从灯塔拉取相应数据。

灯塔的职责：

1,根据客户端IP和服务器接入点IP，返回最优的接入点列表，包括IP的排序，以及客户端接入的国家、省份、运营商、APN和网关。

Tcaplus的职责：

1,保存接入的IP列表和端口、静态策略，或缓存灯塔的计算结果；

主要的流程：

客户端批量解析域名流程

1,TGCP以APN和域名列表为关键字查询缓存，如果存在且没有过期，则直接把IP返回给用户。如果指定强制解析域名列表，则跳过此步骤；

2,TGCP用预配置或缓存的IP向DNSvr发起查询请求，如果成功返回结果，则执行步骤3，否则，重试IP列表中的其它IP，如果都失败，则用域名访问DNSvr。注意：如果是结果格式不正确，则使用上次的IP重试，不要更换IP重试。

3,DNSvr比较客户端IP列表和当前最新的IP列表的MD5，如果相等，则告诉客户端不需要更新本地缓存。否则，TGCP把接入服务器和DNSvr的IP列表写入本地。注意：在访问服务器时，这些IP的优先级要高于静态配置在客户端的IP。

客户端使用域名访问服务器流程

1,如果本地存在有效的IP（即存在对应APN的IP列表，且没有失效），则使用IP访问服务器。

2,否则，发起“客户端批量解析域名流程”后，再访问服务器。

服务器接入tconnd主动上报状态流程：

1,Tconnd周期性向DNSvr上报心跳消息，其中包含本接入点是否可用的信息。

2,DNSvr在一定的时间内没有收到心跳消息或者相应的接入点不可用，则把相应的IP和端口拉黑，黑掉的IP不在下发给客户端。

注意：实际部署的时候，接入的Tconnd要向多个DNSvr接入tconnd上报。

向客户端主动push接入点列表的流程

1,当TGCP连接到服务器接入的Tconnd时，Tconnd要向DNSvr发起请求，以校验当前接入IP的质量和时效性。如果IP列表发生变化，Tconnd要把最新的IP列表下发给客户端缓存起来。

2,当TGCP下次访问服务器时，则使用最新的IP列表。

客户端访问DNSvr失败的流程

1,如果访问DNSvr失败（包括IP+域名），如果配置了本地IP，则直接用IP访问服务器，否则用域名访问。

优化传输层协议设计

在原有tconnd支持的可靠UDP的基础之上，添加以下逻辑：

1,数据压缩；

2,数据加密；

3,合并多个数据包；

4,支持流式数据传输，便于控制每个UDP包的大小，也便于数据加密和压缩；

5,可选地支持改进的拥塞控制算法；

6,即使没有接收到ACK包，也需要主动重试以发送的数据包；

5.2 Hybird开发下的一些优化

要处理在弱网络下的加载速度，那么我们要先确定一下我们的整个APP在哪个地方加载的速度如何，最长的加载路径在哪里，我们从而才有针对性的进行优化与修改。

5.2.1 WebView

如果是对是APP中内嵌的webview网页，针对网页体验优化已经由来已久了。我们可以使用Chrome的开发者模式，调整到Network模式下，将网络条件设置为3G去请求网页，那么我们就能够看出来一个网页加载的速度主要都耗费在哪个地方，如下图所示：

当然，html的加速方式有很多种

1,使用gulpgrunt进行打包压缩：jscss资源压缩，CSS Sprites合并等。

2,使用font-awesome替换图片：字体可以很好的兼容，无限放大，常用的图片都有

安卓手机怎么设置wifi信号弱的问题

一、开启手机WiFi的优化设置

大部分安卓手机的“WLAN”或者“无线局域网”里的高级设置都支持设置，相关设置有的手机要仔细找才会找到，一般人不注意可能都会忽略这里的高级设置。

设置方法：进入“设置WLANWLAN设置（高级设置）”，你就会发现“避开状况不佳的网络”和“WLAN优化”两个选项了，这里把它们勾上。这两个设置对手机WiFi信号有很好的优化作用，一般手机都不会默认勾选的，需要你手动来设置。

二、避开状况不佳的网络

如果机友的手机WiFi信号经常出问题的话，应该尝试将WLAN设置在“休眠状态下保持WLAN连接”设置为始终，看看问题会不会消失。如果设置为始终的话，耗费的电力将会上升，但是从另外的方面来看，这也会让WiFi连接更稳定。

设置方法：进入“设置WLANWLAN设置（高级设置）”，你就会发现“休眠状态下保持WLAN连接”的选项了，这里把它设置成“始终”。

经过以上两项操作，你会发现手机的WiFi信号比之前要好一些，也更稳定了。

关于弱网优化和弱覆盖优化的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。