Sockets 是一种处理网络的范例，这一概念已经存在了几十年。Sockets曾经是网络输入和输出标准化的一种方式，就像应用程序接口（API）一样，这样，无论硬件的具体情况如何，应用程序都可以对Sockets 编程，而且可以在许多不同的硬件实现上运行。
socket 背后的理念是，它是一个数据进出的端口。socket 就像一个真正的数据交易端口，就像码头，从应用程序的角度来看，它是进行交换的地方。socket 本身是抽象的、低级的，按照这个比喻，许多不同的船只、火车和设备都可以使用它。我们可以将所有这些称为协议。
互联网上有数以百计的协议，但最常见的协议只有几种，如 HTTP、FTP、SMTP、POP3 等，以及 TCP 和 UDP 等低级传输协议。从本质上讲，协议决定了如何解释往来于 socket 和相互通信的机器之间的数据。
什么是 WebSockets？
WebSockets 实际上是套接字概念的延伸。虽然 HTTP 是为万维网而发明的，并且从那时起就一直被浏览器所使用，但它有其局限性。它是一种以特定方式工作的特殊协议，并不能很好地满足所有需求。尤其是 HTTP 处理连接的方式。每当你提出请求，比如下载 HTML 或图片，一个端口/套接字就会被打开，数据被传输，然后被关闭。
打开和关闭会产生开销，对于某些应用，尤其是那些需要快速响应、实时交互或显示数据流的应用，这种方式根本行不通。
HTTP 的另一个局限性在于它是一种 “拉 “模式。浏览器会向服务器请求或拉取信息，但服务器无法在需要时向浏览器推送数据。这意味着，浏览器必须每隔几秒或几分钟重复请求，以轮询服务器是否有新信息。2000 年代末，浏览器中添加套接字的呼声日渐高涨。2011 年，WebSocket 实现了标准化，人们可以使用 WebSocket 协议进行非常灵活的浏览器与服务器之间的数据传输，以及浏览器之间的点对点（P2P）或直接通信。与 HTTP 不同的是，连接到服务器的套接字会保持开放，以便进行通信。这意味着数据可以按需实时推送到浏览器。
什么是 REST？
REST 或 REpresentational State Transfer 是另一种抽象概念，用于以标准化方式为应用程序创建 API。对于典型的网络应用程序和现在的传统网络应用程序，使用 HTTP 创建 REST 端点是绝大多数应用程序的架构方式。无论是 Ruby、Java、Go、NodesJS 还是其他多种可用技术，它们在接收信息请求（Requests）和响应请求（Response）方面基本相似。
REST 以可预测的方式组织这些请求，使用 HTTP 操作类型或动词来构建适当的响应。请求来自客户端，常见的 HTTP 动词包括 GET、POST、PUT 和 DELETE，但还有其他几种。它们对应于预期的操作，即检索数据、提交数据、更新数据和删除数据。
到目前为止，REST 是构建请求 API 的最标准化方式。但由于它涉及使用 HTTP，因此也会产生与该协议相关的开销。对于大多数应用程序来说，只有在用户进行操作时才需要传输信息。例如，在浏览新闻网站时，一旦浏览器请求了文章，用户就会忙于阅读，而不会进行操作。在这段时间关闭端口套接字实际上是在节省资源。在交互频率较低的情况下，HTTP 运行良好，这也是使用 HTTP 的原因。
对于更多的实时交互、实时传输或数据流，HTTP 和 REST 并不是最合适的协议和抽象组合。这正是套接字和 WebSockets 的优势所在。
WebSockets 与 REST： 性能比较
打开和关闭连接的开销非常大。发送和接收数据的性能以及能够发送和接收数据的并发设备数量是一个重要的考虑因素。使用轮询与推送也是服务器的实际负担。
REST 性能
打个比方，我们可以将其视为一支拥有指挥系统的军队。让服务器成为将军，而所有浏览器则是在地面上等待命令的士兵。使用 HTTP/REST，如果每个士兵都要询问将军是否有新的命令，这将给将军带来巨大的负担，尤其是在没有新命令的情况下。这意味着将军在大部分时间里都在说 “没有，没有新命令”。
如果您的服务器是将军，那么他们的资源就会被浪费掉，大部分时间都在说没有新消息。此外，由于将军一次只能回答这么多士兵的问题，即使对每个士兵说一次没有新消息也需要很长时间，这就存在时间延迟，排在最后的士兵听到没有新消息的时间远远晚于第一个提问的士兵。
WebSockets 性能
使用相同的比喻，连接套接字就好比每个士兵都有一个无线电，当将军有新命令时，他可以将命令发送到无线电中，所有士兵都能同时接收到。当然，我们还可以在无线电上设置不同的频段，将军可以向在不同频段上收听的特定群体发布命令。
这样双方都能提高效率。
将军不再需要承担不必要的工作，因此你需要更少的服务器为客户提供服务。客户端也无需浪费网络和资源来进行轮询和提出请求。双方的效率都要高得多。
使用 WebSockets 而不是 REST？
目前很多服务商已经将 WebSockets 的规模和可靠性提升到了极致，能够为全球数百万台设备提供服务，每天有数十亿条信息通过网络发送。有许多 WebSocket 框架，其中 Socket.IO 可能是最流行、最广为人知的。
这是熟悉 Socket 风格编程和该范例如何工作的好方法。然而，在生产中实际使用它却有更大的问题。
在使用 Socket.IO 时，就像使用其他服务器一样，你必须投入时间和资源进行设置、配置、监控、管理和扩展。所有这些都需要时间、人力和机器，而所有这些都需要成本。当事情出错时，还要从错误和异常中吸取教训，而这些错误和异常总是会发生的。每次吸取教训的价值都在于教训，而代价则是应用程序停机，一切都无法正常工作，还可能失去客户。最后不管是用WebSockets还是REST都需要根据自己的业务来选择。
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/im/37271.html
