python - Linux TCP 奇怪的行为

Question

我们正在尝试分析各种 TCP 实现(Windows 8、Ubuntu 13.10)的行为。为此，我们使用 Scapy ，一种 Python 工具，可用于制作数据包、通过网络发送数据包并分析响应。

在我们的设置中，我们有一个假的 Scapy 引导客户端和一个监听服务器。通过客户端，我们向服务器发送一系列 TCP 数据包并检查响应。服务器只接受连接而不对它们做任何事情。目的是获得一个简单但更具体的服务器行为模型。我们从模型中省去了/忽略了重传、窗口甚至数据交换等复杂性。

在分析 Windows 8 上监听服务器的行为时，我们得到了一个非常好的模型。然而，在 Ubuntu 上进行实验时，我们遇到了不确定的行为，至少对我来说，这很难解释。我在这里附上了 wireshark 日志的图像，其中包含类似输入数据包的几个“运行”。每次运行都通过随每次运行递增的端口执行。 奇怪的场景遵循以下模式:

client ---- SYN 0 _ ---> server [LISTENING]
client <- SYN+ACK 0 1 -- server [SYN_RCVD]

client -- ACK+FIN 1 1 -> server [SYN_RCVD]
client <--- ACK 1 2 ---- server [CLOSE_WAIT]

client ---- ACK 1 20 --> server [CLOSE_WAIT]
client <--- ACK 1 2 ---- server [CLOSE_WAIT] or no_response [CLOSE_WAIT]

任何人都可以向我解释，为什么在收到无效确认(确认一个从未存在过的段)时，服务器的行为是否具有不确定性？也就是说，要么重新发送它为 ACK+FIN 发送的 ACK，要么不发送任何内容。此行为是由配置参数引起的吗？在我们的设置中，我们使用默认设置。

顺便说一句，简单的服务器代码:

while (true) {
   try {
      Socket socket = server.accept();
   } 
   catch (IOException e) {}
}

更新

我分析了模型，对于 Windows 8，当运行相同的序列时，出现超时。这不符合 rfc793明确规定的标准:

If the connection is in a synchronized state (ESTABLISHED,FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),any unacceptable segment (out of window sequence number orunacceptible acknowledgment number) must elicit only an emptyacknowledgment segment containing the current send-sequence numberand an acknowledgment indicating the next sequence number expectedto be received, and the connection remains in the same state.

你们中的一些人可以阐明这一点吗？协议(protocol)实现是为了符合标准，还是存在一定程度的不合规？我想其中一些是不可避免的，因为标准有时无法指定时间限制，但这里我们讨论的是控制流程中的不合规。

显然我做错事的可能性仍然存在。 :)

谢谢，保罗。

Answer 1

您的服务器是用 Java 编写的吗？我猜你观察到的“非确定性”是由于 GC 计时，如果你显式调用 Socket#close() 或等待 InputStream#read() 可能会消失。