与Windows上的本地主机IPC上的命名pipe道相比,TCP套接字有多慢?

我正在开发一个TCP代理服务器,放在一个TCP服务器的前面,该服务器应该处理来自野生互联网的500到1000个活动连接。

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

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

两个代理套接字上的发送和接收窗口大小设置为1024个字节。

这对性能有什么影响? 这种configuration有多慢? 我应该把一些努力改变服务使用命名pipe道(或其他IPC机制),或本地TCP套接字大部分是一个有效的IPC?

两个应用程序的合并不是一个选项。 现在我们被困在两个过程configuration中。

编辑 :在同一个硬件上有两个单独的过程的原因是100%的经济。 我们只有一台服务器,而我们不打算多收(没钱)。

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

代理服务器是我们试图减轻服务的特定性能问题,这是我们不时得到的DDoS攻击 。

代理是开源的, 这里是项目源代码 。

Solutions Collecting From Web of "与Windows上的本地主机IPC上的命名pipe道相比,TCP套接字有多慢?"

这将是相同的(或至少没有明显不同)。 Winsock足够聪明,可以知道它是否与同一主机上的套接字通信,在这种情况下,它将在IP之下几乎全部短路,并将数据直接从缓冲区复制到缓冲区。 就命名管道和套接字而言,如果您需要将来有可能与不同的机器进行通信,请选择套接字。 如果你知道你永远不需要这样做的事实,选择你的开发人员最熟悉或最舒适的一个。

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

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

我们的测试系统中有一个典型的环回文件传输:

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

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

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

我意识到,这只是一个系统(Windows 7),但我认为这是一个很好的指标,可以如何缓慢的命名管道…似乎TCP是要走的路。

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

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

更何况,如果你坚持TCP,那么你将有一些可以缩放的东西,甚至当时间到了负载平衡。

干杯,

在你描述的场景中,本地TCP连接不太可能成为瓶颈。 当然,它会引入一些开销,但是除非你的CPU已经很热,否则这应该是微不足道的。

据猜测,如果服务器的CPU使用率通常低于50%左右(使用代理),则不必担心将本地TCP连接相关的开销降到最低。

如果CPU使用率定期高于80%,则应该进行一些性能分析。 我将首先比较CPU负载(或者更好的是,如果您可以有意义地衡量它的性能),当代理到位的时候。 除非代理正在做一些复杂的处理,否则与额外的TCP连接相关的开销可能是代理引入的总开销的一个重要部分,所以应该给你至少一个数量级的估计,通过使用更高效的IPC形式获得。

有什么理由在同一台机器上有一个代理,只是好奇?

无论如何:

对于IPC,TCP / IP有几种方法,命名管道在速度和复杂性上都是可比的。 如果你真的想要一些可以扩展的东西,几乎没有开销:使用共享内存。 最好和一个无锁算法一起使用来提升指针(或者为每个读者(代理/服务)和写者(服务/代理)使用一个缓冲区)。