实际上sockjs的目标也就是sockjs具有的特点。
在SockJS: WebSocket emulation done right一文中对sockjs的特点进行了具体阐述。
sockjs几个特点，非常值得一提
跨域通信sockjs服务器端支持跨域通信，意味着我们可以将sockjs server独立出来，把它放在与web主站点不同的域名之上，实际上这是比较合理的部署策略。关于跨域，也是一个比较大的话题，其中有一个机制叫cors(跨域资源共享)主要解决JavaScript不能跨域请求的问题。sockjs服务器应该支持这种机制。
负载均衡无论server端优化得再好，一个sockjs server的处理能力都是有限的，我们更需要的是一种可扩展的解决方案。一种非常简单的方法是把每一个sockjs server放到一个不同的域名之下，如sockjs1.example.com和sockjs2.example.com，允许客户端随机选择一个server。
Prefix-based sticky sessions在sockjs中，一个典型的url如下：
http://localhost:8000/chat/<serverid>/<sessionid>/url中的第二个参数sessionid，必须是一个随机字符串，唯一标识一个session。第一个参数serverid,主要应用于负载均衡目的。负载均衡器可以利用这个serverid参数作为一个线索，进行负载均衡分流。具体使用方面，参考HAProxy的一个配置参考文件，其中关键的配置在于
balance uri depth 2 JSESSIONID cookie sticky sessions另外一种负载均衡配置方案,主要利用含有jsessionid的cookie。这个cookie由socketjs server进行设置，当response到达负载均衡器的时候，jessionid会被加上一个额外的前缀或者后缀，具体原理方面可以参考阅读
LOAD BALANCING, AFFINITY, PERSISTENCE, STICKY SESSIONS: WHAT YOU NEED TO KNOW一文。
我们知道html5 的websocket协议定义了websocket api使得网页可以利用websocket协议和远端主机进行全双工通信。websocket协议应该是最快，最好的web通信协议，已被大多数的浏览器所支持。那么为什么还需要sockjs进行封装？
在真实的网络世界中，实际上有着非常复杂的网络拓扑结构，在浏览器和server之间，含有很多的中间节点，包括路由器，代理服务器，反向代理服务器，负载均衡器等等。即使html5 websocket协议已经成为了标准，但是这些中间节点并不一定会遵守这些标准，还有很大可能会阻止websocket handshake的过程，结果无法建立websocket连接。
How HTML5 Web Sockets Interact With Proxy Servers一文中提到了websocket协议和代理服务器的“不友善关系”，源于代理服务器对websocket handshake的阻挠和对长连接,空闲连接的关闭处理，让我们看到了如果只是直接利用websocket协议，实在是困难重重。
sockjs的出现，实际是为了解决这个问题，使得人们可以建立健壮的web实时通信程序。
sockjs服务器传输协议不仅提供了websocket协议的支持，还提供了流传输Streaming和轮询Polling ，其中又包括多种底层传输方案，如：
xhr，xhr_streaming，jsonp，eventsource，htmlfile。每一种传输方案，其实都值得开辟一个章节来大写特写。
如果浏览器客户端js，采用websocket连接不上服务器，它可以回退选择其他传输方案，那么确保总可以利用一种传输协议，连接到服务器。那么开发者就不需要理睬那些可恶的中间节点了。
推荐阅读 https://github.com/sockjs/sockjs-protocol, sockjs协议没有什么好文档，可以从测试源码中了解服务器应该如何实现协议http://chimera.labs.oreilly.com/books/1230000000545/pt04.html，可以了解xhr,eventsource,websocket等。https://github.com/mrjoes/sockjs-tornado, 基于tornado框架的sockjs server实现，代码也非常简单。https://github.com/sockjs/sockjs-node， 官方server实现