javascript - 重用 TCP 客户端和 TCP 服务器之间打开的一个 TCP 连接

Question

有第三方服务公开 TCP 服务器，我的 Node 服务器(TCP 客户端)应使用 tls Node 模块与其建立 TCP 连接。作为 TCP 客户端， Node 服务器同时也是 HTTP 服务器，它应该充当来自 Web 浏览器的客户和第三方 TCP 服务器之间的代理。因此，常见的用例是浏览器将 HTTP 请求发送到 Node 服务器， Node 服务器将通过 TCP 套接字与 TCP 服务器通信，以收集/构建响应并将其发送回浏览器。

我当前的解决方案是，每个客户/每个 HTTP 请求来自网络浏览器将与 TCP 服务器建立新的独立 TCP 连接。事实证明这个解决方案很糟糕，每次都浪费时间进行 SSL 握手，并且 TCP 服务器不允许来自单个客户端的并发连接超过 50 个。因此，使用此解决方案，不可能有超过 50 个客户同时与 Node 服务器通信。

使用 Node 中的 tls 模块执行此操作的标准方法是什么？

我要做的是拥有一个 TCP 连接，该连接将始终处于事件状态，并且该连接将在 Node 应用程序启动时建立，最重要的是该连接应重用于 许多 HTTP 请求来自网络浏览器。

我首先关心的是如何根据通过 TCP 原始套接字来自 TCP 服务器的数据构建不同的 HTTP 响应。好处是，在描述 TCP 服务器端应采取哪些操作时，我可以通过 header 向 TCP 服务器发送类似 unique token 的内容。

socket.write(JSON.stringify({
  header: {uniqueToken: 032424242, type: 'create something bla bla'},
  data: {...}
}))

拥有唯一的 token TCP 服务器端保证，当 JSON 由来自 TCP 套接字的不同 block 组合并解析时，将具有此 uniqueToken 这意味着我能够将此 JSON 映射到HTTP 请求并返回 HTTP 响应。

我的问题是，一般来说，TCP 协议(protocol)是否保证在这种情况下，不同的连续 block 将属于在组合和解析这些 block 时需要创建的相同响应(当 '\n\n' 发生)换句话说，是否可以保证 block 不会被混合。(我知道包含 '\n\n' 的 block 可能属于两个不同的响应，但我能够处理它)

如果这是不可能的，那么我看不到可以改进第一个解决方案(为需要创建的一个响应提供一个连接)的方法。唯一的方法是引入一些连接池概念，据我所知，tls 模块并没有以任何方式提供开箱即用的功能。

根据以下评论进行编辑，问题的简短版本:假设 TCP 服务器在收到命令 create some bla bla 时需要 2 秒来发送所有数据 block 如果 TCP 客户端发送命令创建一些 bla bla，并在 1 毫秒后立即发送第二个创建一些 bla bla，那么 TCP 服务器是否有可能写入相关的 block 在写入与第一个命令相关的所有 block 之前，先执行第二个命令。

Answer 1

... is there any chance that could happen that TCP server will write chunk related to second command before it writes all chunks related to first command.

如果我正确理解你的问题，你是在问服务器上的同一个套接字上是否有一个 write("AB") 后跟一个 write("CD")端可能会导致客户端从服务器读取 ACDB。

如果两次写入都成功并且实际上已将所有数据写入底层套接字缓冲区，则情况并非如此。但是，由于 TCP 是一种没有隐式消息边界的流协议(protocol)，因此客户端的读取可能类似于 ABCD 或 AB 后跟 CD或 A 后跟 BC 后跟 D 等。因此，为了区分来自服务器的消息，您必须添加一些应用程序级别的消息检测，例如消息结束标记、大小前缀或类似内容。

此外，我将前面的语句限制为两次写入都成功并且实际上已将所有数据写入底层套接字缓冲区。情况不一定如此。例如，您可能会执行缓冲写入的函数，例如(在 C 中)fwrite 而不是 write。在这种情况下，您通常无法控制在何时写入缓冲区的哪些部分，因此 fwrite("AB") 可能会导致“A”写入套接字，而“B”写入套接字” 保存在缓冲区中。如果您有另一个缓冲写入器，它使用相同的底层文件描述符(即套接字)但不是相同的缓冲区，那么您实际上可能会得到类似 ACDB 的内容发送到底层套接字，从而发送到客户端.

如果无缓冲写入未完全成功，即如果 write("AB") 仅写入了“A”并通过“B”所需的返回值发出信号，则甚至可能发生这种情况稍后再写。如果您有一个多线程应用程序，线程之间的同步不足，则可能会出现以下情况:第一个线程在不完整的尝试写入“AB”时将“A”发送到套接字，然后另一个线程发送“CD”成功，然后第一个线程再次通过写入“B”完成发送。在这种情况下，您最终还会在套接字上得到“ACDB”。

总之:TCP 层保证发送顺序与接收顺序相同，但用户空间(即应用程序)需要确保它确实以正确的顺序将数据发送到套接字。此外，TCP 没有消息边界，因此需要在应用程序内部使用消息边界、长度前缀、固定消息大小等来区分 TCP 流内的消息。