我需要允许多个客户端（winforms应用程序）通过互联网（在远程位置）连接到服务器，并启动双工通信，有时会发送繁重的流量。
目前，我们正在通过 netTcpBinding 与 WCF 使用双工通信，并使用我们自己的证书在传输层上进行保护。虽然这有效，但我担心一些事情：
- 设置起来很痛苦 - 我们为每个客户端创建一个证书以与服务器标识它，并且需要在客户端计算机和服务器上为每个客户端注册证书
- 因为我们在某个端口上使用 tcp，所以我们依赖于该部分在客户端打开，以便它可以通过 tcp 启动通信。一些客户位置不喜欢这样。
- 我们需要能够理想地保证交付
作为替代方案，我想使用wsDualHttpBinding，使用单个SSL证书来保护它，并让每个客户端发送某种标识符来标识自己。这会解决防火墙问题吗，并且通过 http 而不是 tcp 的性能是否足够高？据我所知，如果您使用 http，WCF 将创建 2 个通道而不是一个通道（因为 http 不支持双向通信） - 所以这听起来可能会导致一些性能问题。
我的问题是，这个解决方案更好，还是有其他解决方案（如NServiceBus）可以使这更容易并解决这些问题？
编辑
从那以后，我了解到wsDualHttpBinding对我来说不是一个选择，因为：This binding requires that the client has a public URI that provides a callback endpoint for the service。这对我来说是不可能的。
让我分别解决每个问题：
-
为什么不使用 TransportWithMessageCredential 并使用用户名和密码 - 这意味着您只需要管理用户名和客户端密码和客户端证书问题消失
-
使用 NetTcpBinding 时，服务器需要打开入站端口流量 - 客户端只需要允许客户端连接到该流量端口，他们不需要在您的特定端口。他们是否在允许出站方面有问题连接到您的自定义端口？
-
NetTcpBinding 使用 Tcp，它有交付保证，假设你拓扑中没有 SOAP 中介。你是在尝试保证交付或处理？
WSDualHttpBinding 将强制客户端为入站连接打开端口，因此几乎肯定是不可接受的。不久前我写了一篇关于双工的博客文章，这可能有助于澄清问题
你可能还需要查看 SignalR，它是为这种方案设计的，虽然是为 Web 应用设计的，但也有一个 .NET 客户端