Network问题Q&A（1）
1.
答：有可能是客户修改了任务超时时间，超时时间短可能会导致进程还没结束就被强制中断，这样日志无法获取到。建议不要修改超时时间
2.
答：系统账号下无法使用 WebGL,我们是默认开启了的（简单来说就是实现不了）。
3.
答：着重去看客户端重定向次数，另外之前 chrome 的话有个小问题会在额外等待时间里面的数据抓不全（该问题已经修复，所以之前多加了重定向次数的任务现在会导致任务超时），另外 IE10 和 IE11 浏览器下，如果客户使用了 localstorage 技术，我们会无法获取到这一部分的数据
4.
答：节点的错误代码如果是 6XXXXX,那么错误数据不算进趋势图里面。原因是防止错误节点数据在算平均值的时候造成影响。比如十个点平均的总下载时间是 3 秒，一个节点报错任务超时，120S 结束，如果这个点的数据被统计到趋势里面的话，平均值被拉高到 12S，这明显是不准确的
5.
答：和本次任务无关。这个节点最近一小时内做过流媒体任务，那么最后一次流媒体任务算出来的下载速度就是平均下载速度
6.
答：会把任务下发给不支持 HTTPS 的手机去做任务，导致数据不全或者无法执行任务。
7.
答：只有在客户端传回来的任务数据，在对数据进行解析出现错误的情况下 让客户端再次做任务，重新传一次。
8.
答：该节点在最近执行流媒体任务中（这个不确定是多少次或者是多久），播放过程中没有出现再缓冲情况的点数占总点数的比例
9.
答：chrome 内核支持绝大部分的 2.0 协议，如果网站和客户端使用了 2.0 协议，那么有一个特征 响应头的状态码是 200，而 1.1 版本则是 200 OK
10.
答：可以，但是需要独立开启 OPSAPI
11.
答：因为真机只下 200K 左右，所以肯定和全部下载完的 MD5 值（差一个字节的数据，MD5 值都会不一样）不一样
12.
答：因为 VLC 的播放模式时边下边播。虽然只有一条元素资源，但其实 VLC 是一部分一部分去下载的，每次下载会在 HTTP 头中带有 range 头指定下载哪一部分的资源。所以注意看状态码应该是 206，那么在加载的过程中，如果有一段视频下载的时候无法连接，就会报错无法建连（警告）
13.
答：因为 为了控制流量节省成本，我们在发 HTTP 请求的时候自带了 range 头，表示只请求前 2K 的数据，如果客户想多下载就让他配置 HTTP 头，但是要考虑好成本问题并且目前下载数据大了，我们的报表展示的数据会有问题。
14.
答：会对手机的 CPU、网络延时、丢包这三项来做出是否下发任务的判断
15.
答：负数才是对的。抓到的正数应该是 85dBm 从代码角度来说就是抓到的信号值无效，默认给了 85 这个指标