如果 TCP 必须尝试重新传输消息，我无法理解哪些套接字类型会受到负面影响。
我们有一个分布式系统，它对内部进程和外部设备和应用程序使用进程内和 TCP 连接的组合。我担心的是，如果有大量流量导致延迟和丢包，TCP 重新传输将导致系统延迟。
我想避免的是一个应用程序在等待发送的队列中编译消息（通过单个 ZeroMQ TCP 套接字），因为 TCP 强制套接字重复重新传输从未发送过确认的消息。
这是使用 ZeroMQ 会发生的问题吗？目前我在 Linux 操作系统上使用 PUSH/PULL。
或者这不是一个问题，如果不是，为什么？
来自外部设备/应用程序的消息不会提供陈旧数据，这一点至关重要。
首先，唯一可能重传的传输是实际物理网络上的 TCP。然后可能不在 LAN 上，因为以太网数据包不太可能在 LAN 上丢失。
计算机内部的 TCP，尤其是 IPC、INPROC 等，都将保证每次都第一次传送数据。没有重传机制。
如果套接字使用的其中一种传输确实由于传输错误而遇到延迟，那将会减慢速度。在通过套接字使用的所有传输传播之前，ZMQ 不能认为消息“已发送”。“已发送”的外部可见性是出站消息队列已远离高水位线 1。
任何一条消息都可能比 TCP 更快地通过 IPC 到达，并且消息 2 可能在消息 1 通过 TCP 到达之前通过 IPC 到达。但是，如果您依赖消息时间/相对顺序，则首先不应该使用 ZMQ；它是演员模型，而不是 CSP。
为弗兰克编辑
Actor和CSP的区别在于前者是异步的，后者是同步的。因此对于 Actor 模型，发送者对于接收者何时真正收到消息的信息为零。对于 CSP，发送/接收是一个执行集合 - 仅当接收完成时发送才完成。
这可能非常有用。如果在您的系统中，A 指示 C 在指示 B 之前（及时，不仅仅是在 A 的代码流中）做某事是没有意义的，那么您可以使用 CSP（但不是 Actor 模型）来做到这一点。这是因为当 A 向 B 发送消息时，B 在 A 的发送完成之前收到了消息，从而释放了 A 然后发送给 C。
毫不奇怪，受益于 CSP 的是实时系统。
所以考虑 ZMQ 的 Actor 模型，它在 ZMQ 中混合了 TCP、IPC 和 INPROC 传输。通过 TCP 发送的消息很有可能会比通过 INPROC 发送的消息晚很多，即使它们是先发送的。