如果WebSocket用于我们的HTML5应用程序。它应该用于服务器到服务器通信吗？

Question

我需要为现有系统设计一个解决方案，该系统需要在多个应用程序和服务之间使用安全的双向通信。目前的环境如下：

1. HTML5 Kiosk应用程序需要双向通信才能从服务器发送数据和接收数据。由于要求，长轮询和短轮询或REST不是一种选择。这些信息亭将有数十个供用户与之互动。
2. 有数千个位置拥有本地服务器并与第三方硬件和软件解决方案进行交互。每个位置都有一个本地服务器，该服务器具有必须与第三方硬件和软件交互的现有TCP / IP服务器应用程序。客户端要求Kiosk由于带宽和第三方系统而连接到本地服务。

我的任务是设计一个应用程序和网络协议：

• 允许HTML5信息亭与简单数据和更复杂的数据（如流视频和音频）之间进行安全的双向通信。
• 允许现有本地TCP / IP服务器应用程序之间的安全双向通信
• 允许通过互联网与我们的中央门户系统进行安全的双向通信。

Here is a link to the design.

这是Microsoft环境，客户端更喜欢将C＃和.NET用于服务器应用程序。中央系统可以有一个Web服务器（IIS和ASP.NET MVC），但本地服务器无法满足硬件和安全性。所有本地通信都在封闭的网络中。

我的问题是：

1. HTML5和Websockets以外的本地服务器之间的双向通信是否有更好的解决方案？

2. 哪种网络协议最适合中央网络服务？这在图中以红色圈出。这些是我们正在考虑的协议：

   • WebSocket：一些开发人员认为，如果Websockets用于HTML5客户端，那么它可以用于本地和中央服务之间的双向通信。这纯粹来自开发工作和维护考虑，但我不相信在本地和中央C＃应用程序之间使用它。 HTTPS和使用Web端口以避免打开套接字的能力是另一个优势。

   • TCP / IP：与上述相同的参数。工程师已经拥有一些TCP / IP经验，可以重用其他应用程序的代码来加速开发。

   • WCF Duplex：这对我来说很有意义，但增加了一层难以向工程师和管理层出售的复杂性。配置WCF，故障排除也是一个障碍，因为部署必须在每个位置都很快。这曾经是几年前的问题，但我相信WCF配置变得更容易。网络服务应用程序将比网络更多，因此WCF将位于现有组件之上。

   • 任何其他有意义的协议或技术。

Answer 1

WebSockets对于客户端 - 服务器通信看起来没问题。

如果客户端的Web浏览器本身不支持Web套接字，请注意可以选择（通过您的框架）作为后备的长轮询。 所以我想说你的系统在任何情况下都应该为某种程度的负载做好准备。

对于服务器 - 服务器通信，有使用REST或消息传递的趋势（RabbitMq，Kafka等）