Web套接字使ajax/CORS过时了吗？

Question

在所有Web浏览器中使用Web套接字会使ajax过时吗？

因为如果我可以使用Web套接字来实时获取数据和更新数据,为什么我需要ajax？即使我在应用程序启动时使用ajax只获取一次数据,我仍然可能想看看这段数据是否在一段时间后发生了变化.

Web套接字是否可以跨域或仅来自同一个来源？

Answer 1

WebSockets不会使AJAX完全过时,WebSockets也可以跨域.

AJAX

AJAX机制可以与普通Web服务器一起使用.在最基本的层面上,AJAX只是网页发出HTTP请求的一种方式.WebSockets是一种更低级别的协议,需要WebSockets服务器(内置于Web服务器,独立或从Web服务器代理到独立服务器).

使用WebSockets,框架和有效负载由应用程序确定.您可以在客户端和服务器之间来回发送HTML/XML/JSON,但您不必被迫.AJAX是HTTP.WebSockets具有HTTP友好握手,但WebSockets不是HTTP.WebSockets是一种双向协议,它比原始套接字(故意这样)更接近于HTTP.WebSockets有效负载数据在标准的当前版本中以UTF-8编码,但在将来的版本中可能会更改/扩展.

因此,即使在所有客户端本身都支持WebSockets的世界中,也可能始终存在AJAX类型请求的位置.WebSockets正试图解决AJAX不具备能力或能力不足的情况(因为WebSockets的双向性和低得多的开销).但WebSockets并不能取代AJAX所用的一切.

跨域

是的,WebSockets支持跨域.设置连接的初始握手通信源策略信息.维基百科页面显示了典型握手的示例:http://en.wikipedia.org/wiki/WebSockets

Answer 2

我会尝试将其分解为问题:

在所有Web浏览器中使用Web套接字会使ajax过时吗？

绝对不.WebSockets是到服务器的原始套接字连接.这附带了它自身的安全问题.AJAX调用只是异步.HTTP请求可以遵循与其余页面相同的验证过程.

因为如果我可以使用Web套接字来实时获取数据和更新数据,为什么我需要ajax？

您可以使用AJAX来实现更简单,更易于管理的任务.并非所有人都希望获得保护套接字连接的开销以简单地允许异步请求.这可以简单地处理.

即使我在应用程序启动时使用ajax只获取一次数据,我仍然可能想看看这段数据是否在一段时间后发生了变化.

当然,如果数据正在发生变化.您可能没有更改数据或不断更新数据.同样,这是您必须考虑的代码开销.

Web套接字是否可以跨域或仅来自同一个来源？

您可以拥有跨域WebSockets,但必须对WS服务器进行编码才能接受它们.您可以访问域(主机)标头,然后可以使用该标头接受/拒绝请求.然而,这可以通过简单的事情来欺骗nc.为了真正保护连接,您需要通过其他方式验证连接.

Answer 3

在ajax避免的可扩展性方面,Websockets有一些很大的缺点.由于ajax发送请求/响应并关闭连接(如果有人停留在网页上),如果有人停留在网页上,则在空闲时不会使用服务器资源.Websockets用于将数据流回浏览器,并且它们会占用服务器资源.服务器在一次可以保持打开的同时连接数量方面存在限制.更不用说取决于您的服务器端技术,他们可能会绑定一个线程来处理套接字.因此,websockets对每个连接的双方都有更多的资源密集型要求.您可以轻松耗尽为客户端服务的所有线程,如果很多用户只是坐在页面上,则不会有新客户端进入.这就是nodejs,vertx,netty可以真正帮助的地方,但即便是那些也有上限.

还有底层套接字状态的问题,并且在两侧编写代码进行有状态对话,这不是你必须用ajax风格做的事情,因为它是无状态的.Websockets需要您创建一个低级协议,使用ajax为您解决.心脏跳动,关闭空闲连接,重新连接错误等等现在至关重要.这些是使用AJAX时无需解决的问题,因为它是无状态的.状态对于应用程序的稳定性非常重要,更重要的是服务器的运行状况.这不是微不足道的.在HTTP之前,我们构建了许多有状态的TCP协议(FTP,telnet,SSH),然后发生了HTTP.并且没有人再那样做了,因为即使有其局限性,HTTP也更加容易和强大.Websockets带回了有状态协议的好坏.如果你没有得到最后一次的剂量,你很快就会学到很多东西.

