TCP协议中一个鲜为人知但很有趣的特性是simultaneous connection（同时连接）。这个特性在1981年发布的RFC 793（TCP协议规范）中就已经定义，但在实际应用中很少被使用。

传统的TCP连接建立过程是一方作为服务器（监听方），另一方作为客户端（发起连接方）。但RFC 793实际上还定义了另一种连接建立方式：双方可以同时向对方发起连接请求。具体来说，双方都可以直接发送SYN包，而不需要任何一方处于LISTEN状态。

这种同时连接的建立过程是这样的：

1. 双方同时发送SYN包，进入SYN-SENT状态
2. 双方收到对方的SYN包后，发送SYN-ACK包，进入SYN-RECEIVED状态
3. 双方收到SYN-ACK包后，发送ACK包，连接建立

虽然这种连接方式在协议层面是完全合法的，但它在实际应用中面临几个主要挑战：

1. 时机要求严格，两端需要在非常接近的时间点发起连接
2. 很多操作系统的网络协议栈实现可能并不完全支持这种模式
3. 中间设备（如防火墙）可能会干扰这种连接方式
4. 在有NAT设备的情况下更难实现

正是由于这些原因，实际应用中几乎总是采用传统的客户端-服务器模式来建立TCP连接。不过，了解和研究simultaneous connection对于深入理解TCP协议的设计和实现仍然很有价值。

为了验证RFC 793中描述的simultaneous connection，我们编写了一个Python程序来模拟这个过程。这个实验在本地主机（localhost）上使用两个不同的端口来测试同时连接的建立。

1. 程序创建两个线程，分别代表连接的两端。每个线程：

def connect_endpoint(local_port, remote_port):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.bind(('127.0.0.1', local_port))
    sock.setblocking(False)
    sock.connect(('127.0.0.1', remote_port))

这段代码中的关键点是：

• 不调用listen()，直接尝试connect()
• 使用非阻塞模式（setblocking(False)）来处理连接过程
• 双方都是主动发起连接，而不是传统的一方监听一方连接

在实验中，我们观察到连接建立需要一定的重试机制：

while True:
    try:
        sock.getpeername()
        print(f"端口 {local_port} 成功建立连接到端口 {remote_port}!")
        break
    except socket.error:
        retry_count += 1
        time.sleep(0.1)

这个重试机制是必要的，因为：

1. 两端的连接请求可能不是完全同时发出的
2. 网络包的传输有延迟
3. 操作系统的处理也需要时间

为了验证连接的可用性，我们实现了心跳包机制：

def handle_connection(sock, local_port):
    while True:
        message = f"来自端口 {local_port} 的心跳包 - {time.strftime('%H:%M:%S')}"
        sock.send(message.encode())
        received = sock.recv(1024).decode()

这个实现证明：

1. simultaneous connection建立的连接是双向的
2. 连接建立后的行为与普通TCP连接完全相同
3. 可以保持长连接并持续通信

在Windows和Linux系统上运行这个程序，我们可以通过netstat命令观察到：

1. 没有任何端口处于LISTENING状态
2. 连接建立后，两个端口都处于ESTABLISHED状态
3. 连接的建立完全符合RFC 793中描述的simultaneous connection模式

1. 传统网络监控工具的局限性

• 大多数监控工具基于常规的Server-Client模式设计
• 主要关注LISTENING状态的端口和对应连接
• 可能无法有效识别simultaneous connection

2. EDR系统的检测盲点

• 传统EDR重点监控listen()系统调用
• 对于纯connect()建立的连接可能存在检测死角
• 需要更全面的网络行为分析机制

感谢@wonderkun师傅的思路。