这段时间，负责的App底座登录时，因为用户所处网络环境有问题，导致登录失败，而用户级别挺高，是业务的高层，直接投诉。导致我们必须优化登录和网络检测监控，除了加强链路和用户行为跟踪、修改提示语外，还必须添加一个网络诊断，让用户明白，这就是网络的锅，和我们代码或逻辑实现木有关系。
为此，经过搜索了网络诊断的资料，经过整理，还需要考虑移动App的实现，得出以下技术方案。
上述是真正背景和需求缘由。
1、背景
一个App功能的整体表现，往往与用户当前的网络状况密不可分。当客户端处于弱网或本地网络异常时，我们的App存在两个缺点：
1、目前没有收集此时客户端的本地网络信息导致用户报障时无法准确排查问题。
2、目前客户端没有提供用户主动网络诊断的入口，用户无法直观知道究竟是自己网络问题还是App后端服务问题。
如果可以为App提供一个的网络诊断功能，让用户明确功能出现阻断的原因，既可以提高用户体验，还可以收集那些能够衡量当前网络状况的重要信息。然后在征得用户同意的情况下，将信息上报到服务端进行分析，可以有针对性地对网络链路中的薄弱环节进行优化。
这里的网络诊断主要是针对特定的域名或者ip，也就是说App的网络诊断是对当前网络到域名指向的服务端的连通性和带宽情况。
1.1 导致本地网络异常的原因可能有
断网
DNS挟持、DNS解析出错
本地代理异常
防火墙拦截
1.2 对应的诊断方式
系统API判断是否有网络接连
查看本地DNS服务
查看本地代理配置
Traceroute拨测相关域名
通过HTTP发送HEAD或GET请求模拟浏览器的访问行为来检查会请求到的后端服务
2. 网络诊断的工具
常用的网络工具或者方式，包括ping、DNS、traceroute、网络测速
2.1 PING 测试
通过 ping 后端服务地址得到的信息诊断当前网络跟服务器是否畅通以及丢包率。比如：
ping xxx.xxx
正在 Ping xxx.xxx [10.18.43.243] 具有 32 字节的数据: 来自 10.18.43.243 的回复: 字节=32 时间=5ms TTL=250 来自 10.18.43.243 的回复: 字节=32 时间=4ms TTL=250 来自 10.18.43.243 的回复: 字节=32 时间=4ms TTL=250 来自 10.18.43.243 的回复: 字节=32 时间=5ms TTL=250
10.18.43.243 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 4ms，最长 = 5ms，平均 = 4ms
android可以通过下边的代码发送命令：
val command = "ping -c $packageCount -w 15 -t $ttl $url"
Runtime.getRuntime().exec(command)
2.2 DNS 解析
DNS（Domain Name System），它的作用就是根据域名，查出对应的 IP 地址，它是 HTTP 协议的前提。只有将域名正确的解析成 IP 地址后，后面的 HTTP 流程才可以继续进行下去。
DNS 服务器的要求，一定是高可用、高并发和分布式的服务器。它被分为多个层次结构。
根 DNS 服务器：返回顶级域 DNS 服务器的 IP 地址。
顶级域 DNS 服务器：返回权威 DNS 服务器的 IP 地址。
权威 DNS 服务器：返回相应主机的 IP 地址。
这三类 DNS 服务器，类似一种树状的结构，分级存在。