一、背景
随着得物用户规模和业务复杂度不断提升,端上网络体验优化已逐步进入深水区。为了更好地保障处于弱网状态下得物App用户的使用体验,我们在已有的网络体验大盘、网络诊断工具的基础上研发了弱网诊断能力。该工具能够高效实时诊断用户真实网络环境,同时给出精确网络质量分级,为后续App各业务场景进行针对性优化做好基础建设保障。
一些网络性能指标:
-
速率:指传送数据的速率。速率是计算机网络中最重要的性能指标,单位是b/s(比特每秒,也写作bps ,即bit per second )。速率较高时可写作kbps,mbps。
-
带宽:带宽用来表示网络的通信线路传送数据的能力,表示在单位时间内从网络中的某一点到另一点所能通过的“最高速率”。
-
吞吐量(throughput):表示在单位时间内通过某网络的数据量。吞吐量常用于对网络的一种测量。吞吐量受网络带宽或者速率限制。例如,对于一个100Mb/s的网络,其额定速率是100Mb/s,那么该数值是此网络的吞吐量的上限,其吞吐量可能只有70Mb/s。
-
时延:指数据从网络上的一端传输到另一端所需要的时间。
-
往返时间RTT(Round-Trip Time):表示从发送方发送数据开始,到发送方收到接收方的确认,总共经历的时间。
-
HttpRTT:指从客户端请求的第一个字节开始发送到收到第一个数据包响应的时间差。这个时间包含3个部分,客户端发送数据到服务器耗时、服务器处理耗时、服务器响应数据到客户端耗时。
弱网诊断观察的指标:
弱网诊断根据HttpRTT和吞吐量来观察用户网络环境。
-
HttpRTT:在不考虑服务器处理耗时的情况下,能够体现用户请求被处理的真实时延。
-
吞吐量(throughput):用户的额定速率能被系统提供的API获取到,然而其仅能表示设备能够提供的最大速率(一般很大),却不是真实速率,而测量真实的吞吐量更能体现出用户当前真实网络环境。
二、整体架构
本次实现的是被动弱网诊断,也就是不主动发起探测请求,被动采集App内的全部网络请求,再根据一定在策略计算出用户网络环境。相对于主动探测,被动探测不会浪费用户资源。尤其是在吞吐量计算方面,主动探测不仅会消耗用户流量,还可能会对正在进行中的用户网络请求产生影响。而且当用户网络环境不佳时,负向影响更加严重。
以下为被动网络诊断的整体架构图:
整体架构图
三、采集层
HttpRTT采集
HttpRTT的采集比较简单,各端根据自身Http协议栈的实现获取到从写入requestHeader开始,到收取responseHeader的时间差即可。
对于Android,我们通过OkHttp完成Http请求,通过向OkHttp注册网络监听即可实现。需要说明的是,在不修改源码的情况下,Android无法获取到收到第一个响应数据包的时间,只能监听到Header读取完成,这会有些许误差,但实测下来可以忽略。
对于其他客户端内通过自行实现Http协议栈发起的网络请求(如PCDN),我们通过向其注册特定的监听回调,也能获取到HttpRTT。
采集样本过滤
HttpRTT包含了服务器处理时间,而当服务器处理时间过长或过低时对其他普遍意义上的Http请求参考价值相对较低,因此我们需要排除这些数据:
-
localhost:如果向localHost发起请求,且响应的仅是缓存的数据,那么其HttpRTT时延明显接近于0;
-
PUT请求:由于PUT请求传输的数据量一般较大,其HttpRTT明显高于其他;
-
其他明显偏离的数据。
吞吐量(throughput)采集
throughput(bit/s , bps) = 单位时间内通过的数据量(bit) / 单位时间(s)
吞吐量的采集相对要复杂得多,吞吐量采集目的是获取用户所能使用的最大的数据率(或带宽),因而其需要在设备上恰好有大量数据正在传输时采集。对于主动探测来说,在无其他请求干扰的情况下,主动发起一个大数据量CDN下载请求即可快速测量出吞吐量。而被动探测则需要想办法预测或检测到大量数据传输的时刻,并适时计算吞吐量。
时间窗口
怎样选取计算吞吐量的时间窗口是计算吞吐量准确性的关键。这个窗口要恰好在大量数据正在传输时,不能早也不能晚。如果提前开启了时间窗口,那么同样的大小的数据通过,由于分母增大会导致计算出的数值偏低;如果数据传输完成后,稍晚关闭时间窗口,那么同样会由于分母增大而导致计算出的数值偏低。
我们知道Http请求或多或少会有上行/下行数据,但由于服务器处理耗时长短的不确定性(不能算在分母里),单个Http请求测速时并不可靠。而多个Http正在并发请求进行中的时候,其请求的流量会叠加,单个请求的服务器耗时会被其他Http请求覆盖,此时采集吞吐量会是个好的选择。因此,我们可以在监听到Http并发请求数量达到5个以上时采集吞吐量。