linux下tcp/udp数据包收发延迟的来源

Question

linux 2.6中发送/接收TCP/UDP数据包的延迟来源是什么？

我想知道“乒乓”延迟测试中的延迟来源。

有一些关于以太网延迟的很好的论文，但它们只涵盖了线路和交换机中的延迟源(并且相当粗略，仅针对特定的交换机)。

数据包之后的处理步骤是什么？

具有常见ping的深度延迟分析(icmp)的论文也会很有用。

我依赖于社区:)

Answer 1

尽管它很旧，但本指南详细介绍了linux网络堆栈。

http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html

如果你通读这里，你应该能够发现可以通过内核增加延迟的地方。

例如，如果在内核中临时缓冲了帧

Answer 2

Short Answer：对于内核中的确切延迟，您应该使用perf探测和perf脚本。

More details：让我们看看下面的例子。首先，我们想看看TCP乒乓测试使用了哪些函数(我使用的是netperf)。

在接收流上：

​

在传输流上：

​

因此，让我们跟踪传输流的一些函数(它很长，所以我将展示TCP流中的主要函数)。我们可以使用perf探针来采样每个函数的入口点和出口点：

perf probe --add sock_sendmsg='sock_sendmsg'
perf probe --add sock_sendmsg_exit='sock_sendmsg%return'
perf probe --add inet_sendmsg='inet_sendmsg'
perf probe --add inet_sendmsg_exit='inet_sendmsg%return'
perf probe --add tcp_sendmsg_exit='tcp_sendmsg%return'
perf probe --add tcp_sendmsg='tcp_sendmsg'
perf probe --add tcp_sendmsg_locked='tcp_sendmsg_locked'
perf probe --add tcp_sendmsg_locked_exit='tcp_sendmsg_locked%return'
perf probe --add sk_stream_alloc_skb='sk_stream_alloc_skb'
perf probe --add sk_stream_alloc_skb_exit='sk_stream_alloc_skb%return'
perf probe --add tcp_push_exit='tcp_push%return'
perf probe --add tcp_push='tcp_push'
perf probe --add tcp_send_mss='tcp_send_mss'
perf probe --add tcp_send_mss_exit='tcp_send_mss%return'
perf probe --add __tcp_push_pending_frames='__tcp_push_pending_frames'
perf probe --add __tcp_push_pending_frames_exit='__tcp_push_pending_frames%return'
perf probe --add tcp_write_xmit_exit='tcp_write_xmit%return'
perf probe --add tcp_transmit_skb_exit='tcp_transmit_skb%return'
perf probe --add tcp_transmit_skb='tcp_transmit_skb'

不，我们可以记录以下内容：

perf record -e probe:* -aR taskset -c 7 netperf -t TCP_RR -l 5 -T 7,7

并为延迟报告运行perf脚本：

perf script -F time,event --ns

输出(1次迭代)：

525987.403094082:                   probe:sock_sendmsg:
525987.403095586:                   probe:inet_sendmsg:
525987.403096192:                    probe:tcp_sendmsg:
525987.403098203:             probe:tcp_sendmsg_locked:
525987.403099296:                   probe:tcp_send_mss:
525987.403100002:              probe:tcp_send_mss_exit:
525987.403100740:            probe:sk_stream_alloc_skb:
525987.403101697:       probe:sk_stream_alloc_skb_exit:
525987.403103079:                       probe:tcp_push:
525987.403104284:      probe:__tcp_push_pending_frames:
525987.403105575:               probe:tcp_transmit_skb:
525987.403110178:               probe:tcp_transmit_skb:
525987.403111640:          probe:tcp_transmit_skb_exit:
525987.403112876:          probe:tcp_transmit_skb_exit:
525987.403114351:            probe:tcp_write_xmit_exit:
525987.403114768: probe:__tcp_push_pending_frames_exit:
525987.403115191:                  probe:tcp_push_exit:
525987.403115718:        probe:tcp_sendmsg_locked_exit:
525987.403117576:               probe:tcp_sendmsg_exit:
525987.403118082:              probe:inet_sendmsg_exit:
525987.403118568:              probe:sock_sendmsg_exit:

现在很容易看出延迟是在哪里花费的。例如，我们可以注意到，在sock_sendmsg()调用和inet_sendmsg()调用之间有1504纳秒(ns)或1.504微秒(us)的延迟。另外，我们可以看到sk_stream_alloc_skb需要957 ns。总的来说，整个过程(从sock_sendmsg进入到退出)大约需要24.5us。请记住，这不是您在netperf中看到的情况，因为数据包是在流中间的某个位置物理传输的。

您可以使用相同的方法来跟踪内核中的任何代码片段。

希望这能有所帮助。

P.S.这是在内核-4.14上完成的，而不是2.6。不确定perf当时是如何开发的，所以它可能不会工作得很好。