Wireshark & Packetdrill | TCP 基础之三次挥手 - 新鲜讯息

必须动用已有的知识去解释新知识

实验目的

通过 packetdrill 测试 TCP 基础之三次挥手，本次构造模拟的是服务器端场景。

基础脚本

基础脚本为 TCP 三次握手，构造模拟的是服务器端场景，相关脚本说明详见。

# cat tcp_3wh_000.pkt 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 三次挥手，实际上就是第二个 ACK 和第三个 FIN 数据包进行了合并。为什么第二个 ACK 会延迟发送，简单来说是在收到第一个 FIN 数据包后，接收端会进入 pingpong 模式，也就不满足 quickack 模式，综合判断下不会立马发送 ACK ，最终就会 Delayed ACK，和之后的第三个 FIN 数据包一并发送。

和 TCP 四次挥手一样，首先发起 FIN 的可以是客户端，也可以是服务器端，以下分别模拟相关两种场景。

客户端测试

首先模拟客户端先注入 FIN 数据包，观察服务器端协议栈响应。

# cat tcp_3wh_001.pkt 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+0.1 < F. 1:1(0) ack 1 win 10000#

由于脚本最后的语句仅是注入 FIN ，所以脚本一执行完后就结束了，而 tcpdump 捕获数据包时未看到明显的服务器端响应，相关数据包说明如下。

# packetdrill cat tcp_3wh_001.pkt# # 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 bytes22:50:50.514327 tun0  In  IP 192.0.2.1.42457 > 192.168.29.218.8080: Flags [S], seq 0, win 10000, options [mss 1460], length 022:50:50.514355 tun0  Out IP 192.168.29.218.8080 > 192.0.2.1.42457: Flags [S.], seq 3091907294, ack 1, win 64240, options [mss 1460], length 022:50:50.524445 tun0  In  IP 192.0.2.1.42457 > 192.168.29.218.8080: Flags [.], ack 1, win 10000, length 022:50:50.624530 tun0  In  IP 192.0.2.1.42457 > 192.168.29.218.8080: Flags [F.], seq 1, ack 1, win 10000, length 022:50:50.624613 tun0  Out IP 192.168.29.218.8080 > 192.0.2.1.42457: Flags [F.], seq 1, ack 2, win 64239, length 022:50:50.624632 tun0  In  IP 192.0.2.1.42457 > 192.168.29.218.8080: Flags [R.], seq 2, ack 1, win 10000, length 0# 1. 前三个数据包为 TCP 三次握手数据包，略过。2. 第四个数据包为模拟注入的客户端 FIN 数据包。22:50:50.624530 tun0  In  IP 192.0.2.1.42457 > 192.168.29.218.8080: Flags [F.], seq 1, ack 1, win 10000, length 0// 对应于脚本 +0.1 < F. 1:1(0) ack 1 win 10000 ，与之前间隔 100ms 后 < 输入数据包，packetdrill 根据此行脚本各字段值构造的 FIN 数据包，注入到内核协议栈。3. 最后两个数据包 FIN/ACK 和 RST/ACK22:50:50.624613 tun0  Out IP 192.168.29.218.8080 > 192.0.2.1.42457: Flags [F.], seq 1, ack 2, win 64239, length 022:50:50.624632 tun0  In  IP 192.0.2.1.42457 > 192.168.29.218.8080: Flags [R.], seq 2, ack 1, win 10000, length 0// packetdrill 脚本之外产生的数据包，或者说预期之外的数据包。// 根据个人判断，在 packetdrill 脚本执行完毕后，socket 被强行关闭，如果有accept()的情况下，内核会发送 FIN/ACK 结束连接，没有accept()的情况下，则不会发送 FIN/ACK.// 最后一个为客户端所发送的 RST/ACK 结束连接，也像是 packetdrill 脚本默认构造，用于快速重置连接使用的。// 因此这两个数据包一般与 packetdrill 构建的测试脚本无关，分析时可省略。

在以上脚本最后增加 sleep 语句，使得脚本执行完不要退出。

# cat tcp_3wh_001.pkt 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+0.1 < F. 1:1(0) ack 1 win 10000+0 `sleep 100`#

如下测试后，可观察到在客户端注入 FIN 数据包后，服务器端响应了 ACK 数据包。

注意，服务器端仅仅是响应了 ACK ，是因为这里并没有模拟调用 close()，所以就没有后续第三个 FIN 数据包的发送。

# packetdrill tcp_3wh_001.pkt脚本执行完后未退出，可见光标闪烁。# 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 bytes12:50:27.494334 tun0  In  IP 192.0.2.1.34499 > 192.168.38.155.8080: Flags [S], seq 0, win 10000, options [mss 1460], length 012:50:27.494361 tun0  Out IP 192.168.38.155.8080 > 192.0.2.1.34499: Flags [S.], seq 346908529, ack 1, win 64240, options [mss 1460], length 012:50:27.504436 tun0  In  IP 192.0.2.1.34499 > 192.168.38.155.8080: Flags [.], ack 1, win 10000, length 012:50:27.604513 tun0  In  IP 192.0.2.1.34499 > 192.168.38.155.8080: Flags [F.], seq 1, ack 1, win 10000, length 012:50:27.610030 tun0  Out IP 192.168.38.155.8080 > 192.0.2.1.34499: Flags [.], ack 2, win 64239, length 0# 通过 ss 查询 TCP 连接状态为 CLOSE-WAIT。# ss -anto | grep 8080CLOSE-WAIT 1      0      192.168.210.130:8080       192.0.2.1:60155 #之后通过 CTRL+C 可终止脚本运行，如下：# packetdrill tcp_3wh_001.pkt^Ctcp_3wh_001.pkt:13: error executing `sleep 100` command: got signal 2 (Interrupt)# 再次通过 ss 查询 TCP 连接状态已经变成 LAST-ACK。# ss -anto | grep 8080LAST-ACK  1      1      192.168.210.130:8080       192.0.2.1:60155 timer:(on,348ms,3)      # 抓包结果如下，仅出现一个服务器发送的 FIN 数据包，与上面的 TCP 连接 LAST-ACK 对应。12:50:30.414159 ?     Out IP 192.168.38.155.8080 > 192.0.2.1.34499: Flags [F.], seq 1, ack 2, win 64239, length 0

