https://github.com/zacharyzcr/simultaneous-connection

RFC 793/Simultaneous Connection
https://github.com/zacharyzcr/simultaneous-connection

Last synced: 3 months ago
JSON representation

RFC 793/Simultaneous Connection

• Host: GitHub
• URL: https://github.com/zacharyzcr/simultaneous-connection
• Owner: ZacharyZcR
• Created: 2024-12-26T07:56:15.000Z (6 months ago)
• Default Branch: main
• Last Pushed: 2024-12-26T08:02:38.000Z (6 months ago)
• Last Synced: 2025-01-29T09:41:23.084Z (5 months ago)
• Language: Python
• Size: 3.91 KB
• Stars: 1
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# Simultaneous-Connection

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协议的设计和实现仍然很有价值。

## Python实现Simultaneous Connection

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

### 核心实现思路

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

```python

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)）来处理连接过程

- 双方都是主动发起连接，而不是传统的一方监听一方连接

### 连接建立过程

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

```python

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. 操作系统的处理也需要时间

### 数据交互验证

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

```python

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师傅的思路。