如果您需要实时数据流,这需要额外的开销,因为轮询服务器以获取流数据更糟糕,但如果您所做的只是用户交互 - >请求 - >响应 - >更新UI,那么ajax更容易并将使用资源较少,因为一旦发送了响应,会话就结束了,不再使用其他服务器资源.所以我认为这是一个权衡,架构师必须决定哪个工具适合他们的问题.AJAX有它的位置,websockets占有一席之地.

更新

因此,当我们讨论线程时,服务器的体系结构才是最重要的.如果您使用传统的多线程服务器(或进程),其中每个套接字连接都有自己的线程来响应请求,那么websockets对您很重要.因此,对于每个连接,我们都有一个套接字,如果你有太多的这些,最终操作系统将会崩溃,而线程也是如此(对于进程来说更是如此).线程比套接字重(在资源方面),所以我们尝试保存我们同时运行的线程数.这意味着创建一个线程池,它只是在所有套接字之间共享的固定数量的线程.但是一旦打开套接字,该线程就会用于整个会话.这些对话的长度决定了你为这些新套接字重新调整这些线程的速度.你的会话长度决定了你可以扩展的程度.但是,如果您正在流式传输此模型,则无法正常进行缩放.你必须打破线程/套接字设计.

HTTP的请求/响应模型使其在为新套接字转换线程时非常有效.如果您打算使用请求/响应,请使用已构建的HTTP,并且比在websockets中重新实现类似的内容要容易得多.

由于websockets不必作为HTTP请求/响应,并且如果您的服务器在其线程池中具有固定数量的线程并且您具有相同数量的websockets以将所有线程与活动对话捆绑在一起,则可以流式传输数据,您可以为新客户提供服务!你达到了最大容量.这也是协议设计对于websockets和线程也很重要的地方.您的协议可能允许您放松每个会话模型的每个插槽的线程,这样人们只是坐在那里不使用服务器上的线程.

这就是异步单线程服务器的用武之地.在Java中,我们经常将此NIO称为非阻塞IO.这意味着它是套接字的不同API,其中发送和接收数据不会阻塞执行调用的线程.

如此传统的阻塞套接字在调用socket.read()或socket.write()时,它们会一直等到接收或发送数据,然后再将控制权返回给程序.这意味着您的程序将等待套接字数据进入或退出,直到您可以执行任何其他操作为止.这就是为什么我们有线程,所以我们可以同时工作(同时).当我等待来自客户端Y的数据时,将此数据发送到客户端X.当谈论服务器时,Concurrencies是游戏的名称.

在NIO服务器中,我们使用单个线程来处理所有客户端并注册回调以在数据到达时得到通知.例如

socket.read( function( data ) {
   // data is here! Now you can process it very quickly without waiting!
});

socket.read()调用将在不读取任何数据的情况下立即返回,但我们提供的函数将在调用时被调用.这种设计从根本上改变了构建和构建代码的方式,因为如果你挂断了等待的东西,你可以不接待任何新客户.你有一个单独的线程,你不能一次做两件事!你必须保持一个线程移动.

NIO,异步IO,基于事件的程序,因为这是众所周知的,是一个更复杂的系统设计,如果你刚开始,我不建议你尝试写这个.即使是非常高级的程序员也很难建立一个强大的系统.由于您是异步的,因此无法调用阻止的API.就像从数据库中读取数据或向其他服务器发送消息一样,必须异步执行.即使从文件系统读取/写入也会降低单线程速度,从而降低可伸缩性.一旦你去异步,如果你想保持单个线程的移动,它就会一直异步.这就是它变得具有挑战性的地方,因为最终你会遇到像DB一样的API,它不是异步的,你必须在某种程度上采用更多的线程.因此,即使在异步世界中,混合方法也很常见.

好消息是有其他解决方案使用已经构建的可用的低级API.NodeJS,Vertx,Netty,Apache Mina,Play Framework,Twisted Python,Stackless Python等.可能有一些模糊的C++库,但老实说,我不会打扰.服务器技术不需要最快的语言,因为它的IO限制超过CPU限制.如果你是一个死硬的性能坚果使用Java.它拥有庞大的代码社区,它的速度与C++相比非常接近(有时甚至更好).如果你讨厌它,请使用Node或Python.