Linux下消息队列与TCP/IP Socket，哪种IPC性能更优？

Great question! Let's break this down specifically for your use case—process A sending small integer packets every 50ms to process B, with B sending a reply every 5 seconds.

Core Performance Differences #

The biggest gap between these two IPC mechanisms comes down to how they handle data transfer:

• Message Queues (like POSIX or System V queues) are kernel-level IPC. Data moves directly between processes via kernel memory, skipping all the overhead of network protocol stacks, TCP handshakes, or flow control.
• TCP/IP Sockets, even for local communication over the loopback interface, still go through the full TCP/IP stack. That means header encapsulation, checksum calculations, sliding window management, and connection state maintenance—all of which add extra CPU and latency cost.

Performance Analysis for Your Scenario #

Your setup has two key traits: high-frequency small packets (50ms intervals) and low-frequency replies (5 seconds apart). Here's how each mechanism stacks up:

1. Latency
   • Local TCP sockets typically have one-way latency in the single-digit to tens of microseconds range. Message queues, by contrast, clock in at sub-microsecond to a few microseconds. For your 50ms send interval, the absolute latency difference might seem small, but the protocol overhead of TCP adds up over time—especially with frequent sends. Message queues leave almost no footprint here.
   • Note: TCP is your only option for cross-host communication, but since your processes are on the same machine, message queues are fully applicable.
2. Throughput
   • For small packets like your integer payloads, message queues can easily handle millions of packets per second with minimal CPU usage. Local TCP sockets top out at hundreds of thousands to a million packets per second, but they'll consume more CPU doing it thanks to protocol stack processing.
3. Resource Overhead
   • Message queues don't require maintaining socket connections or TCP state (like TIME_WAIT or ESTABLISHED entries). This means lower kernel resource usage, which is ideal for long-running processes like yours.

Rough Speed Difference Benchmarks #

These are real-world test numbers (your results may vary based on hardware/kernel version):

• For a 10-byte packet (similar to your small integer payload):
  • POSIX Message Queue: ~0.5-2µs one-way latency, ~2M+ packets/sec throughput
  • Local TCP Socket: ~5-15µs one-way latency, ~500k-1M packets/sec throughput
• At your 20 packets/sec rate (50ms intervals), both will handle the load easily—but message queues will do it with far less CPU overhead.

Other Considerations #

• Reliability: Both are reliable, but TCP achieves this via retransmissions and ACKs (adding overhead). Message queues rely on kernel-level guarantees, which are more efficient.
• Ease of Use: TCP sockets have a universal API that works cross-platform/cross-host, but that comes with redundancy for local use. Message queue APIs are purpose-built for local IPC, making code simpler.
• Message Boundaries: Message queues natively preserve message boundaries—no need to handle packet sticking. TCP is a stream protocol, so you'll have to define your own packet format to split messages, adding a bit of development work.

Recommendation for Your Scenario #

If process A and B are running on the same Linux host, go with a POSIX message queue (it's more user-friendly than System V queues and performs just as well). It's the clear winner for your high-frequency small-packet needs, offering lower latency, lower CPU usage, and simpler code.

Save TCP sockets for if you ever need to expand to cross-host communication—right now, message queues are the optimal choice.

内容的提问来源于stack exchange，提问作者GUI-Novice