websocket有没有可能取代ajax

对于服务器与客户端的双向通信，WebSocket 简直是不二之选。如果不是还有少数旧版浏览器尚在服役的话，所有的轮询、长连接等方式早就该废弃掉。那些整合多种双向推送消息方式的库（如http://Socket.IO、SignalR）当初最大的卖点就是兼容所有浏览器版本，自动识别旧版浏览器并采取不同的连接方式，现在也渐渐失去了优势——所有新版浏览器都兼容 WebSocket，直接用原生的就行了。

但是，很大一部分 AJAX 的使用场景仍然是传统的请求-响应形式，比如获取 json 数据、post 表单之类。这些功能虽然靠 WebSocket 也能实现，但就像在原本传输数据流的 TCP 之上定义了基于请求的HTTP协议一样，我们也要在 WebSocket 之上重新定义一种新的协议，最少也要加个 request id 用来区分每次响应数据对应的请求吧。

……但是，何苦一层叠一层地造个新轮子呢？直接使用 AJAX 不是更简单、更成熟吗？

另外还有一种情况，也就是传输大文件、图片、媒体流的时候，最好还是老老实实用 HTTP 来传。如果一定要用 WebSocket 的话，至少也专门为这些数据专门开辟个新通道，而别去占用那条用于推送消息、对实时性要求很强的连接。否则会把串行的 WebSocket 彻底堵死的。

所以说，WebSocket 在用于双向传输、推送消息方面能够做到灵活、简便、高效，但在普通的 Request-Response 过程中并没有太大用武之地，比起普通的 HTTP 请求来反倒麻烦了许多，甚至更为低效。

每项技术都有自身的优缺点，在适合它的地方能发挥出最大长处，而看到它的几个优点就不分场合地全方位推广的话，可能会适得其反。

用 Websocket 取代 ajax 来开发 web 应用，是不太可能的。

需要考虑以下更多的问题：

1、多种客户端访问技术，譬如移动端，自己开发的 sdk；用 http 协议，会很通用而简单；websocket在技术上，不够通用；

2、并发，http 是短连接，而 websocket 会保持长连接，当交互并不频繁的时候，连接是被大量浪费的，因此服务器的连接容量会大大多于 http；

3、负载，http 协议，可以很容易的进行 web 请求转发来扩容，在搭建 lbs 接入层的时候，很简单和稳定；而 websocket 协议，虽然 nginx 也可以转发，但是毕竟是新技术，稳定性未知；

4、简单：在问题诊断的时候，可以直接面向 http 协议进行切片从而监视原始数据，工具也很多；而 websocket，需要更多面向 tcp 协议的工具，复杂度和难度会增加不少；

综上，还是建议只有当需要服务器 push 的模块，才采用 websocket，而其他的交互采用 http。