我有一个提供者 (A) 想通过传入的 TCP 连接向我们发送数据。不幸的是，消费服务 (B) 无法接收入站 TCP 连接。此外，它没有静态 IP，这是另一个要求。
解决此问题的一种方法是将传入 TCP A 端口连接到另一个 TCP 端口 B 的服务，以便消费者可以与 B 建立出站连接。
这不是一个独特的问题[1] [2]，使用 socat 我可以做出非常接近我想要的东西：
socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr
但是，这样做存在以下问题：
- 如果 B 断开连接，则无法重新连接。使用
TCP4-LISTEN:PORT-B,reuseaddr,fork，它可以连接但不接收数据。 - 在 A 建立连接之前 B 无法连接（可克服）
- 只能建立一个连接
PORT-B（可克服）
有没有办法调整命令，使其成为“永久”并抵抗失败？
重要的问题是，A 将如何应对失去连接或拒绝连接？任何假设单个 TCP 连接将永远保持不变的东西都是脆弱的。这就是互联网的本质。
设置即
socat服务[x]inetd怎么样？您将设置
xinetd在 PORT-B 中侦听，并socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIO在 B 端连接后立即启动。xinetd将从 B 端传入的流量传递到 的标准输入socat，并捕获 的标准输出socat并将其传递给 B 端。如果B断开，则
socat可以允许该过程结束；xinetd一旦 B 再次连接，将启动一个新的。当 B 断开连接时，A 将收到“连接被拒绝”错误。我曾经不得不在旧的 HP-UX 系统上做类似的事情。
现实世界是混乱的。
在现实世界中，有时 TCP 连接会死掉，例如，如果状态防火墙或 NAT 重新启动，如果连接时间过长而没有流量，或者底层连接关闭时间过长，则可能会发生这种情况。
此外，有时当连接死亡时，它们不会对称地死亡。如果一个承载大量数据的连接死掉了，那么发送者很可能会在接收者这样做之前很久就注意到它已经死了。这有几个副作用。
此外，TCP 连接是字节流，而不是消息流，因此当您的连接中断时，您可能会收到部分消息。
最终结果使我得出结论，一个强大的解决方案需要了解应用程序协议，以便您的解决方案能够理解。