tl; diana;

比较它们就像比较餐馆的食物(有时可能很贵，可能不是100%你想要)和自制的食物，在那里你必须自己收集和种植每一种食材。

也许如果你只想吃苹果，后者更好。但如果你想要一些复杂的东西，而你又孤身一人，那真的不值得你自己烹饪和制作所有的食材。

这两种我都用过。以下是我的经验。

套接字IO

Has autoconnect Has namespaces Has rooms Has subscriptions service Has a pre-designed protocol of communication (talking about the protocol to subscribe, unsubscribe or send a message to a specific room, you must all design them yourself in websockets) Has good logging support Has integration with services such as redis Has fallback in case WS is not supported (well, it's more and more rare circumstance though) It's a library. Which means, it's actually helping your cause in every way. Websockets is a protocol, not a library, which SocketIO uses anyway. The whole architecture is supported and designed by someone who is not you, thus you dont have to spend time designing and implementing anything from the above, but you can go straight to coding business rules. Has a community because it's a library (you can't have a community for HTTP or Websockets :P They're just standards/protocols)

尚

You have the absolute control, depending on who you are, this can be very good or very bad It's as light as it gets (remember, its a protocol, not a library) You design your own architecture & protocol Has no autoconnect, you implement it yourself if yo want it Has no subscription service, you design it Has no logging, you implement it Has no fallback support Has no rooms, or namespaces. If you want such concepts, you implement them yourself Has no support for anything, you will be the one who implements everything You first have to focus on the technical parts and designing everything that comes and goes from and to your Websockets You have to debug your designs first, and this is going to take you a long time

显然，你可以看到我偏向于SocketIO。我很想这么说，但我真的真的不想。

我真的在努力不使用SocketIO。我不想用它。我喜欢自己设计东西，自己解决问题。

But if you want to have a business and not just a 1000 lines project, and you're going to choose Websockets, you're going to have to implement every single thing yourself. You have to debug everything. You have to make your own subscription service. Your own protocol. Your own everything. And you have to make sure everything is quite sophisticated. And you'll make A LOT of mistakes along the way. You'll spend tons of time designing and debugging everything. I did and still do. I'm using websockets and the reason I'm here is because they're unbearable for a one guy trying to deal with solving business rules for his startup and instead dealing with Websocket designing jargon.

如果你是一个人的团队或者一个小团队想要实现复杂的功能，那么为一个大的应用程序选择Websockets并不是一个简单的选择。我用Websockets写的代码比以前用SocketIO写的要多，而且比用SocketIO简单十倍。

我要说的是…如果您想要一个成品和设计，请选择SocketIO。(除非你想要一些功能非常简单的东西)

即使现在的浏览器支持WebSockets，我认为没有必要抛弃SocketIO，它仍然在当今的任何项目中占有一席之地。它很容易理解，就我个人而言，多亏了SocketIO，我学会了WebSockets是如何工作的。

正如在本主题中提到的，有很多Angular、React等的集成库，以及TypeScript和其他编程语言的定义类型。

我要补充的另一点是Socket之间的区别。io和WebSockets是与Socket的集群。IO不是什么大问题。套接字。io提供了适配器，可用于将其与Redis链接，以增强可伸缩性。你有眼窝和眼窝。比如Io-redis。

是的，我知道，SocketCluster是存在的，但这是跑题了。

TLDR:

的套接字。Io '是一个应用层规范，可以在/使用应用层规范'websockets'之上实现。

websocket规范 套接字。io规范

我认为简单的答案是在基本的web技术定义中:

Specification: A documented standard detailing the requirements for a program to achieve in order to be labeled as "an implimentation of some sepc." It is important to achieve this rubber stamp when building programs, because any program is only as good at the machine executing the code. Programming is fundamentally built upon specifications, and if, they are not followed code will not execute correctly. However, a specification does nothing. It is just a text document. Implementation: This is actual, executable code that accomplishes what the specification says to do. Application Layer - System that defines messages and handshakes sent over transport. This is the stuff you have to know when working with HTTP/Websockets/Socketio. It defines how the connections will be made, authenticated, data will be sent, and how it will arrive.

我想在2021年再提供一个答案。套接字。在2019年9月至2020年8月(将近2年)期间，基本上没有任何活动，我本以为该项目可能已经死亡。

套接字。io也发表了一篇文章，叫做为什么使用Socket。2020年的IO ?除了退回到HTTP长轮询之外，我认为这2个特性都是socket的。IO提供，websocket缺乏

端的自动重连接 将数据广播到给定客户端集(房间/名称空间)的方法

我发现socket的另一个特性。io方便是为ws服务器开发，特别是我使用docker部署我的服务器。因为我总是启动一个以上的服务器实例，跨ws服务器通信是必须的和套接字。IO为它提供https://socket.io/docs/v4/redis-adapter/。

使用redis-adapter，将服务器进程扩展到多个节点很容易，而ws服务器的负载平衡则很困难。点击这里https://socket.io/docs/v4/using-multiple-nodes/了解更多信息。

使用套接字。IO基本上就像使用jQuery -你想要支持旧的浏览器，你需要写更少的代码，库将提供回退。套接字。IO使用websockets技术，如果可用，则检查可用的最佳通信类型并使用它。

它的优点是简化了您在#2中所描述的WebSockets的使用，更重要的是，当浏览器或服务器不支持WebSockets时，它提供了对其他协议的故障转移。我会避免直接使用WebSockets，除非你非常熟悉它们不能工作的环境，并且你有能力绕过这些限制。

这是一个关于WebSockets和Socket.IO的很好的阅读。

http://davidwalsh.name/websocket