Web套接字使ajax / CORS过时？

在所有Web浏览器中使用Web套接字是否会使Ajax过时？

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

networking套接字是可能的跨域或只有相同的起源？

Answer 1

WebSockets不会使AJAX完全过时，WebSockets可以跨域。

AJAX

AJAX机制可以用于普通的Web服务器。 在最基本的层面上，AJAX只是网页发出HTTP请求的一种方式。 WebSockets是一个低得多的协议，需要一个WebSocket服务器（或者内置到Web服务器，独立的，或者从Web服务器代理到一个独立的服务器）。

使用WebSocket，框架和有效载荷由应用程序决定。 您可以在客户端和服务器之间来回发送HTML / XML / JSON，但是您不会被迫。 AJAX是HTTP 。 WebSockets有一个HTTP友好的握手，但WebSockets不是HTTP 。 WebSockets是一种双向协议，与原始套接字（有意）相比，更接近于HTTP。 WebSockets有效载荷数据在标准的当前版本中是UTF-8编码，但在将来的版本中可能会更改/扩展。

所以，即使在所有客户端本身支持WebSocket的环境中，也可能总会有AJAXtypes的请求。 WebSockets正在尝试解决AJAX不具备或者稍微有能力的情况（因为WebSockets的双向开销较低）。 但是WebSockets并不能代替AJAX所用的所有东西。

跨域

是的 ，WebSockets支持跨域。 build立连接的初始握手会传达源策略信息。 维基百科页面显示了一个典型的握手示例： http : //en.wikipedia.org/wiki/WebSockets

Answer 2

我会尽力把这个问题分解成几个问题：

在所有Web浏览器中使用Web套接字是否会使Ajax过时？

绝对不。 WebSockets是到服务器的原始套接字连接。 这带有它自己的安全问题 。 AJAX调用是简单的asynchronous。 HTTP请求可以遵循与其余页面相同的validation过程。

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

你会使用AJAX更简单，更易于pipe理的任务。 不是每个人都想要保证一个套接字连接的开销来简单地允许asynchronous请求。 这可以处理得很简单。

即使我使用ajax只是在应用程序启动时取一次数据，我仍然可能想看看这个数据在一段时间后是否改变了。

当然， 如果这些数据正在改变 。 你可能没有数据改变或不断刷新。 再一次，这是你必须考虑的代码开销 。

networking套接字是可能的跨域或只有相同的起源？

你可以跨域WebSockets，但是你必须编写你的WS服务器来接受它们。 您可以访问域（主机）头，然后您可以使用它来接受/拒绝请求。 但是，这可以通过像nc这样简单的东西来欺骗。 为了真正确保连接，您需要通过其他方式validation连接。

Answer 3

Websockets在ajax避免的可伸缩性方面有几大缺点。 由于ajax发送一个请求/响应，并closures连接（..或稍后），如果有人停留在网页上，它闲置时不使用服务器资源。 Websockets旨在将数据stream式传输回浏览器，并且它们将服务器资源捆绑在一起。 服务器一次可以同时打开多less个同时连接的限制。 更不要说取决于你的服务器端技术，他们可能会绑定一个线程来处理套接字。 因此，每个连接的websockets对双方都有更多的资源密集型需求。 您可以轻松地用尽所有服务客户的线程，然后如果有很多用户只是坐在页面上，就不会有新客户进来。 这是nodejs，vertx，netty真的可以帮忙的地方，但是即使这些也有上限。

另外还有底层套接字状态的问题，并在双方写代码进行有状态的谈话，这是不是你与阿贾克斯风格，因为它是无状态的。 Websockets需要你创build一个低级的协议，这是为你解决与Ajax。 像心脏跳动，closures空闲连接，错误重新连接等等现在非常重要。 这些是使用AJAX时无需解决的问题，因为它是无状态的。 状态对于您的应用程序的稳定性以及更重要的是您的服务器的健康状况非常重要。 这不是微不足道的。 在HTTP之前，我们build立了很多有状态的TCP协议（FTP，telnet，SSH），然后发生了HTTP。 没有人做了这么多，因为即使有它的限制，HTTP令人惊讶地更容易和更强大。 Websockets带回有状态协议的好坏。 如果你没有得到最后一剂药的治疗，你会很快学到的。

如果您需要stream式传输实时数据，则需要额外的开销，因为轮询服务器以获取stream式数据会更糟糕，但如果您所做的只是用户交互 – >请求 – >响应 – >更新UI，那么ajax会更容易，并且会使用更less的资源，因为一旦发送响应，对话结束并且不使用额外的服务器资源。 所以我认为这是一个折衷，架构师必须决定哪个工具适合他们的问题。 AJAX有它的地方，websockets有自己的位置。

更新

所以，当我们谈论线程时，你的服务器的架构是重要的。 如果您使用传统的multithreading服务器（或进程），每个套接字连接都有自己的线程来响应请求，那么websockets对您来说非常重要。 因此，对于每个连接，我们都有一个套接字，如果你有太多这样的操作系统，最终操作系统将会崩溃，对于线程也是如此（对于进程来说更是如此）。 线程比套接字（资源方面）要重，因此我们试着保存同时运行多less个线程。 这意味着创build一个线程池，它只是在所有套接字之间共享的固定数量的线程。 但是，一旦套接字打开，该线程将用于整个对话。 这些对话的长度决定了你能够以多快的速度重新调整新插槽的线程。对话的长度决定了你可以扩展多less。 但是，如果您正在stream式传输此模型不适合缩放。 你必须打破线程/套接字devise。

HTTP的请求/响应模式使得在转换新套接字的线程时非常高效。 如果你只是要使用请求/响应使用HTTP已经build成，并比在websockets中重新实现类似的东西容易得多。

由于websockets不必是HTTP的请求/响应，并且可以在你的服务器在其线程池中有固定数量的线程的情况下stream数据，并且你拥有相同数量的websocket将所有线程与主动对话捆绑在一起，你可以不要为进来的新客户服务！ 你已经达到了你的最大容量。 这就是协议devise对于websockets和线程来说很重要的地方。 您的协议可能允许您放松每个会话模式的每个套接字线程，这样坐在那里的人就不会在服务器上使用线程。

这就是asynchronous单线程服务器的用武之地。在Java中，我们经常把这个NIO称为非阻塞IO。 这意味着这是一个不同的API，用于发送和接收数据不会阻塞执行调用的线程的套接字。

所以在调用socket.read（）或socket.write（）的时候阻塞套接字是很传统的，它们要等到数据被接收或发送之后再把控制权返回给你的程序。 这意味着你的程序停滞不前，等待套接字数据进入或退出，直到你可以做任何事情。 这就是为什么我们有线程，所以我们可以同时工作（在同一时间）。 当我从客户端Y等待数据时，将这些数据发送到客户端X.当我们讨论服务器时，并发货币就是游戏的名称。

在NIO服务器中，我们使用单个线程来处理所有客户端，并注册数据到达时通知callback。 例如

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

socket.read（）调用将立即返回而不读取任何数据，但我们提供的函数将在调用时调用。此devise从根本上改变了您构build代码的方式，因为如果您挂起等待某些东西不会收到任何新的客户。 你有一个单一的线程，你不能一次做两件事情！ 你必须保持这个线程移动。

NIO，asynchronousIO，基于事件的程序，这是所有已知的，是一个非常复杂的系统devise，我不会build议你尝试写这个，如果你刚开始。 即使是非常高级的程序员也很难build立一个强大的系统。 由于你是asynchronous的，你不能调用阻塞的API。 就像从数据库读取数据或向其他服务器发送消息一样，必须asynchronous执行。 即使从文件系统读取/写入，也会减慢单线程的速度，降低可伸缩性。 一旦你走asynchronous，如果你想保持单线程移动，所有的时间都是asynchronous的。 这就是它具有挑战性的地方，因为最终你会遇到一个API，就像数据库一样，它不是asynchronous的，你必须在某个层次采用更多的线程。 所以即使在asynchronous世界中，混合方法也很常见。

好消息是还有其他解决scheme使用已经构build的低级API，您可以使用。 NodeJS，Vertx，Netty，Apache Mina，Play Framework，Twisted Python，Stackless Python等等。C ++可能会有一些模糊的库，但老实说我不会感到困扰。 服务器技术不需要最快的语言，因为它的IO绑定比CPU绑定更多。 如果你是一个顽固的performance坚果使用Java。 它有一个巨大的代码社区，它的速度与C ++非常接近（有时甚至更好）。 如果你只是恨它去与Node或Python。

Answer 4

是的，是的。 ：d

较早的答案缺乏想象力。 如果websockets可用，我没有理由使用AJAX。