TCP套接字与Windows上用于localhost IPC的命名管道相比有多慢？

Question

我正在开发一个TCP代理,它将放在TCP服务之前,该服务应该处理来自通配Internet的500到1000个活动连接.

代理与服务在同一台机器上运行,并且大部分都是透明的.该服务在很大程度上不知道代理,唯一的例外是通知客户端的真实远程IP地址.

这意味着,对于每个入站打开的TCP套接字,服务器上还有两个套接字:代理中的第二个套接字,以及代理后面的真实服务上的套接字.

两个代理套接字上的send和recv窗口大小设置为1024字节.

对此有何影响？这个配置有多慢？我是否应该努力改变服务以使用命名管道(或其他IPC机制),或者localhost TCP套接字在很大程度上是一个有效的IPC？

这两个应用程序的合并不是一种选择.现在我们坚持使用两个流程配置.

编辑:在同一硬件上进行两个独立过程的原因是100%经济性.我们只有一台服务器,我们不打算获得更多(没有钱).

TCP服务是Visual Basic 6中的遗留软件,它超出了我们的预期.代理是C++.我们没有时间,金钱和人力来重写和迁移VB6代码到现代编程环境.

代理是我们尝试缓解服务的特定性能问题,这是我们不时会遇到的DDoS攻击.

代理是开源的,这是项目源代码.

Answer 1

它将是相同的(或至少不可测量的不同).Winsock非常聪明,可以知道它是否与同一主机上的套接字进行通信,在这种情况下,它会使IP以下的所有内容短路,并将数据直接复制到缓冲区到缓冲区.就命名管道与套接字而言,如果您将来可能需要能够与不同的计算机进行通信,请选择套接字.如果你知道一个事实,你永远不需要这样做,那么选择你的开发人员最熟悉或最熟悉的那个.

Answer 2

对于后来阅读此内容的任何人,我想添加一些回答原始问题的发现.

对于我们正在开发的实用程序,我们有一个可以使用命名管道的网络类,或者具有相同调用的TCP.

以下是我们测试系统上的典型环回文件传输:

TCP/IP传输时间:2.5秒
命名管道传输时间:3.1秒

现在,如果你走出机器并连接到网络上的远程计算机,命名管道的性能会更差:

TCP/IP传输时间:12秒
命名管道传输时间:2.5分钟(是分钟!)

我意识到这只是一个系统(Windows 7)但是我认为这是一个很好的指标,表明命名管道的速度有多慢......而且似乎TCP就是这样.

Answer 3

我知道这个话题很古老，但它对我来说仍然很重要，也许其他人将来也会关注这个话题。

我通过 TCP 连接和命名管道在 Excel (VBA) 和同一台机器上的另一个进程之间实现了 IPC。

在快速性能测试中，我从客户端 (Excel) 向服务器（不是 Excel）提交了一条由 26 个字节组成的消息，并等待来自其他进程的回复消息（在示例中由 12 个字节组成）。我在一个循环中执行了很多次并测量了平均执行时间。

使用本地主机上的 TCP（Windows 7，没有快速路径），一次“对话”（请求+回复）大约需要 300-350 微秒。尤其是发送数据非常慢（通过 TCP 发送 26 字节大约需要 200 微秒）。使用 Named Pipes，一次对话平均需要大约 60 微秒 - 所以要快很多。

我不完全确定为什么差异如此之大。我测试的公司环境有严格的防火墙、包检查等等，所以我认为这可能是因为即使基于 localhost 的 TCP 连接通过了安全措施，显着减慢了它的速度，而命名管道的可能没有.

TL:DR：在我的例子中，命名管道比 TCP 快 5-6 倍，用于小包（还没有测试过更大的包）

Answer 4

http://msdn.microsoft.com/en-us/library/aa178138(v=sql.80).aspx

让我给你总结一下。如果您担心性能，请使用 TCP/IP。但是，如果您有一个非常快的网络并且您不担心性能，那么命名管道将是“整洁的”，因为它可能会为您节省一些代码。

更不用说，如果您坚持使用 TCP，那么您将拥有可以扩展的东西，甚至在时机成熟时可以进行负载平衡。

干杯，