不错的网络协议栈测试工具 — Packetdrill

Packetdrill - A network stack testing tool developed by Google.

项目:https://code.google.com/p/packetdrill/

本文:zhangskd @ csdn blog

 

简介

 

The packetdrill scripting tool enables quick, precise tests for entire TCP/UDP/IPv4/IPv6 network stacks,

from the system call layer down to the NIC hardware.

截至2013年开源时,Packetdrill已经在Google内部使用了18个月,主要用于以下几个用途:

 

(1) Regression testing of network stack

"we have a suite of hundreds of packetdrill scripts that are run by all developers on our team before

submitting a patch for review."

对网络协议栈进行回归测试,确保新的功能不会影响网络协议栈的可用性。

总共包含657个test cases。

 

(2) Test-driven development of network protocols

"we have developed several new features for Linux TCP using packetdrill."

在以下几个TCP新特性的开发中发挥重要作用:

Early Retransmit

Fast Open

Loss Probes

Rewrite of F-RTO

 

(3) Reproduction of bugs seen in production network traces

"we have used packetdrill to isolate hard-to-reproduce bugs seen in complex real traces."

使用它发现了Linux内核的10个bug。

 

安装和使用

 

(1) 安装

首先安装flex和bison,用于构建词法和语法分析器。

然后编译即可:

cd packetdrill

./configure

make


(2) 使用

./packetdrill test.pkt

test.pkt为按Packetdrill语法编写的测试脚本。

成功:无输出,表示脚本正确,一切都符合预期。

失败:指出脚本的错误地方,以及原因。

 

语法

 

The tool supports four types of statements: packets, system calls, shell commands, and Python scripts.

Each statement is timestamped and is executed by the interpreter in real time, verifying that events

proceed as the script expects.

脚本中可以包含四种语句:数据包、系统调用、shell命令、python语句。

每条语句都必须以时间戳开头,指明它的执行时间。

 

(1) Packets

数据包分为:输入的数据包、输出的数据包,格式类似于tcpdump的,

支持TCP、UDP、ICMP,以及TCP的大部分选项。

 

输入的数据包(input packets)

对于输入的数据包(<表示输入),packetdrill会构造一个真实的数据包,然后注入协议栈。

< denotes an input packet to construct and inject into the system under test.

Here's an example of a TCP SYN packet, which packetdrill creates and injects into the

network stack under test 100ms after the start of the test:

0.100 < S 0:0(0) win 32792 <mss 1000, nop, nop, sackOK, nop, wscale 6>

 

输出的数据包(outbound packets)

对于输出的数据包(>表示输出),packetdrill会检查协议栈是不是真的发出了这样一个包。

> denotes an output packet to sniff and verify, to expect the system to send.

Here's an example of an outbound UDP packet expected to be sent immediately after

a prior event(denoted by +0), which packetdrill sniffs and then verifies for matching

specification:

+0 > udp (1472)

 

(2) System Calls

系统调用的格式类似于strace。

对于每个系统调用,packetdrill会在指定的时间给予执行,并检查返回值是否和预期的一样。

Here's an example of a bind() system call invocation in packetdrill notation:

+0 bind(3, ..., ...) = 0

In this example, 3 denotes the file descriptor number to pass in, and the = 0 denotes the expected

return value (i.e.., the user expects the system call to succeed).

The ellipsis (...) allows scripts to omit irrelevant details.
 

(3) Shell Commands

允许在脚本中使用shell命令,用反引号括起来。

+0 `sysctl -q net.ipv4.tcp_timestamps=0`

 

(4) Python Commands

允许在脚本中使用Python命令,用%{和}%括起来。

Packetdrill allows inline Python code snippets to print information and to make assertions about the

internal state of a TCP socket using the TCP_INFO getsockopt() option.

The following Linux-based example asserts that the sender's congestion window is 10 packets:

+0 %{ assert tcpi_snd_cwnd == 10 }%

 

(5) 时间戳

每条语句都必须以时间戳开头,指明它的执行时间,或者预期事件的发生时间。

时间戳可以使用多种格式:

Absolute(绝对时间):0.75

Relative(相对时间):+0.2

Wildcard(任意时间):*

Range(绝对时间区间):0.750~0.900

Relative Range(相对时间区间):+0.1~+0.2

Loose(允许误差值):--tolerance_usecs=800

Blocking(阻塞时间区间):0.750...0.900

 

如果在规定的时间戳,对应的事件并没有发生就会报错,并告知该事件的实际发生时间。

+1.0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 6>

预期在1s以后TCP应该发送一个SYNACK包。

在实际的使用中,一般指定--tolerance_usecs=405000,也就是允许4ms的时间误差。

 

(6) 完整例子

验证TCP的快速重传功能,fast retransmit说白了就是收到3个重复的ACK或SACK后马上重传一个数据包

(对于FACK来说只要孔>=3个包即可)。

脚本中服务器端的协议栈是要观测的对象,对应的是输出的数据包(outbound packet)。

