Question

首先，我打算没有敌意也不打算，只想知道别人的想法。我正在研究客户端和服务器之间的双向通信;客户端是一个Web应用程序。在这一点上，我有几个选择：MS专有的双工绑定，从我听到的不可靠和不自然：彗星和网络套接字（对于支持的浏览器）。

我知道这个问题已经在其他方面被问到了，但我对这个方法有一个更具体的问题。考虑到Web套接字是客户端的，客户端代码位于JavaScript中。是否真的打算直接在JavaScript中构建一大块应用程序？为什么W3C在Web服务中没有这样做？如果我们能够使用SOAP提供合同并定义事件以及涉及的现有消息传递，那会不会更容易？到目前为止，感觉就像棒子的短端。

为什么不简单地利用JS动态特性并将大量代码留在服务器上呢？

而不是

mysocket.send("AFunction|withparameters|segmented");

我们可以说

myServerObject.AFunction("that", "makessense");

而不是

...
mysocket.onmessage = function() { alert("yay! an ambiguous message"); }
...

我们可以说

...
myServerObject.MeaningfulEvent = function(realData) { alert("Since I have realistic data....");  alert("Hello " + realData.FullName); }
...

HTML 5永远占据了......我们是否在错误的方向上浪费了大量的精力？想法？

Answer 1

听起来我还没有完全掌握Websockets的概念。例如，你说：

考虑Web套接字是客户端

情况并非如此，套接字有两面，您可以将它们视为服务器和客户端，但是一旦建立连接，区别就会模糊 - 您可以将客户端和服务器视为“同行” “ - 每个人都可以随时写入或读入连接它们的管道（套接字连接）。我怀疑你会从在TCP上学习更多关于HTTP的工作中受益 - WebSockets就像这样与HTTP类似/类似。

关于SOAP / WSDL，从围绕TCP / WebSocket / HTTP的对话的角度来看，您可以将所有SOAP / WSDL对话视为与HTTP相同（即正常的网页流量）。

最后，请记住网络编程的堆叠特性，例如SOAP / WSDL如下所示：

SOAP/WSDL
--------- (sits atop)
HTTP
--------- (sits atop)
TCP

WebSockets看起来像这样

WebSocket
--------- (sits atop)
TCP

HTH。

Answer 2

JavaScript允许客户端通过HTTP与XMLHttpRequest进行通信。 WebSockets扩展了此功能，允许JavaScript生成任意网络I / O（不仅仅是HTTP），这是一个逻辑扩展，允许需要使用TCP流量（但可能不使用HTTP协议）的各种应用程序被移植到JavaScript。我认为，随着应用程序继续迁移到云，HTML和JavaScript支持桌面上可用的所有内容，这是合乎逻辑的。

虽然服务器可以代表JavaScript客户端执行非HTTP网络I / O并通过HTTP提供该通信，但这并不总是最合适或最有效的事情。例如，在尝试建立在线SSH终端时添加额外的往返成本是没有意义的。 WebSockets使JavaScript可以直接与SSH服务器通信。

至于语法，部分内容基于XMLHttpRequest。正如在其他帖子中指出的那样，WebSockets是一个相当低级的API，可以包含在一个更容易理解的API中。更重要的是，WebSockets支持所有必需的应用程序，而不是它具有最优雅的语法（有时专注于语法会导致更多限制性功能）。库作者总是可以使这个非常通用的API对其他应用程序开发人员更易于管理。

Answer 3

正如您所指出的，WebSockets具有低开销。开销类似于普通的TCP套接字：每帧只有两个字节，而AJAX / Comet只有几百个字节。

为什么是低级而不是某种内置的RPC功能？一些想法：

在低级套接字协议上采用现有的RPC协议并将其分层并不难。如果假定RPC开销，则不能反向并建立低级连接。
WebSockets支持相当简单，可以在服务器端添加到多种语言。有效载荷只是一个UTF-8字符串，几乎每种语言都有内置的有效支持。 RPC机制不是那么多。如何处理Javascript和目标语言之间的数据类型转换？你需要在Javascript端添加类型提示吗？可变长度参数和/或参数列表怎么样？如果语言没有很好的答案，你会建立这些机制吗？等
以后会建模哪种RPC机制？您会选择现有的（SOAP，XML-RPC，JSON-RPC，Java RMI，AMF，RPyC，CORBA）还是全新的？
一旦客户端支持相当普遍，那么许多具有正常TCP套接字的服务将添加WebSockets支持（因为添加它是相当简单的）。如果WebSockets是基于RPC的，则情况并非如此。某些现有服务可能会添加RPC层，但大部分WebSockets服务都是从头开始创建的。

对于我的noVNC项目（仅使用Javascript，Canvas，WebSockets的VNC客户端），WebSockets的低开销特性对于实现合理的性能至关重要。在VNC服务器包含WebSockets支持之前，noVNC包括wsproxy，它是TCP套接字代理的通用WebSockets。

如果您正在考虑实现交互式Web应用程序并且尚未确定服务器端语言，那么我建议查看Socket.IO这是node的库（服务器端Javascript）使用谷歌的V8引擎）。

除了节点的所有优点（双方语言相同，效率非常高，电源库等）之外，Socket.IO还为您提供了以下几点：

提供用于处理连接的客户端和服务器框架库。
检测客户端和服务器支持的最佳传输。传输包括（从最好到最差）：本机WebSockets，使用Flash仿真的WebSockets，各种AJAX模型。
无论使用何种传输方式，都保持一致的界面。
自动编码/解码Javascript数据类型。

在Socket.IO之上创建RPC机制并不困难，因为双方都是相同的本地类型的语言。

Answer 4

WebSocket通过允许来自服务器的请求使Comet和所有其他HTTP推送类型技术清晰可读。它是一种沙盒插座，为我们提供了有限的功能。

但是，API足以让框架和库作者以他们想要的方式改进界面。例如，您可以在WebSockets之上编写一些RPC或RMI样式的服务，允许通过线路发送对象。现在内部它们以某种未知格式被序列化，但服务用户不需要知道也不关心。

从规范作者POV开始思考，从

开始

mysocket.send("AFunction|withparameters|segmented");

到

myServerObject.AFunction("that", "makessense");

相对容易，需要在WebSockets周围编写一个小包装器，以便序列化和反序列化不透明地发生在应用程序中。但反过来意味着规范作者需要制作一个更复杂的API，这使得在其上编写代码的基础变弱。

Answer 5

我遇到了同样的问题，我需要做call('AFunction', 'foo', 'bar')之类的事情而不是序列化/反序列化每次互动。我的偏好也是将大量代码留在服务器上，只使用Javascript来处理视图。 WebSockets因其对双向通信的自然支持而更适合。为了简化我的应用程序开发，我在WebSockets之上构建了一个层来进行远程方法调用（如RPC）。

我已在http://sourceforge.net/projects/rmiwebsocket/发布了RMI/RPC图书馆。在Web页面和servlet之间建立通信后，您可以在任一方向上执行调用。服务器使用反射来调用服务器端对象中的适当方法，客户端使用Javascript的“调用”方法来调用客户端对象中的相应函数。该库使用Jackson来处理各种Java类型与JSON的串行化/反序列化。

Answer 6

WebSocket JSR由许多方（Oracle，Apache，Eclipse等）协商，所有方都有着截然不同的议程。它也是在消息传输级别停止并且离开更高级别的构造。如果您需要的是Java to JavaScript RMI，请查看FERMI Framework。

为什么Web套接字不使用SOAP？

6 个答案: