大 iPhone Ping 时间是否表明应用程序延迟？答案

【问题标题】：Are Large iPhone Ping Times Indicative of Application Latency?大 iPhone Ping 时间是否表明应用程序延迟？
【发布时间】：2010-04-20 20:18:39
【问题描述】：

我正在考虑创建一个实时应用程序，其中 iPod Touch/iPhone/iPad 与服务器端组件（产生 MIDI，并在主机中向前发送）对话。当我在 Wifi 上 ping 我的 iPod Touch 时，我得到了巨大的延迟（以及巨大的差异）：

64 bytes from 192.168.1.3: icmp_seq=9 ttl=64 time=38.616 ms
64 bytes from 192.168.1.3: icmp_seq=10 ttl=64 time=61.795 ms
64 bytes from 192.168.1.3: icmp_seq=11 ttl=64 time=85.162 ms
64 bytes from 192.168.1.3: icmp_seq=12 ttl=64 time=109.956 ms
64 bytes from 192.168.1.3: icmp_seq=13 ttl=64 time=31.452 ms
64 bytes from 192.168.1.3: icmp_seq=14 ttl=64 time=55.187 ms
64 bytes from 192.168.1.3: icmp_seq=15 ttl=64 time=78.531 ms
64 bytes from 192.168.1.3: icmp_seq=16 ttl=64 time=102.342 ms
64 bytes from 192.168.1.3: icmp_seq=17 ttl=64 time=25.249 ms

即使这是 iPhone->Host 或 Host->iPhone 时间的两倍，15ms+ 对于我正在考虑的应用程序来说也太长了。 有没有更快的方法（例如 USB 数据线）？如果没有，在 Android 上构建应用会提供任何其他选择吗？

Traceroute 报告更多可行时间：

traceroute to 192.168.1.3 (192.168.1.3), 64 hops max, 52 byte packets
 1  192.168.1.3 (192.168.1.3)  4.662 ms  3.182 ms  3.034 ms

谁能帮我解读一下 ping 和 traceroute 之间的区别，以及它们对于需要与主机通信（和从主机通信）的应用程序可能意味着什么？

【问题讨论】：

我一直假设 traceroute 和 ping 都使用相同的技术（icmp 包），因此认为它们基本相同 -> 期待阅读答案。
谢谢@Till，根据第一个答案，显然差异不仅仅是发送的字节数。
悲伤 - 这种 IP 包的膨胀听起来像是 iPhone 虚拟乐器干扰会议不可行......（我怀疑你正在计划；））
@Till，我刚刚与 DSMI 的创建者（dsmi.tobw.net 已经在此之上构建了应用程序）通过电子邮件发送，他曾经说过期望 17 毫秒的延迟。他说现在应该更少了，而且有了 iPod Touch。所以我的下一步是试用现有的应用程序，看看它们的“感觉”如何。这会比在这里提问更实用，但更不有趣。

标签： iphone android latency

【解决方案1】：

我认为这可能是 WiFi 省电模式要了你的命。我认为手机会缓冲数据包并仅偶尔发送出去。我在使用的 N900 上通过 WiFi 看到了类似的行为。

请注意您发布的 ping 中的强烈模式。这很可能是由 ping 和天线周期性地打开和关闭所产生的节拍模式。

【讨论】：

我暂时将此标记为最佳答案，让我们看看其他人是否有话要说。谢谢！
@Yar 根据 ping 间隔，我使用 UDP 的时间明显不同，所以我认为 Justin 对此很清楚。这是我自己回答的问题：stackoverflow.com/questions/17859732/…
ping 和 traceroute 之间的一个区别是数据包间计时。 Ping 每秒定期发送一个数据包（如果您告诉它，则更少）。 traceroute 在收到答复后立即发送另一个查询。 Traceroute 的行为可能会使无线电保持开启状态，而 ping 的行为允许无线电有时间关闭，并且再次通电需要更长的时间，从而导致更高的延迟。详情见@Nuoji 的帖子。

【解决方案2】：

请记住，ping 的“往返”包括 host1->AP->host2->AP->host1 的时间，而 traceroute 的“往返”包括 host1->AP->host1。那些 ping RTT 时间实际上相当不错。在我家，它们平均接近 250 毫秒，而我的 3GS 经常达到 300 毫秒以上。

Ping 响应时间受内核可用性的影响。如果 ICMP 请求进入时 CPU 正忙，则它会被缓冲，直到 CPU 可以处理它。这种阻塞有很多机会发生在像 iPhone 这样资源受限的设备上（或者说，一个负担过重的路由器）。此外，iPhone OS 会在一定程度上尝试对数据包进行排队，以便以突发方式传输。这可以防止无线电连续发射，从而节省电力。当然，这会影响延迟，并会挑战任何需要低和/或稳定延迟的应用程序（例如 VoIP）。

目前没有针对 USB 本身的 TCP/IP 的公共标准（与 1394 相反，有）。由于 USB 是串行链路层，理论上可以使用您自己的协议或预定义的协议（例如 PPP）通过扩展坞连接器传递数据。一旦建立了 EASession，就会通过正常的 NSInputStream/NSOutputStream 进行通信。

【讨论】：

谢谢。那么，什么更可能反映应用到应用的数据发送、ping 或 traceroute 或两者都不是？
这在很大程度上取决于您计划如何进行“应用程序到应用程序的数据发送”。 TCP 将具有与 UDP 不同的特性，XMPP 将具有与 HTTP 不同的特性等。我不太担心 ping 和 traceroute，只需对您的预期传输进行峰值解决方案，看看会发生什么。顺便说一句，Android 设备的 ping 时间与您在 iPhone 上看到的一样。
感谢@CommonsWare，接下来我将测试一些现有的应用程序以获得一个想法。构建我自己的，只是为了对这个潜在的瓶颈进行原型制作，使用这些 Objective-c 的东西（对于那些必须学习它的人来说）是昂贵的。
有大量适用于 iPhone 的现场表演应用程序。不要让延迟让您失望。您可以考虑通过 UDP 传输压缩的 PCM 数据，而不是传输 MIDI。根据编解码器，可以屏蔽丢弃的数据包。这条道路在 VoIP 世界中已被广泛采用。可以使用适当的缓冲区结构来管理数据包抖动。例如，许多 VoIP 系统可以处理高达 200 毫秒的数据包抖动和超过 1000 毫秒的数据包延迟。对于常见的应用程序，大多数人可能会容忍小于 300 毫秒的延迟。

【解决方案3】：

我在 Verizon 和 AT&T 开展了大量的蜂窝网络工作。指向移动设备时的 Ping 时间必须了解任何初始连接尝试都将高于正常情况。

如果我们看到的 ping RTT 基线平均可以为 AT&T 大约 300 毫秒。对于 Verizon 400 毫秒到 600 毫秒，它们甚至更高。

但每个运营商的第一个数据包必须首先找到移动设备。正因为如此，你得到的第一反应可能真的（真的）很高。 3000 毫秒到高达 4500 毫秒是我在我管理的网络上看到的，该网络有 2700 个移动端点，我们定期从监控系统连接到这些端点。

此外，任何具有大量射频噪声的环境都会产生延迟和丢包。即使是您的家也会产生大量噪音来干扰通过无线电运行的设备。

这可能没有帮助，但是...如果您可以使用具有更好缓冲功能的 API，您可能会更好...或者更仔细地查看您正在考虑使用的当前 API 的缓冲功能.

我希望你能成功 =)

【讨论】：

谢谢，这在一定程度上确实有帮助，+1