使用 TCP Ack 来测量服务器的延迟？
我正在尝试测量我无法控制的服务器的延迟。这是在并置环境中，因此延迟约为 500 us (0.5 ms)。
据我了解，Cisco 设备经常降低 ICMP 流量的优先级，导致 ping 时间不可靠。有没有办法让我判断我正在移动的齿轮是否出现这种情况？
我可以使用 TCP 确认来确定远程服务器的最小延迟吗？为此，我需要以某种方式强制远程服务器在收到我的数据后立即发送 TCP 确认。
I am trying to measure latency to a server that I don't control. This is in a colocated environment, so the latency is on the order of 500 us (.5 ms).
I understand that Cisco gear frequently deprioritizes ICMP traffic, making ping times unreliable. Is there a way for me to tell if this is the case on the gear I am traversing?
Can I use TCP acknowledgements to determine the minimum latency to the remote server? To do this, I would somehow need to force the remote server to send a TCP ack immediately on receiving my data.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
尝试一下hping。您可以发送 ack 并测量延迟：
或使用 SYN：
另请注意，第 2 层链路上的优先级不太可能（但有可能）。此外，看到 ARP 比 ICMP 慢并不一定意味着 ICMP 没有被降低优先级，这可能意味着带宽不足以达到限制阈值。
ARP 几乎总是较慢，因为它进行广播并且可能会在交换机上遭受端口排队。您可以单播 ARP，但如果有人在寻找它，这可能会显得可疑。
Try hping. You can send acks and measure the latency:
or with a SYN:
Also note, deprioritization on a layer-2 link is unlikely (but possible). In addition, seeing ARP being slower than ICMP doesn't necessarily mean ICMP isn't deprioritized---it might mean bandwidth is insufficient to hit the limiting threshold.
ARP will almost always be slower because it broadcasts and may suffer port-queuing at the switch. You could unicast ARP, but that might look suspicious if anyone is looking for it.
您可以尝试使用
arping，它会执行以下操作：使用 ARP 进行 ping 操作。You could try using
arping, which does a ping using ARPs.