最后脚本增加服务器端 close 发送 FIN ，完成 TCP 三次挥手完整过程。

# cat tcp_3wh_002.pkt 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+0.1 < F. 1:1(0) ack 1 win 10000+0 close(4) = 0+0 > F. 1:1(0) ack 2+0.01 < . 2:2(0) ack 2 win 10000#

# packetdrill tcp_3wh_002.pkt ## 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 bytes22:02:28.319674 tun0  In  IP 192.0.2.1.46827 > 192.168.233.140.8080: Flags [S], seq 0, win 10000, options [mss 1460], length 022:02:28.319707 tun0  Out IP 192.168.233.140.8080 > 192.0.2.1.46827: Flags [S.], seq 3459722375, ack 1, win 65535, options [mss 1460], length 022:02:28.329813 tun0  In  IP 192.0.2.1.46827 > 192.168.233.140.8080: Flags [.], ack 1, win 10000, length 022:02:28.429878 ?     In  IP 192.0.2.1.46827 > 192.168.233.140.8080: Flags [F.], seq 1, ack 1, win 10000, length 022:02:28.429915 ?     Out IP 192.168.233.140.8080 > 192.0.2.1.46827: Flags [F.], seq 1, ack 2, win 65535, length 022:02:28.439993 ?     In  IP 192.0.2.1.46827 > 192.168.233.140.8080: Flags [.], ack 2, win 10000, length 022:02:28.440096 ?     In  IP 192.0.2.1.46827 > 192.168.233.140.8080: Flags [R.], seq 2, ack 2, win 10000, length 0#

服务器端测试

通过 close ，服务器端先发送 FIN 数据包，之后注入客户端 FIN 数据包，最后完成服务器端 ACK 。

# cat tcp_3wh_003.pkt 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+0 close(4) = 0+0 > F. 1:1(0) ack 1+0.01 < F. 1:1(0) ack 2 win 10000+0 > . 2:2(0) ack 2 <..å.>#

执行脚本，并通过 tcpdump 捕获数据包，可观察到 TCP 三次挥手完整过程。

# packetdrill tcp_3wh_003.pkt ## 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 bytes22:05:45.899665 tun0  In  IP 192.0.2.1.51661 > 192.168.18.58.8080: Flags [S], seq 0, win 10000, options [mss 1460], length 022:05:45.899693 tun0  Out IP 192.168.18.58.8080 > 192.0.2.1.51661: Flags [S.], seq 2001050617, ack 1, win 65535, options [mss 1460], length 022:05:45.909805 tun0  In  IP 192.0.2.1.51661 > 192.168.18.58.8080: Flags [.], ack 1, win 10000, length 022:05:45.909913 tun0  Out IP 192.168.18.58.8080 > 192.0.2.1.51661: Flags [F.], seq 1, ack 1, win 65535, length 022:05:45.920001 tun0  In  IP 192.0.2.1.51661 > 192.168.18.58.8080: Flags [F.], seq 1, ack 2, win 10000, length 022:05:45.920031 tun0  Out IP 192.168.18.58.8080 > 192.0.2.1.51661: Flags [.], ack 2, win 65535, length 022:05:45.920164 tun0  In  IP 192.0.2.1.51661 > 192.168.18.58.8080: Flags [R.], seq 2, ack 2, win 10000, length 0#1. 前三个数据包为 TCP 三次握手数据包，略过。2. 第四个数据包为服务器 close 所发出的 FIN 数据包。22:05:45.909913 tun0  Out IP 192.168.18.58.8080 > 192.0.2.1.51661: Flags [F.], seq 1, ack 1, win 65535, length 0// 对应于脚本 +0 > F. 1:1(0) ack 1 ，close 关闭连接，预期服务器协议栈发出 FIN 。3. 第五个数据包为注入的客户端 FIN 数据包。22:05:45.920001 tun0  In  IP 192.0.2.1.51661 > 192.168.18.58.8080: Flags [F.], seq 1, ack 2, win 10000, length 0// 对应于脚本 +0.01 < F. 1:1(0) ack 2 win 10000 ，为客户端关闭连接所发送的 FIN，此处模拟合并了第二个 ACK 。4. 第六个数据包为服务器的 ACK 数据包。22:05:45.920031 tun0  Out IP 192.168.18.58.8080 > 192.0.2.1.51661: Flags [.], ack 2, win 65535, length 0// 对应于脚本 +0 > . 2:2(0) ack 2 <...>，预期服务器收到客户端的 FIN 所发送的 ACK 确认。5. 最后一个数据包 RST/ACK22:05:45.920164 tun0  In  IP 192.0.2.1.51661 > 192.168.18.58.8080: Flags [R.], seq 2, ack 2, win 10000, length 0// packetdrill 脚本之外产生的数据包，或者说预期之外的数据包。// 客户端所发送的 RST/ACK 结束连接，如前所述是 packetdrill 脚本默认构造，用于快速重置连接使用的。// 因此这个数据包一般与 packetdrill 构建的测试脚本无关，分析时可省略。