netcat的-q选项到底能做什么？

我有一项服务，该服务的行为一直在代理后面进行调试。代理是一个黑匣子，但是可以使用以下简单的python程序来模拟服务的行为：

#!/usr/bin/env python

import socket
import sys
import time

PORT = int(sys.argv[1] or 50007)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
    s.bind(('', PORT))
    s.listen(1)
    conn, addr = s.accept()
    print('conn from %s' % (addr,))
    data = conn.recv(1024)
    time.sleep(1)
    conn.sendall(data)
finally:
    conn.close()
    s.close()

当我使用netcat直接连接到此服务器时，我得到了预期的行为，即在用换行符向stdin发送一些任意文本之后，服务器延迟一秒钟，将其回显并关闭连接。但是，当我将此服务放在代理后面时，netcat会立即以状态0退出，除非我给它提供带有非零数字的-q选项，此后其行为与直接连接相同。

在我的系统上从netcat的手册页中引用：

-q      after EOF on stdin, wait the specified number of seconds and then quit.
        If seconds is negative, wait forever.

我要调试的是代理连接行为的不同之处，它将导致连接行为与-q选项不同，并且不幸的是，手册页在帮助我方面没有做什么。如果不是我的输入（它从未收到我的EOF），它指的是“ stdin”？-q长时间忽略什么EOF才能从中接收代理返回的数据，而在没有代理进行中介连接时，它不必忽略呢？

编辑：根据要求，这里有一些示例调用，尽管它们与获得的基本一样：

# after starting the example server on  with  
foo
$

# the above, just with -q1 (no change)
$ echo foo | nc -q1  
foo
$

# after starting the example server behind the blackbox proxy
$ echo foo | nc  
$

# same, but with -q
$ echo foo | nc -q1  
foo
$

void.. 5

echo foo | netcat在所有情况下都发送EOF。不同之处在于netcat关闭其网络套接字的方式。

如果没有-qnetcat，则在收到EOF之后立即发送TCP FIN，从而关闭其一半的TCP连接。那不是完全关闭连接，只是表明将不再发送任何数据。之后，netcat继续从连接中打印数据，直到关闭为止。

普通服务器不处理FIN的netcat延迟，延迟，发送回显响应，然后关闭连接的后半部分。

黑盒代理似乎通过立即关闭连接对客户端的FIN做出反应。这可能是某种服务器负载优化，例如，对于许多Web浏览器来说，这很有用。

使用-qnetcat直到服务器关闭连接或-q超时结束才发送FIN 。

在下运行您的四种情况tcpdump -w，然后在Wireshark中加载捕获文件，按照TCP流查看差异。请注意，此netcat行为可能取决于特定版本，对于Ubuntu 16.04 + netcat-openbsd 1.105，我确认了这一行为。

echo foo | netcat在所有情况下都发送EOF。不同之处在于netcat关闭其网络套接字的方式。

如果没有-qnetcat，则在收到EOF之后立即发送TCP FIN，从而关闭其一半的TCP连接。那不是完全关闭连接，只是表明将不再发送任何数据。之后，netcat继续从连接中打印数据，直到关闭为止。

普通服务器不处理FIN的netcat延迟，延迟，发送回显响应，然后关闭连接的后半部分。

黑盒代理似乎通过立即关闭连接对客户端的FIN做出反应。这可能是某种服务器负载优化，例如，对于许多Web浏览器来说，这很有用。

使用-qnetcat直到服务器关闭连接或-q超时结束才发送FIN 。

在下运行您的四种情况tcpdump -w，然后在Wireshark中加载捕获文件，按照TCP流查看差异。请注意，此netcat行为可能取决于特定版本，对于Ubuntu 16.04 + netcat-openbsd 1.105，我确认了这一行为。