与 Windows 上用于本地主机 IPC 的命名管道相比，TCP 套接字有多慢？

How slow are TCP sockets compared to named pipes on Windows for localhost IPC?

提问by vz0

I am developing a TCP Proxy to be put in front of a TCP service that should handle between 500 and 1000 active connections from the wild Internet.

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

The proxy is running on the same machine as the service, and is mostly-transparent. The service is for the most part unaware of the proxy, the only exception being the notification of the real remote IP address of the clients.

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

This means that, for every inbound open TCP socket, there are two more sockets on the server: the secondth of the pair in the Proxy, and the one on the real service behind the proxy.

这意味着，对于每个入站打开的 TCP 套接字，服务器上还有两个套接字：代理中的第二个套接字和代理后面的真实服务中的一个。

The send and recv window sizes on the two Proxy sockets are set to 1024 bytes.

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

What are the performance implications on this? How slow is this configuration? Should I put some effort on changing the service to use Named Pipes (or other IPC mechanism), or a localhost TCP socket is for the most part an efficient IPC?

这对性能有什么影响？这个配置有多慢？我应该努力改变服务以使用命名管道（或其他 IPC 机制），还是 localhost TCP 套接字在很大程度上是一种高效的 IPC？

The merge of the two apps is not an option. Right now we are stuck with the two process configuration.

两个应用程序的合并不是一种选择。现在我们被困在两个进程配置上。

EDIT: The reason for having two separate process on the same hardware is 100% economics. We have one server only, and we are not planning on getting more (no money).

编辑：在同一硬件上有两个独立进程的原因是 100% 的经济性。我们只有一台服务器，我们不打算获得更多（没有钱）。

The TCP service is a legacy software in Visual Basic 6 which grew beyond our expectations. The proxy is C++. We don't have the time, money nor manpower to rewrite and migrate the VB6 code to a modern programming environment.

TCP 服务是 Visual Basic 6 中的遗留软件，其增长超出了我们的预期。代理是 C++。我们没有时间、金钱或人力来重写 VB6 代码并将其迁移到现代编程环境。

The proxy is our attempt to mitigate a specific performance issue on the service, a DDoS attackwe are getting from time to time.

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

The proxy is open source, and here is the project source code.

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

回答by Jeff Tucker

It will be the same (or at least not measurably different). Winsock is smart enough to know if it's talking to a socket on the same host and, in that case, it will short-circuit pretty much everything below IP and copy data directly buffer-to-buffer. In terms of named pipes vs. sockets, if you need to potentially be able to communicate to different machines ever in the future, choose sockets. If you know for a fact that you'll never need to do that, pick whichever one your developers are most familiar or most comfortable with.

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

回答by Joel Sundquist

For anyone that comes to read this later, I want to add some findings that answer the original question.

对于稍后阅读本文的任何人，我想添加一些回答原始问题的发现。

For a utility we are developing we have a networking class that can use named pipes, or TCP with the same calls.

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

Here is a typical loop back file transfer on our test system:

这是我们测试系统上的典型环回文件传输：

TCP/IP Transfer time: 2.5 Seconds
Named Pipes Transfer time: 3.1 Seconds

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

Now, if you go outside the machine and connect to a remote computer on your network the performance for named pipes is much worse:

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

TCP/IP Transfer time: 12 Seconds
Named Pipes Transfer time: 2.5 Minutes (Yes Minutes!)

TCP/IP 传输时间：12 秒
命名管道传输时间：2.5 分钟（是分钟！）

I realize that this is just one system (Windows 7) But I think it is a good indicator of how slow named pipes can be...and it seems like TCP is the way to go.

我意识到这只是一个系统（Windows 7）但我认为这是一个很好的指标，可以说明命名管道的速度有多慢……而且似乎 TCP 是要走的路。

回答by Bogey

I know this topic is very old, but it was still relevant for me, and maybe others will look at this in the future as well.

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

I implemented IPC between Excel (VBA) and another process on the same machine, both via a TCP connection as well as via Named Pipes.

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

In a quick performance test, I submitted a message than consisted of 26 bytes from client (Excel) to server (not Excel), and waited for the reply message from the other process (which consisted of 12 bytes in the example). I executed this a ton of times in a loop and measured the average execution time.

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

With TCP on localhost (Windows 7, no fastpath), one "conversation" (request+reply) took around 300-350 microseconds. Especially sending data was quite slow (sending the 26 bytes took around 200microseconds via TCP). With Named Pipes, one conversation took around 60 microseconds on average - so a LOT faster.

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

I'm not entirely sure why the difference was so large. The corporate environment I tested this in has a strict firewall, package inspections and what not, so I THINKthis may have been caused as even the localhost-based TCP connection went through security measures significantly slowing it down, while named pipe ones likely did not.

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

TL:DR: In my case, Named Pipes were around 5-6 times faster than TCP for small packages (have not tested with bigger ones yet)

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

回答by Dan

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

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

Let me sum it up for you. If you are worried about performance then use TCP/IP. But if you have a really fast network and your not worried about performance then Named Pipes would be "neat" in that it might save you some code.

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

Not to mention, if you stick to TCP then you will have something that can be scaled, and even load balanced when the time comes.

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

Cheers,

干杯，

回答by Harry Johnston

In the scenario you describe, the local TCP connections are very unlikely to be a bottleneck. It will introduce some overhead, of course, but this should be negligible unless your CPU is already running hot.

在您描述的场景中，本地 TCP 连接不太可能成为瓶颈。当然，它会引入一些开销，但这应该可以忽略不计，除非您的 CPU 已经很热了。

At a guess, if your server's CPU usage is normally below 50% or so (with the proxy in place) it isn't worth worrying about minimizing the overhead associated with the local TCP connections.

猜测一下，如果您的服务器的 CPU 使用率通常低于 50% 左右（使用代理），则不必担心最小化与本地 TCP 连接相关的开销。

If CPU usage is regularly above 80% you should probably be doing some profiling. I'd start by comparing the CPU load (or, better still, the performance, if you can measure it meaningfully) when the proxy is in place to when it isn't. Unless the proxy is doing some complicated processing, the overhead associated with the extra TCP connections is probably a significant fraction of the total overhead introduced by the proxy, so that should give you at least an order-of-magnitude estimate of how much you'd gain by using a more efficient form of IPC.

如果 CPU 使用率经常高于 80%，您可能应该进行一些分析。我首先比较代理存在时和代理不存在时的 CPU 负载（或者，更好的是，性能，如果您可以有意义地衡量它）。除非代理正在执行一些复杂的处理，否则与额外 TCP 连接相关的开销可能是代理引入的总开销的很大一部分，因此这至少应该给您一个数量级的估计d 通过使用更有效的 IPC 形式获得收益。

回答by Ritsaert Hornstra

What is the reason to have a proxy on the SAME machine, just curious?

在同一台机器上有代理的原因是什么，只是好奇？

Anyway:

反正：

There are several methods for IPC, TCP/IP, named Pipes are comparable in speed and complexity. If you really want something that scales well and has almost no overhead: use shared memory. Best used in combination with a lock free algorithm for advancing the pointers (or use one buffer for each reader (the proxy/the service) and writer(the service/the proxy)).

IPC有几种方法，TCP/IP，命名管道在速度和复杂度上都相当。如果你真的想要一些可以很好地扩展并且几乎没有开销的东西：使用共享内存。最好与无锁算法结合使用以推进指针（或为每个读取器（代理/服务）和写入器（服务/代理）使用一个缓冲区）。