基于SO_TIMESTAMP追踪Docker容器跨内核网络包处理时延问题
问题背景
我希望追踪Docker容器的Linux网络栈包处理时延。据我了解，容器的引入会让到达容器的数据包产生更多开销，因为需要经过主机内核和Docker容器内核两个内核栈，这理应带来更高的时延和内核包处理时延。
已开展工作
我在搭载Docker的CentOS系统上进行测试，通过一款工具利用SO_TIMESTAMP追踪包处理时延：当数据包离开NIC进入内核时，以timeval格式返回时间戳；用户空间程序调用recvmsg后，调用gettimeofday()，两者差值即为包处理时延。在CentOS 3.10.xxx内核版本的主机上运行程序时，包处理时延约为~100us，但在两个Docker容器中运行相同代码时，得到的时延几乎相同。
核心疑问
引入容器及其内核栈后，包处理时延理应增加。我的逻辑是：Docker容器内程序的SO_TIMESTAMP仅会在数据包进入虚拟网卡veth0时，让容器自身内核生成时间戳，这属于软件时间戳，读数精度较低。但容器与主机系统时间一致，总处理时延理应约为~200us。请问是否可以利用SO_TIMESTAMP追踪跨两个内核栈的包处理时延？另外，针对上述RX栈，追踪反向的TX栈时延的最佳方式是什么？
问题解答
关于SO_TIMESTAMP追踪跨内核栈时延的可行性
首先要明确：Docker容器并没有独立的内核栈——容器共享主机的内核，只是通过网络命名空间实现网络隔离。这是你测试时延没有翻倍的核心原因。
SO_TIMESTAMP在容器内获取的时间戳，本质上是数据包在主机内核中进入容器网络命名空间对应的veth设备时生成的，并非容器有独立内核处理。所以你无法通过容器内的SO_TIMESTAMP直接追踪跨“两个内核栈”的时延，因为从物理NIC到容器进程的路径全程都在主机内核中处理，只是经过了veth pair的转发。
如果要完整追踪数据包从物理NIC到容器进程的全路径时延，需要在主机侧和容器侧分别埋点：
- 主机侧：在物理网卡或主机端的veth接口上捕获数据包进入内核的时间戳（可以用
SO_TIMESTAMP或者eBPF） - 容器侧：在容器内的veth接口捕获数据包进入用户进程的时间戳
两者的差值才是完整的端到端处理时延。
追踪TX栈时延的最佳方式
针对容器发送数据包的TX路径，推荐以下几种实用方案：
- eBPF工具：这是最灵活且精度最高的方案，使用
bcc或bpftrace编写脚本，在数据包从容器进程发出（sendmsg系统调用）、离开容器veth、离开主机物理网卡这几个关键点打时间戳，计算各段时延。例如可以追踪net_dev_queue（数据包进入主机发送队列）和netif_tx_start（数据包离开网卡）等内核函数，结合用户态的sendmsg调用时间戳。 SO_TIMESTAMPING扩展：使用SO_TIMESTAMPING选项（区别于基础的SO_TIMESTAMP），它可以获取数据包在不同阶段的时间戳，比如用户态调用发送的时间、内核将数据包放入发送队列的时间、数据包离开物理网卡的时间。在容器内设置该选项后，能获取到发送路径中内核处理的关键时间点。- tc（Traffic Control）工具：在主机的veth接口或物理网卡上使用
tc的ingress/egress钩子，配合clock动作记录时间戳，统计转发时延。这种方式配置简单，但精度和灵活性不如eBPF。
内容的提问来源于stack exchange，提问作者akastack
