明天太遥远，行动从今天开始
实验目的
通过实验简单了解 packetdrill 时间模型中的相对时间。
时间模型
由于许多协议对时间非常敏感，所以在「packetdrill」 脚本中增加了对时间灵活性的支持。每个语句都有一个时间戳，由 「packetdrill」 强制执行：如果事件没有在指定的时间发生，则 「packetdrill」 会标记一个错误并报告实际时间。
「packetdrill」时间模型
|
Model |
Syntax |
Description |
|
Absolute |
0.750 |
Specifies the specific time at which an event should occur. |
|
Relative |
+0.2 |
Specifies the interval after the last event at which an event should occur. |
|
Wildcard |
* |
Allows an event to occur at any time. |
|
Range |
0.750~0.9 |
Requires the given event to occur with in the timer ange. |
|
Loose |
--tolerance_usecs=800 |
Allows all events to happen with in a range(from the command line). |
|
Blocking |
0.750...0.9 |
Specifies a blocking system call that starts/returns at the given times. |
避免伪造失败
使用 --tolerance_usecs 参数值 4ms，使得事件只要在期望时间的 4ms 范围内发生，即认为测试是成功的。
基础脚本
# cat tcp_3hs_000.pkt// TCP 基础之三次握手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+0 < S 0:0(0) win 10000 <mss 1460>+0 > S. 0:0(0) ack 1 <...>+0.01 < . 1:1(0) ack 1 win 10000+0 accept(3, ..., ...) = 4
实际上基础脚本就是以相对时间来编写的，一般来说这种时间模式相对方便编写脚本。
相对时间
以 TCP 三次握手为基础，测试时间模型中的相对时间。所谓的相对时间，就是指定事件相较于上一个事件的时间间隔。
实验测试一
基础脚本测试，相关的脚本说明可详见《TCP 基础之三次握手》，本次测试重点研究下相对间隔时间。
抓包结果，第一个 SYN 的时间 19:46:05.868401，第二个 SYN/ACK 的时间 19:46:05.868424，协议栈自动回复，相对时间 +0 表示相较于上一个事件立即执行，再加上偏移时间，因此也就是预期 4ms 内响应即可，第三个 ACK 的时间 19:46:05.878522，相较第二个 SYN/ACK 时间间隔了大约 10ms，这也是脚本中 ACK 相较 SYN/ACK 的 0.01ms（10ms）的时间间隔体现。
# tcpdump -i any -nn port 8080tcpdump: data link type LINUX_SLL2tcpdump: verbose output suppressed, use -v[v]... for full protocol decodelistening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes19:46:05.868401 ? In IP 192.0.2.1.50695 > 192.168.66.16.8080: Flags [S], seq 0, win 10000, options [mss 1460], length 019:46:05.868424 ? Out IP 192.168.66.16.8080 > 192.0.2.1.50695: Flags [S.], seq 2677976254, ack 1, win 65535, options [mss 1460], length 019:46:05.878522 ? In IP 192.0.2.1.50695 > 192.168.66.16.8080: Flags [.], ack 1, win 10000, length 019:46:05.878592 ? Out IP 192.168.66.16.8080 > 192.0.2.1.50695: Flags [F.], seq 1, ack 1, win 65535, length 019:46:05.878601 ? In IP 192.0.2.1.50695 > 192.168.66.16.8080: Flags [R.], seq 1, ack 1, win 10000, length 0
实验测试二
初步修改的脚本，仍然关注 > SYN/ACK，修改为较 SYN 10ms 的间隔时间。
# cat tcp_3hs_time_005.pkt0 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+0 < S 0:0(0) win 10000 <mss 1460>+0.01 > S. 0:0(0) ack 1 <...>+0.01 < . 1:1(0) ack 1 win 10000+0 accept(3, ..., ...) = 4
测试结果，实际测试执行失败，提示了相关错误。时间错误：脚本期望的出向数据包在相对时间 0.01 秒 (系统执行有所偏差为 0.010064 秒)发出，但实际上协议栈在 0.000060 秒就发出了（需要记住的是，> 代表预期，表示预期协议栈会响应的数据包），即使默认偏移时间值在 0.004 秒，也就是 [ts-tolerance,ts+tolerance] 内，也不符合，因此执行失败。
# packetdrill tcp_3hs_time_005.pkttcp_3hs_time_005.pkt:7: error handling packet: timing error: expected outbound packet at 0.010064 sec but happened at 0.000060 sec; tolerance 0.004000 secscript packet: 0.010064 S. 0:0(0) ack 1actual packet: 0.000060 S. 0:0(0) ack 1 win 65535 <mss 1460>#
抓包结果，可以看到仅抓到两个包，也就是 SYN 和 SYN/ACK，因为在之后脚本错误停止了。
# tcpdump -i any -nn port 8080tcpdump: data link type LINUX_SLL2tcpdump: verbose output suppressed, use -v[v]... for full protocol decodelistening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes20:10:27.648394 ? In IP 192.0.2.1.52405 > 192.168.72.150.8080: Flags [S], seq 0, win 10000, options [mss 1460], length 020:10:27.648415 ? Out IP 192.168.72.150.8080 > 192.0.2.1.52405: Flags [S.], seq 1998792960, ack 1, win 65535, options [mss 1460], length 0
实验测试三
那么如何修改脚本呢？考虑到协议栈实际大都在 0.000060 秒就做出了响应，再加上默认偏移时间值在 0.004 秒内，因此相对时间写成 +0.004 秒的情况下，也就是 [0.000000,0.008000] 内，脚本是否会执行成功?
# cat tcp_3hs_time_006.pkt0 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+0 < S 0:0(0) win 10000 <mss 1460>+0.004 > S. 0:0(0) ack 1 <...>+0.01 < . 1:1(0) ack 1 win 10000+0 accept(3, ..., ...) = 4
脚本实际测试未成功，为什么？在错误提示中已经说明了原因，script packet: 0.004059 秒，因为还有一个自身执行的时间偏离，如果是 0.004059 秒，加上偏移就是在 [0.000059,0.008059] 内，真实数据包的 0.000054 秒不在其中，因此测试失败 。
# packetdrill tcp_3hs_time_006.pkttcp_3hs_time_006.pkt:7: error handling packet: timing error: expected outbound packet at 0.004059 sec but happened at 0.000054 sec; tolerance 0.004000 secscript packet: 0.004059 S. 0:0(0) ack 1actual packet: 0.000054 S. 0:0(0) ack 1 win 65535 <mss 1460>#
继续修改脚本，写成了 0.003 秒，这样 script packet 的执行时间加上偏移，肯定是在 [0.000000,0.007000] 内，脚本会执行成功。
# cat tcp_3hs_time_007.pkt0 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+0 < S 0:0(0) win 10000 <mss 1460>+0.003 > S. 0:0(0) ack 1 <...>+0.01 < . 1:1(0) ack 1 win 10000+0 accept(3, ..., ...) = 4
执行结果，尝试执行了三次均成功。
# packetdrill tcp_3hs_time_007.pkt# packetdrill tcp_3hs_time_007.pkt# packetdrill tcp_3hs_time_007.pkt#
抓包结果，第一个 SYN 的时间 20:46:05.100396，第二个 SYN/ACK 的时间 20:46:05.100415，协议栈自动回复，相对时间 +0.003 表示相较于上一个事件间隔 3ms，再加上偏移时间，因此也就是预期 7ms 内响应即可，第三个 ACK 的时间 20:46:05.110514，相较第二个 SYN/ACK 时间间隔了大约 10ms，这也是脚本中 ACK 相较 SYN/ACK 的 0.01ms（10ms）的时间间隔体现。
# tcpdump -i any -nn port 8080tcpdump: data link type LINUX_SLL2tcpdump: verbose output suppressed, use -v[v]... for full protocol decodelistening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes20:46:05.100396 ? In IP 192.0.2.1.57761 > 192.168.0.9.8080: Flags [S], seq 0, win 10000, options [mss 1460], length 020:46:05.100415 ? Out IP 192.168.0.9.8080 > 192.0.2.1.57761: Flags [S.], seq 2732724235, ack 1, win 65535, options [mss 1460], length 020:46:05.110514 ? In IP 192.0.2.1.57761 > 192.168.0.9.8080: Flags [.], ack 1, win 10000, length 020:46:05.110576 ? Out IP 192.168.0.9.8080 > 192.0.2.1.57761: Flags [F.], seq 1, ack 1, win 65535, length 020:46:05.110585 ? In IP 192.0.2.1.57761 > 192.168.0.9.8080: Flags [R.], seq 1, ack 1, win 10000, length 0
测试结论
考虑到脚本执行会去执行校验 > (代表预期，表示预期协议栈会响应的数据包)的情况，所以一般注意 > 处即可，而 < 代表注入数据包的时间，相对来说灵活一些。
简单来说，< 执行时间相对精准可控，> 执行时间预期范围可控。
相对时间，一般来说这种时间模式相对方便编写脚本，+0 即可，也就是预期 4ms 内得到响应，即认为测试是成功的。
往期推荐
原文始发于微信公众号（Echo Reply）：Wireshark & Packetdrill | 理解时间模型之相对时间
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论