nettracker
-
Ping方式：相当于执行ping命令
- 功能：检查端到端的连通性，查看对端的响应时间（包括最短，最长，平均）及丢包率
- 优缺点：探测过程快，结果简明易懂，但是无法知道链路上各节点状况
- 适用场景：在不关心链路上各节点信息，只希望判断对端可用性的情况下推荐该方式
-
MTR方式：相当于执行MTR命令
- 功能：查看链路上各节点的ip地址、响应时间（包括最短，最长，平均）及丢包率
- 优缺点：能够得知链路上各节点状况，判断问题所在，但探测过程需要时间，结果相对复杂，需要相关人员具备基本的网络知识
- 适用场景：在关注链路整体状态，希望定位问题节点的情况下推荐该方式
- v1.9.5及以上版本支持该功能
- 相关功能均有由类KSYNetTracker实现
- KSYNetTracker支持一个对象完成多次探测，不需要每次探测前都重新创建对象
- 完成本次探测时需要调用stop方法，方可调用start启动下一次探测
- 探测过程中修改配置项不会立即生效，下次调用start启动探测时生效，建议所有配置项的修改在启动探测前进行
| 属性/方法 | 默认值 | 说明 | 有效范围 |
|---|---|---|---|
| action | KSY_NETTRACKER_ ACTION_MTR | 探测方式: Ping 或者 MTR | KSY_NETTRACKER_ACTION_MTR - KSY_NETTRACKER_ACTION_PING |
| timeout | 1000 | 探测报文的超时时间，单位是ms | 100 - 2000 |
| maxttl | 64 | 探测使用的最大ttl值 | 1 - 0x7FFFFFFF |
| number | 10 | 探测次数 | 1 - 20 |
- 完成一次探测时发送一次通知
- 监听到此消息后可通过routerInfo获取已完成的统计结果
- 如果当前的探测方式为KSY_NETTRACKER_ACTION_PING，则在usrInfo字典中，关键字count指明当前的探测次数；关键字rtt表示本次探测消耗的时间，单位是ms
- 完成所有探测通知时发送此消息
- 监听到此消息后可通过routerInfo获取全部统计结果
- 获取到探测结果后需要调用stop方法结束本次探测
- 探测过程中出现错误时发送此消息
- 监听到此消息后，应调用stop方法结束探测
tracker = [[KSYNetTracker alloc] init];
[[NSNotificationCenter defaultCenter]addObserver:self
selector:@selector(handleTrackerNotify:)
name:(KSYNetTrackerOnceDoneNotification)
object:tracker];
[[NSNotificationCenter defaultCenter]addObserver:self
selector:@selector(handleTrackerNotify:)
name:(KSYNetTrackerFinishedNotification)
object:tracker];
[[NSNotificationCenter defaultCenter]addObserver:self
selector:@selector(handleTrackerNotify:)
name:(KSYNetTrackerErrorNotification)
object:tracker];
tracker.action = KSY_NETTRACKER_ACTION_MTR;
[tracker start:@"www.baidu.com"];
5. 获取探测结果routerInfo
for(KSYNetRouterInfo *netInfo in tracker.routerInfo)
{
if(netInfo.ips)
{
j = 0;
for(NSString *ip in netInfo.ips)
{
if(j == 0)
{
infoLog = [infoLog stringByAppendingFormat:@"%-3d", i];
infoLog = [infoLog stringByAppendingFormat:@"%-16s", [ip UTF8String]];
infoLog = [infoLog stringByAppendingFormat:@"%-4d", netInfo.number];
infoLog = [infoLog stringByAppendingFormat:@"%5.1fms", netInfo.tmax];
infoLog = [infoLog stringByAppendingFormat:@"%5.1fms", netInfo.tmin];
infoLog = [infoLog stringByAppendingFormat:@"%5.1fms", netInfo.tavg];
infoLog = [infoLog stringByAppendingFormat:@" %-6.1f", netInfo.tdev];
infoLog = [infoLog stringByAppendingFormat:@"%-4.1f\n", netInfo.loss];
}
else
infoLog = [infoLog stringByAppendingFormat:@" %-16s\n", [ip UTF8String]];
j++;
}
}
i++;
}
[tracker stop];
MTR的探测结果较为复杂，以探测www.baidu.com的结果为例说明该如何分析结果：
index ip number max min avg stdev lost
1 192.168.1.1 10 10.509 1.031 2.973 2.822 0.000
2 222.131.152.1 10 101.489 3.340 23.731 30.151 0.000
3 61.51.241.89 10 12.628 2.785 7.677 3.090 0.000
4 202.106.34.9 10 21.660 4.554 8.572 4.931 0.000
5 123.126.7.42 10 35.747 3.054 10.681 10.835 0.000
6 123.125.248.94 10 89.131 3.909 15.220 24.925 0.000
7 -- -- -- -- -- -- --
8 -- -- -- -- -- -- --
9 61.135.169.125 10 24.862 3.549 8.281 6.239 0.000
-
stdev提供了数据包在每个主机的标准偏差，它反应了链路的稳定状况。如果标准偏差越高，说明数据包在这个节点的延时越不相同；反之说明节点延迟越稳定。它会让您了解到平均延时是否是真的延时时间的中心点，或者测量数据受到某些问题的干扰。
-
第2跳直接延迟很大。但是第3跳之后，延迟又恢复正常了。最后的延迟差不多为8ms。像这种情况，是不影响实际情况的。因为可能仅仅是第2跳设备限制了ICMP传输速率的原因。所以一般情况下建议使用最后一跳的实际延迟为准。
-
第7跳和第8跳没有ip及相关信息，可能有两个原因：
- 第7跳和第8跳的设备禁止了ICMP报文的发送
- 第9跳的设备不支持响应ttl过小的ICMP报文
-
如果探测报文的转发路径出现变化，则探测结果中可能会出现一跳上有多个ip地址的情况