脚本中客户端对应的是输入的数据包(inbound packet),用于注入协议栈。

完整例子如下:

// Establish a connection. 服务端socket函数调用
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0

// 客户端的socket函数调用不用显式指出
// 客户端构造SYN包,注入协议栈
+0 < S 0:0(0) win 32792 <mss 1000, sackOK, nop, nop, nop, wscale 7>

// 预期协议栈发送SYNACK包
+0 > S. 0:0(0) ack 1 <...>

// 客户端构造ACK包,注入协议栈,完成三次握手
+.1 < . 1:1(0) ack 1 win 257

// 服务端接受连接
+0 accept(3, ..., ...) = 4

// Send 1 data segment and get an ACK,构造收发包场景
+0 write(4, ..., 1000) = 1000
+0 > P. 1:1001(1000) ack 1
+.1 < . 1:1(0) ack 1001 win 257
+0 %{ print tcpi_snd_cwnd }%

// Write 4 data segments
+0 write(4, ..., 4000) = 4000
+0 > P. 1001:5001(4000) ack 1

// Get 3 SACKs,构造快速重传场景
+.1 < . 1:1(0) ack 1001 win 257 <sack 2001:3001, nop, nop>
+0 < . 1:1(0) ack 1001 win 257 <sack 2001:4001, nop, nop>
+0 < . 1:1(0) ack 1001 win 257 <sack 2001:5001, nop, nop>

// We've received 3 duplicate ACKs, so we do a fast retransmit.
// 收到3个SACK后,预期协议栈会快速重传
+0 > . 10001:2001(1000) ack 1

// Receiver ACKs all data.
+.1 < . 1:1(0) ack 6001 win 257

 

实现

 

Packetdrill是一个用户态应用程序,主要用C语言编写。

使用flex构造词法分析器,使用bison构造语法分析器。

脚本解释器包括一个主线程和一个用于执行阻塞的系统调用的线程。

使用packet socket来验证输出的数据包,使用TUN device来注入输入的数据包。

具体代码可见项目。

 

测试案例

 

一些用于测试具体场景的测试案例:

fast_retransmit // 快速重传

early_retransmit // ER补丁测试

blocking // 阻塞的系统调用

fast_recovery // PRR补丁测试

initial_window // 初始cwnd

init_rto // SYNACK包的RTO

close

connect

icmp

inet_diag

ioctl

listen

mss

pmtu_discovery

receiver_rtt

sack

shutdown

undo

 

run_tests.h为一个测试脚本:

#!/bin/bash
for f in `find . -name "*.pkt" | sort`; do
    echo "Running $f ..."
    ip tcp_metrics flush all &> /dev/null
    ../../packetdrill $f
done

注意:Due to TCP metrics caching in recent kernels, a second run of all tests can result in failures.

The script run_tests.sh in this directory uses the iproute tool to flush the TCP metrics cache

before each test.

这些测试脚本在3.11.0-12-generic中都能通过。

偶尔有timing error,是正常现象,可用--tolerance_usecs=405000指定允许的时间误差。

 

我的体验

 

测试一个简单的场景:连接建立后,服务端发送10个包。

这时候处于慢启动阶段,cwnd是指数增长的。

按理来说每收到1个ACK,cwnd++;每收到1个delayed ACK,cwnd+=2。最终cwnd应该为20。

但测试结果表明,最终cwnd为12。

进一步分析发现这是受到拥塞窗口有效性验证机制的影响,当发送是受到应用程序的限制(没有新数据可供发送),

而不是受到cwnd的限制时,不允许增加cwnd。

当然,这只是一个小例子,说明Packetdrill有助于网络协议栈的分析。

 

优缺点

 

任何一个工具都有优点和限制,Packetdrill也不例外。

 

(1) 优点

属于脚本测试工具,能够快速和方便的测试网络协议栈,自由的构造测试场景。

因为是用脚本测试,所以快速方便,不用大动干戈。

可以在产品机上直接测试,因此测结果是真实的。

场景可重现,测试可自动执行。

比较通用,支持IPv4和IPv6,支持多种操作系统。

 

(2) 缺点

属于黑盒测试工具,虽然它能通过TCP_INFO选项从内核中获取一些信息,但是这些信息毕竟有限。

当预期结果不符时,缺少信息来做进一步判断。

编写测试脚本时,需要对要构造的场景十分了解,知道协议栈是如何具体处理的(对每一步了如指掌)。

所以,当场景比较复杂时(比如涉及到较多的数据包、往返时延),编写脚本的难度大大增加了。

另外目前只支持测试单条连接,不允许同时测试多条连接。

 

Reference

 

[1] packetdrill: Scriptable Network Stack Testing, from Sockets to Packets

[2] Drilling Network Stacks with packetdrill

[3] https://code.google.com/p/packetdrill/

 

你可能感兴趣的:(不错的网络协议栈测试工具 — Packetdrill)