Node.js 与 Haskell 混合网络编程踩坑记：TCP 粘包与状态不一致引发的“死锁”

1. 背景与目标

我们需要在 Node.js 中实现一个定制化的 TCP 客户端 (RSATransport)，用于连接现有的 Haskell 服务端。该协议包含自定义的握手流程和三种数据传输模式：

Plain (0) : 握手后明文直连。
RSA (1) : 全程使用 RSA-OAEP 加密。
AES (2) : 握手协商出 Session Key 后使用 AES-CTR 加密。

Haskell 服务端逻辑 (RSA.hs) ：服务端在握手时使用带缓冲的读取方式 (recvDataOaep)，但在切换到 Plain 模式后，直接操作底层 Socket (recvData tp)。

2. 问题现象

开发过程中出现了一个奇怪的现象：

AES 模式正常：握手、密钥交换、数据传输均流畅。
RSA 模式正常。
Plain 模式"卡死" ：握手看似完成，但随后发送的第一条数据服务端无响应，客户端也收不到回包。
"薛定谔的 Bug" ：如果在代码中加入 console.log，有时能跑通一点点，但随后依然卡住。

3. 根因深度分析

经过排查，这是一个典型的 TCP 粘包 遇上 应用层状态缓冲区设计缺陷 导致的逻辑死锁。

3.1 Haskell 服务端的"缓冲区旁路" Bug

在 RSA.hs 中，接收逻辑是这样的：

Haskell

sql 复制代码

-- Haskell 伪代码
recvData RSATP {..} n = case rsaMode of
  Plain -> recvData tp n           -- [关键点] 直接读底层 Socket，忽略缓冲区
  RSA   -> recvDataOaep readBuffer ... -- 从缓冲区 readBuffer 读取
  AES   -> recvDataAes readBuffer ...  -- 从缓冲区 readBuffer 读取

在握手阶段（协商 Mode），服务端调用的是 recvDataOaep。这个函数为了解密，可能会从 TCP Socket 预读取多于所需的字节（例如读取了 4096 字节，但 Mode 包只有 256 字节）。多余的数据被留在了 Haskell 的 readBuffer (TVar) 中。

3.2 Node.js 的"过于高效"

在 Node.js 客户端，当握手完成（发送了 Mode Byte）后，我们立即清空了积压的写入队列 (_writeBuffer) 并发送业务数据。

由于 TCP 的 Nagle 算法 和操作系统的缓冲机制，发送的 [Mode 包] 和后续的 [业务数据包] 极大概率被合并成了一个 TCP 段发送到了服务端。

3.3 致命的"擦肩而过"

于是发生了以下时序：

Client : 发送 [Mode=Plain][Data="Hello"]（在同一个 TCP 包中）。
Server : 调用 recvDataOaep 读取 Mode。它把整个 TCP 包读入内存，解析出 Mode=Plain，剩下的 Data="Hello" 留在了 readBuffer 中。
Server : 切换状态到 Plain。
Server : 调用 recvData tp 等待新数据。注意：它跳过了 readBuffer，直接去问底层 Socket 要数据！
Result : Socket 缓冲区是空的（数据已经被读到应用层缓冲区了），服务端挂起等待。客户端以为服务端收到了，也在等待响应。死锁形成。

4. 解决方案

要解决这个问题，必须在客户端打破"粘包"，确保服务端在处理完 Mode 切换后，Socket 缓冲区里才有新数据到达。

4.1 禁用 Nagle 算法

首先，禁止 TCP 延迟发送，确保小包（如握手包）能尽快发出去。

JavaScript

kotlin 复制代码

this._socket = net.connect(options);
this._socket.setNoDelay(true); // 禁用 Nagle

4.2 严格的写操作流控

不能依赖 Node.js 的自动缓冲，必须确保上一个包真正写入内核（drain）后，再发下一个包。

JavaScript

javascript 复制代码

// 使用回调链确保顺序
this._sendOAEP(modePayload, function() {
    // Mode 包写入完成后的回调
    self._finishHandshake();
});

4.3 针对 Plain 模式的"魔法延时"

这是最关键的一步。由于我们无法修改 Haskell 服务端代码，必须在客户端进行规避。在发送 Mode 包和发送第一条 Plain 数据之间，强制插入一个微小的延时（50ms）。

这给了服务端足够的时间：

处理 Mode 包。
清空其内部接收逻辑。
切换到 Socket 直接读取模式。

JavaScript

javascript 复制代码

RSATransport.prototype._finishHandshake = function() {
  this._state = 'ESTABLISHED';
  this.emit('connect');

  // 刷新积压的数据
  if (this._writeBuffer.length > 0) {
    const flush = () => {
      // ... 发送积压数据 ...
    };

    // 针对 Plain 模式的 Hack：
    // 强制延时，防止 Mode 包和后续数据粘包，
    // 避免服务端读取 Mode 时误读了后续数据到 Buffer 中却在 Plain 模式下无法访问。
    if (this._mode === MODE_PLAIN) {
      setTimeout(flush, 50); 
    } else {
      flush();
    }
  }
};

4.4 完善背压 (Backpressure) 处理

除了上述核心 Bug，我们还修复了 write 方法的返回值问题。当处于 Plain 模式（高吞吐）时，必须正确处理 TCP 的背压，否则会导致内存飙升或数据丢失。

JavaScript

kotlin 复制代码

// 转发底层的 drain 事件
this._socket.on('drain', () => this.emit('drain'));

// 正确返回 boolean
Transport.prototype.write = function(data, encoding, callback) {
  return this._socket.write(data, encoding, callback); 
};

5. 总结

这次排查再次验证了网络编程中的一条铁律：TCP 是流协议，不是包协议。

当客户端与服务端由不同语言编写，且服务端存在混合读取策略（Buffer读取 vs Socket直读）时，应用层必须极其小心地处理数据边界。

教训 1 : 不要假设 write 两次就会产生两个 TCP 包。
教训 2: 在处理协议状态切换（如握手 -> 传输）时，状态机的同步至关重要。
教训 3: 遇到"卡死"且日志影响行为时，优先怀疑缓冲机制和竞态条件。