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



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

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

我的任务是设计一个应用程序和网络协议,它将:

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

这是设计的链接。

这是一个Microsoft环境,客户端更喜欢将 C# 和 .NET 用于服务器应用程序。中央系统可以有一个Web服务器(IIS和 ASP.NET MVC),但由于硬件和安全性,本地服务器不能。所有本地通信都在封闭的网络中。

我的问题是:

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

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

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

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

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

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

WebSockets看起来可以进行客户端 - 服务器通信。

请注意,如果客户端的 Web 浏览器本身不支持 Web 套接字,则可以选择长轮询(由您的框架)作为回退。 所以我想说你的系统在任何情况下都应该准备好接受一定程度的负载。

对于服务器-服务器通信,有一种使用REST或消息传递(RabbitMq,Kafka等)的趋势。

最新更新