移动端弱网优化专题 (十四)：携程 APP 移动网络优化实践（弱网识别篇）
本文由携程技术团队 Aaron 分享，原题“干货 | 携程弱网识别技术探索”，下文进行了排版和内容优化。
1、引言
网络优化一直是移动互联网时代的热议话题，弱网识别作为移动端弱网优化的第一步，受到的关注和讨论也是最多的。本文从方案设计、代码开发到技术落地，详尽的分享了携程在移动端弱网识别方面的实践经验，如果你也有类似需求，这篇文章会是一个不错的实操指南。
2、本文作者
Aaron：携程移动开发专家，关注网络优化、移动端性能优化。
3、系列文章
《移动端弱网优化专题(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端弱网优化专题(二)：史上最全移动弱网络优化方法总结》
《移动端弱网优化专题(三)：现代移动端网络短连接的优化手段总结》
《移动端弱网优化专题(四)：百度 APP 网络深度优化实践（DNS 优化篇）》
《移动端弱网优化专题(五)：百度 APP 网络深度优化实践（网络连接优化篇）》
《移动端弱网优化专题(六)：百度 APP 网络深度优化实践（移动弱网优化篇）》
《移动端弱网优化专题(七)：爱奇艺 APP 网络优化实践（网络请求成功率优化篇）》
《移动端弱网优化专题(八)：美团点评的网络优化实践（大幅提升连接成功率、速度等）》
《移动端弱网优化专题(九)：淘宝移动端统一网络库的架构演进和弱网优化实践》
《移动端弱网优化专题(十)：爱奇艺 APP 跨国弱网通信的优化实践》
《移动端弱网优化专题(十一)：美图 APP 的移动端 DNS 优化实践》
《移动端弱网优化专题(十二)：得物自研移动端弱网诊断工具的技术实践》
《移动端弱网优化专题(十三)：得物移动端常见白屏问题优化（网络优化篇）》
《移动端弱网优化专题(十四)：携程 APP 移动网络优化实践（弱网识别篇）》（* 本文）
4、技术背景
自从 2010 年携程推出”无线战略“，并发布移动端 APP 以来，无线研发团队对于客户端网络性能的优化就一直没有停止过。经过这十几年持续不断的优化，目前携程的端到端网络性能已经处于一个相当不错的水平，大盘数据趋于稳定，优化也随之进入 ”深水区“，提升难度巨大。
结合线上的一系列客诉反馈，我们发现即使大盘的数据再优秀，用户网络表现不佳的个例 case 仍然层出不穷，排查后大部分被我们归因到"弱网”。这部分“弱网”长尾数据相比大盘均值仍有巨大的提升空间，如果可以针对性优化的话，对于提升整体用户体验和减少客诉都有非常明确的价值。
既然要优化“弱网”，那第一步一定是建立相应的“弱网识别模型”，准确识别出弱网场景，本文即探讨携程在弱网识别方面的技术探索，包含技术选型细节和关键的路径思考，欢迎沟通交流。
5、技术方案概览
如上图所示，携程弱网识别模型的整个工作流程由数据采集、数据处理、结果输出三部分组成，接下来我们顺着流程来逐个剖析相关细节。
6、数据采集实现
6.1 反映网络质量的指标有哪些
说到可以客观反映网络质量的指标，业内定义清晰且获得公认的有如下这些：
1）HttpRTT：Http 请求一次网络往返的耗时，具体口径是客户端从开始发送 RequestHeader 到收到 ResponseHeader 第一个字节的时间差；
2）TransportRTT：网络通道上一次数据往返的耗时，具体口径是客户端从开始发送数据到收到服务端返回数据第一个字节的时间差，要减去服务处理的耗时；
3）ThroughPut：网络吞吐量，是指定位时间内网络通道上下行的数据量，具体口径是单位位时间内上行或者下行的数据量除以单位时间，由于上行数据量受到业务因素的影响较大，我们一般仅关注下行；
4）BandwidthDelayProduct：带宽时延乘积，顾名思义是指网络带宽乘以网络时延的结果，即当前网络通道里正在传输的数据总量，是一个复合指标，可以客观反映当前网络承载数据的能力，计算方式是 ThroughPut * TransportRTT；
5）SignalStrength：信号强度，移动互联网时代，设备依靠 Wifi 或者蜂窝数据接入互联网，信号强度会影响用户的网络表现；
6）NetworkSuccessRate：网络成功率，剔除业务影响的纯网络行为成功率，与网络质量呈正相关，包含建联成功率、传输成功率等。
6.2 哪些指标作为模型输入？为什么？
对于网络质量识别，业内做的比较早的是 Google 的 NQE（Network Quality Estimator），国内大多数网络质量识别方案也都参考了 Google NQE，NQE 中识别模型的输入主要是 HttpRTT、TransportRTT、DownstreamThroughput 这三个指标。
对于 HttpRTT、TransportRTT，在应用层和传输层都有很多方式可以采集到，且口径清晰，所以这两个指标被我们纳入采集范围。
对于 DownstreamThroughput，我们实践过程中发现，该指标受到用户行为的影响很大，当用户集中操作大量发送网络请求的时候，该指标就偏高，当用户停止操作阅读数据时，该指标就会偏低甚至长时间得不到更新，考虑到指标的波动性，我们不将此指标纳入采集范围。
既然 DownstreamThroughput 被排除在外，那由他参与计算的 BandwidthDelayProduct 也被我们排除。
SignalStrength 信号强度由于 iOS 无法准确获取，考虑到多端一致性，也被我们 Pass。
NetworkSuccessRate 网络成功率这个指标，可能很少被其他方案提及到，我们提出这个指标并将他纳入采集范围的主要原因是，基于 RTT 的网络识别模型，在遇到网络波动导致的用户大面积请求失败时，无法获取到有效的 RTT 值，导致识别的准确性和实时性都收到影响，引入网络成功率可以很好的弥补这个缺陷，最终线上生产环境验证也证明了该指标的必要性。
最终：携程的网络质量识别模型采集 HttpRTT、TransportRTT、NetworkSuccessRate 作为输入指标。
6.3 输入的网络指标如何采集
携程的网络请求，主要有 Tcp 代理通道、Quic 代理通道、Http 通道三种网络通道。
对于上述提到了三个输入指标，我们从如下网络行为中进行数据采集：
1）TransportRTT：通道心跳耗时、Tcp 通道建联耗时、Http 通道建联耗时（Tips：建联耗时不涉及业务处理，近似于纯网络传输耗时，所以我们把他作为 TransportRTT；Quic 建联约等于 Tls 握手耗时，且存在 0RTT 等特性干扰，所以不采用）；
2）HttpRTT：标准 Http 请求的 responseHeader 开始接收时间减去 RequestHeader 的开始发送时间、自定义网络通道请求的开始接收时间减去开始发送时间；
3）NetworkSuccessRate：Tcp 建联成功状态、Quic 建联成功状态、心跳成功状态、Http 请求是否完整接收到 Response。
对于自定义的 Tcp、Quic 代理通道，按照上述口径在网络通道相关状态回调内统计数据即可，自定义实现参考价值不大，这里就不过多赘述。
对于标准的 Http 请求，我们可以通过获取系统网络框架返回的 Metric 信息或者监听请求的状态流转来获取网络指标。
1）对于 iOS 端：
iOS 10 之后 NSURLSession 支持通过 NSURLSessionTaskDelegate 的协议方法 URLSession:task:didFinishCollectingMetrics:获取到请求的 Metric 信息，详细信息见附录。
单次请求的 Metric 定义如下图：
解释一下：
1）TransportRTT = connectEnd - connectStart - secureConnectionEnd + secureConnectionStart；建联耗时要减去 Tls 的耗时，连接复用时，相关字段为空值，不纳入计算；
2）HttpRTT = responseStart - requestStart；
3）NetworkSuccessStatus = responseEnd 且没有传输错误；网络成功率只关心传输是否成功，不需要关注 Response 的 http 状态码。
2）对于 Android 端：
系统网络框架 OkHttp 支持添加 EventListener 来获取 Http 请求的状态流转信息，可以在各状态回调内记录时间戳来计算 RTT，详细信息见附录。
单次请求的 Events 定义如下图：
解释一下：
1）TransportRTT = connectEnd - connectStart - secureConnectEnd + secureConnectStart；
2）HttpRTT = responseHeadersStart - requestHeadersStart；
3）NetworkSuccessStatus = responseBodyEnd 且没有传输错误。
依照上述方法收集到网络数据后，我们把数据封装成对应的结构体，注入识别模型，携程对于网络数据结构体的定义如下，方便大家参考。
typedef enum : int64_t {
} NQEMetricsSourceType;
struct NQEMetrics {
};
7、数据处理实现
7.1 数据过滤和滑动窗口
网络数据采集后，注入到识别模型内，需要一个数据结构来承载，我们采用的是队列。
进入队列前，我们需要先进行数据过滤，筛选掉一些无效的数据。
目前采用的筛选策略有如下这些：
1）单条 NQEMetrics 数据：在 isSuccessed=true 的情况下，httpRTT、transportRTT 至少有一条不为空，否则为无效数据；
2）RTT 必须大于最小阈值：用来过滤一些类似 LocalHost 请求的脏数据，目前采用的阈值为 10ms；
3）RTT 必须小于最大阈值：用来过滤前后台切换进程挂起导致的 RTT 数值偏大，目前采用的阈值为 5mins。
数据过滤后加入队列，为了实时性和结果准确性，我们处理数据时，会根据两个限制逻辑来确定一个具体的滑动窗口，只让窗口内的数据参与计算。
具体窗口限制逻辑如下：
1）最小数量限制：当窗口内数据过少时，会放大单条数据的影响，导致结果毛刺增多，所以我们限制最小计算窗口的数据条数为 5；
2）最大时间限制：为了数据实时性的考虑，比较旧的数据不参与计算，目前采用的阈值为 5mins。
每次计算网络质量时，可以根据这两个限制来确定计算窗口，窗口外的数据可以实时清理出队列，减少内存占用。
上文提到的各种阈值设置，均可通过配置系统更新。
7.2 动态权重计算
弱网识别模型的原理简单来说就是将窗口内的一组数据经过一系列处理后，得出一个最终值，再用这个最终值与对应的弱网阈值比较来得出是否是弱网。
出于实时性的考虑，我们希望距离当前时间越近的数据权重越高，所以要用到动态权重的算法，这里我们比较推荐的是”半衰期动态权重“和”反正切动态权重“两种算法。
1）半衰期动态权重：
半衰期顾名思义，即每经过一个固定的时间，权重降低为之前的一半。
这里衰减幅度和周期都是可以自定义的，计算公式如下：
每秒衰减因子 = pow(衰减幅度, 1.0 / 衰减周期)；衰减幅度为浮点型，取值范围 0~1，衰减周期为整形，单位为秒
动态权重 = pow(每秒衰减因子, abs(now - 数据采集时间))
以衰减幅度为 0.5，衰减周期为 60 秒为例，对应的函数曲线如下：
横坐标为数据采集时间距今的时间差，纵坐标为权重，从图上可以清晰看到，随着时间差增大，权重无限趋近于 0。
半衰期动态权重也是 Google NQE 采用的权重计算方案，Google 采用的周期是每 60 秒降低 50%，相关代码详见附录。
部分核心代码如下：
double GetWeightMultiplierPerSecond(
// Default value of the half life (in seconds) for computing time weighted
// percentiles. Every half life, the weight of all observations reduces by
// half. Lowering the half life would reduce the weight of older values
// faster.
int half_life_seconds = 60;
int32_t variations_value = 0;
auto it = params.find("HalfLifeSeconds");
if (it != params.end() && base::StringToInt(it->second, &variations_value) &&
}
DCHECK_GT(half_life_seconds, 0);
return pow(0.5, 1.0 / half_life_seconds);
}
void ObservationBuffer::ComputeWeightedObservations(
…
}
2）反正切动态权重：
y=arctan(x)反正切函数在第一象限的取值范围为 0~Pi/2，我们将 arctan(x)取反，向上平移 Pi/2，然后除以 Pi/2，函数曲线即可在第一象限随着 x 增大 y 的取值从 1 趋近于 0。
我们还可以使用一个斜率系数来控制权重降低的趋势快慢，公式推导过程如下：
动态权重 = (Pi / 2 - arctan(abs(now - 数据采集时间) * 斜率系数)) / (Pi / 2) = 1 - arctan(abs(now - 数据采集时间) * 斜率系数) / Pi * 2；斜率系数为浮点型，取值范围为 0~1，系数越小，权重降低的越缓慢。
以斜率系数为 1/20 为例，对应的函数曲线如下：
和前文的半衰期动态权重相同，横坐标为数据采集时间距今的时间差，纵坐标为权重，随着时间差增大，权重趋近于 0，两种动态权重算法效果类似。
反正切动态权重的实现代码如下：
static double _nqe_getWeight(double targetTime) {
}
从上图的代码实现可以看出，反正切相关的代码实现要简单很多，但是由于存在推导过程，所以理解起来比较困难，代码维护成本较高（数学功底对于程序员来说也是非常重要的），大家可以酌情自行选择。
携程最终采用的也是半衰期动态权重的方案，出于实时性考虑，最终线上验证后采用的衰减幅度为 0.3，衰减幅度为 60 秒，供参考。
7.3 RTT 指标加权中值计算
在确定了单条数据的权重之后，对于 RTT 的数值计算，我们第一个想到的是加权平均，但是加权平均很容易收到高权重脏数据的影响，准确性堪忧，所以我们改用了“加权中值”。
加权中值的计算方式是，将窗口内的数据按照数值大小升序排列，然后从头遍历数据，累加权重大于等于总权重的一半时，停止遍历，当前遍历到的数值即为最终的加权中值。
NQE 对于 TransportRTT 和 HttpRTT 处理，也是使用的这种方式，相关代码详见附录。
部分核心代码如下：
std::optional<int32_t> ObservationBuffer::GetPercentile(
……
// 此处的 percentile 值为 50，即取中值
double desired_weight = percentile / 100.0 * total_weight;
double cumulative_weight_seen_so_far = 0.0;
for (const auto& weighted_observation : weighted_observations) {
}
// Computation may reach here due to floating point errors. This may happen
// if |percentile| was 100 (or close to 100), and |desired_weight| was
// slightly larger than |total_weight| (due to floating point errors).
// In this case, we return the highest |value| among all observations.
// This is same as value of the last observation in the sorted vector.
return weighted_observations.at(weighted_observations.size() - 1).value;
}
7.4 成功率指标加权平均计算
对于成功率，我们的 NQEMetrics 结构体内定义了单次成功状态 isSuccessed，单条数据的加权成功率为 (NQEMetrics.isSuccessed ? 1 : 0) * weight，整体的加权成功率为加权成功率总和除以总权重。
相关代码实现如下：
extern double _calculateSuccessRateByWeight(const vector &metrics, uint64_t types, const shared_ptr<NQEConfig> config) {
}
7.5 引入成功率趋势提高实时性
网络质量识别不仅需要准确，实时性也非常重要，在网络质量切换时模型识别的时间越短越好。前文已经提到了 TransportRTT、HttpRTT、NetworkSuccessRate 三个核心指标的计算，但是在线上实际验证的过程中，我们发现在网络完全不可用成功率跌 0 后，识别模型对于网络状态的恢复感知很慢，原因是成功率的攀升需要较长的时间。
针对这个极端的 case，我们引入了一个“成功率趋势”的新指标，来优化模型的实时性，在成功率未达阈值当时有明显趋势时，提前切换网络质量状态。成功率趋势是指一段时间内成功率连续上升或者下降的幅度，浮点类型，取值范围-1 ~ +1。
成功率趋势初始值为 0，计算方式如下：
1）在每次更新成功率时，计算更新前后成功率的差值：
如果差值为正，则成功率向好：
1）如果当前成功率趋势值为正，则向好趋势持续，成功率趋势加上当前差值；
2）如果当前成功率趋势值为负，则成功率趋势由坏转好，成功率趋势重置为当前差值。
如果差值为负，则成功率向坏：
1）如果当前成功率趋势值为正，则成功率趋势由好转坏，成功率趋势重置为当前差值；
2）如果当前成功率趋势值为负，则向坏趋势持续，成功率趋势加上当前差值（负值）。
2）当然还需要过滤一些毛刺数据，避免趋势变化过频：
具体代码实现如下：
void NQE::_updateSuccessRateTrend() {
}
在网络成功率和成功率趋势的加持下，我们的识别模型实时性大幅度提升。我们控制相同请求频率和请求数据量，线下模拟弱网切换进行测试。
测试结果如下：
1）单 RTT 识别模型：网络质量切换后识别较慢，且存在连续切换场景识别不出弱网的情况；
2）RTT+成功率模型：切换识别速度较单 RTT 模型提升约 50%，成功率跌 0 后的 Bad 切 Good 识别明显较慢；
3）RTT+成功率+成功率趋势模型：切换识别速度较单 RTT 模型提升约 70%，Bad 切 Good 识别速度明显提升。
所以，最终携程弱网识别模型计算的指标有 TransportRTT、HttpRTT、NetworkSuccessRate、SuccessRateTrend（成功率趋势）四个。
8、结果输出
8.1 网络质量定义
识别模型对外输出的是一个网络质量的枚举值，Google NQE 对于网络质量的定义如下，源码详见附录。
enum EffectiveConnectionType {
// Effective connection type reported when the network quality is unknown.
EFFECTIVE_CONNECTION_TYPE_UNKNOWN = 0,
// Effective connection type reported when the Internet is unreachable
// because the device does not have a connection (as reported by underlying
// platform APIs). Note that due to rare but potential bugs in the platform
// APIs, it is possible that effective connection type is reported as
// EFFECTIVE_CONNECTION_TYPE_OFFLINE. Callers must use caution when using
// acting on this.
EFFECTIVE_CONNECTION_TYPE_OFFLINE,
// Effective connection type reported when the network has the quality of a
// poor 2G connection.
EFFECTIVE_CONNECTION_TYPE_SLOW_2G,
// Effective connection type reported when the network has the quality of a
// faster 2G connection.
EFFECTIVE_CONNECTION_TYPE_2G,
// Effective connection type reported when the network has the quality of a 3G
// connection.
EFFECTIVE_CONNECTION_TYPE_3G,
// Effective connection type reported when the network has the quality of a 4G
// connection.
EFFECTIVE_CONNECTION_TYPE_4G,
// Last value of the effective connection type. This value is unused.
EFFECTIVE_CONNECTION_TYPE_LAST,
};
Google 枚举定义的最大问题是理解成本比较高，其他开发同学看到这个所谓的“3G”、“4G”，他依然不知道网络是好是坏，是不是他认为的“弱网”。
所以我们在定义接口的时候，对于枚举的设计考虑最多的就是理解成本，结合开发同学最想知道的“是不是弱网”。
我们的接口定义如下：
typedef enum : int64_t {
} NetworkQualityType;
这样是不是看起来简单明了多了，我们接下来就讲讲怎么计算得出这几个枚举的结果。
8.2 网络质量计算方式
NetworkQualityTypeUnknown 是在初始化或者网络切换后的一段时间内，数据不足无法得出网络质量，会进入此状态。
NetworkQualityTypeOffline 的触发条件很单一，就是操作系统识别到无网络连接，具体的获取方式由各平台自行实现，例如 iOS 可以通过 Reachability 获取，官方 Demo 详见附录 6。
NetworkQualityTypeBad 也就是我们最核心的“弱网”状态，计算方式是上文提到的 TransportRTT、HttpRTT 两个指标任一指标触发弱网阈值，或者 NetworkSuccessRate 和 SuccessRateTrend 同时满足弱网阈值。
NetworkQualityTypeGood 是指正常的网络质量状态，上述三种网络质量类型讲完后，这个类型就简单了，即非上述三种情况的场景，归类到 Good，这也是设计上占比最高的网络质量类型。
识别模型的运转流程如下：
解释一下：
1）数据队列在初始化和网络连接状态变化两个时机会被重置，充值后网络质量类型进入 NetworkQualityTypeUnknown；
2）网络连接状态进入无连接状态时，数据队列被清空，网络质量类型直接进入 NetworkQualityTypeOffline，在网络类型变为可用类型前，数据队列不接受数据注入，且不进行计算；
3）数据队列的数据变化触发质量计算，出于资源开销考虑，要限制计算的频次，我们采用计算间隔和新增数据量两个阈值限制，计算间隔大于 60s 或者新增数据量超过 10 条才会触发计算；同时也暴露了对外接口，业务可按需强制刷新计算结果；
4）关于主动网络探测，可结合自身的业务需求按需实现，目前携程的 APP 在使用时网络数据更新比较频繁，无需补充主动探测数据。
8.3 弱网阈值制定
模型核心的计算逻辑，就是将加工后得到的各网络指标与对应的弱网阈值进行对比，从而获得是否进入弱网的结果。
关于弱网阈值的制定上，我们经历了如下两个阶段：
1）第一阶段：
主要参考 NQE EFFECTIVE_CONNECTION_TYPE_2G 的阈值定义：
1）HttpRTT > 1726ms；
2）TransportRTT > 1531ms；
3）成功率按照内部讨论的预期设置为 NetworkSuccessRate < 90%；
4）成功率趋势阈值设置为 SuccessRateTrend < 0.1，即成功率连续向好增加超过 10pp，即使成功率小于 90%，也从 Bad 切换为 Good，这个指标主要是为了提升 Bad 切 Good 的速度。
2）第二阶段：
我们通过线上的网络质量分布监控，和一些具体 case 的分析，不断迭代我们的阈值，我们需要制定一个识别准确率的指标来指引阈值的调整工作，达到逻辑准确与自洽。
理论上：我们希望识别模型的入参与当下计算出的网络质量类型所匹配，例如当前注入 NQEMetrics 数据的 HttpRTT <= 1726ms ，那我们预期当前计算出的网络质量类型就是 Good。但是弱网的决策逻辑是相对复杂的，需要考虑到各种因素，以
下两点会造成弱网状态下的入参数据不一定符合弱网阈值定义：
1）弱网的计算是对过去已经发生网络行为的分析，具有一定的滞后性，所以在识别结果切换附近，必然有部分的原数据已经满足下一阶段的网络质量定义；
2）弱网的决策是对多个指标的复合计算，所以在识别到弱网状态时，不一定所有的指标原数据都符合弱网定义，比如由 HttpRTT 触发弱网时，当前的 TransportRTT 数据可能表现良好。
终上两点原因，弱网分类下必然有一定的非弱网数据，这里的误差数据占比与识别准确率负相关，误差数据占比越低，识别准确率越高。所以想到这里，我们的模型识别准确率的指标计算口径就有了：
模型弱网识别准确性 = 100% - 弱网状态下不符合弱网阈值定义原数据占比
有了这个指标指引，我们在模型上线后进行了数个版本的数据统计，通过各指标阈值的微调和 case by case 解决异常场景，误差数据从刚上线的 15%+降低到 10%以下，即模型识别准确率优化至 90%以上。
最终携程 90%准确率的模型对应的弱网阈值如下（不同业务场景的网络请求差别较大，仅供大家参考）：
1）HttpRTT > 1220ms；这个值是线上 HttpRTT 的 TP98 值，与弱网占比相近；
2）TransportRTT > 520ms；同线上 TP98 值；
3）NetworkSuccessRate < 90%；
4）SuccessRateTrend < 0.2；之前的 0.1 导致模型的结果切换过于频繁，最终调整到了 0.2。
Tips：对于类似携程这种自定义的弱网识别模型，弱网标准也是考虑业务现状的定制标准，所以不需要太多和外部的弱网标准对齐，重点是自洽和符合业务预期。
9、落地效果
考虑到识别模型要支持多平台（iOS、Android、Harmony 等），所以我们在一开始实现方案时就采用了 C++作为开发语言，天然支持了多平台，各平台只需要实现上层数据采集和注入模型的少量逻辑即可完成模型的接入。相同的代码实现和弱网标准，也方便我们在不同的平台间直接对标数据，发现各平台的问题针对性优化。
目前携程的网络质量识别模型，已经在 iOS、Android 平台完成接入并大面积投产，网络质量数据与集团的 APM 监控平台打通，形成了携程官方统一的网络质量标准，在网络排障、框架网络优化、业务网络优化等多种场景下扮演重要角色，弱网优化相关的内容我们会在后面相关的专题内继续分享，此处不再赘述。
最终网络质量相关的分布数据如下（数据为实验采集，不代表携程真实业务情况，仅参考）。
网络质量分布：
各网络质量下对应的请求性能数据：
10、未来展望
网络质量识别模型的完成只是我们网络优化的开始，后续还有很多的工作需要我们继续努力。
未来一段时间我们会从以下几个方面继续推进：
1）持续推进各平台、各独立 APP 的网络质量识别模型接入，完成携程终端全平台的网络质量模型覆盖。
2）做好识别模型的防劣化工作，解决各业务场景的 bad case，坚守现阶段识别准确率和实时性的标准水位。
3）推出携程内部的“网络性能白皮书”，从 APP、系统平台、网络质量、成功率、全链路耗时等各维度解析公司内部各业务线的网络表现，形成内部的网络性能数据基线，为业务优化提供参考。
4）借助现有的弱网标准和识别能力，从网络框架侧和业务侧两个不同的角度进行弱网优化，提高整体网络表现；当下海外市场是业务发力的重点，海外场景的网络表现也明显弱于国内，我们会针对海外场景从弱网的角度进行重点优化。
携程目前已经针对弱网场景推出了一系列优化策略，部分策略已经取得非常不错的收益，后续我们会继续推进，也会持续分享输出。（本文已同步发布于：http://www.52im.net/thread-4737-1-1.html）
11、参考资料
[1] TCP/IP 详解 - 第 17 章·TCP：传输控制协议
[2] 快速理解 TCP 协议一篇就够
[3] 新手入门一篇就够：从零开发移动端 IM
[3] 腾讯原创分享(二)：如何大幅压缩移动网络下 APP 的流量消耗（上篇）
[4] 深入浅出，全面理解 HTTP 协议
[5] 快速读懂 Http/3 协议，一篇就够！
[6] 技术扫盲：新一代基于 UDP 的低延时网络传输层协议——QUIC 详解
[7] 冰山之下，一次网络请求背后的技术秘密
[8] 通俗易懂，理解移动网络的“弱”和“慢”
[9] 史上最全移动弱网络优化方法总结
[10] 爱奇艺 APP 网络优化实践（网络请求成功率优化篇）
[11] 美团点评的网络优化实践（大幅提升连接成功率、速度等）
[12] 淘宝移动端统一网络库的架构演进和弱网优化实践
[13] 爱奇艺 APP 跨国弱网通信的优化实践
[14] 得物自研移动端弱网诊断工具的技术实践
还未添加个人签名 2019-08-26 加入
开源IM框架MobileIMSDK、BeautyEye的作者。
评论