WebSocket 和普通套接字通信有什么区别？
What's the difference between WebSocket and plain socket communication?
根据 Wikipedia，HTTP 和 WebSocket 之间的唯一关系是 Upgrade HTTP request 形式的额外握手。在那之后，浏览器和 HTTP 服务器似乎只会通过普通套接字以旧的 C/S 范例进行通信。
所以我的问题是：
- WebSocket 只是一种普通的套接字通信吗？
- 之所以叫
WebSocket，是因为通信的目标是服务器的80端口？即 port 80 只是 web. 的同义词
- 80端口是服务器端的，客户端用的是什么端口？
- 如果它只是浏览器和服务器之间的普通套接字通信，为什么 WebSocket 直到最近才在浏览器中实现？它似乎只不过是对 B/S 范式的一点 C/S 扩展。
添加 1（2017 年 5 月 23 日上午 9:46）
今天，我重温了@jfriend00 的精彩回答。总结一下我的理解吧。
- Socket只是一个端到端的通信通道。它不限制可以使用什么通信协议。
- webSocket 和 HTTP 一样，只是另一种独立的通信协议。虽然名称中的 socket 一开始让我感到困惑。
- webSocket利用了和HTTP相同的端口号，如果我们能通过HTTP进行通信，就可以确定webSocket通信是可以进行的。因为频道打通了，我们可以选择最合适的方式在频道中对话。
不，WebSocket 不仅仅是普通的套接字。他们使用需要握手的成帧协议，然后用 32 位随机数交换由 XORint 屏蔽的消息。如需更多信息，read the RFC which standardizes them.
这个额外编码层的原因是允许网络浏览器创建任意套接字连接会引发各种安全问题。例如，您可以让您网站的访问者通过 SMTP 连接到任意邮件服务器，并让他们在用户不知情的情况下发送垃圾邮件。这就是为什么该协议的设计方式使得任何服务器端应用程序在可以从 Web 浏览器使用之前都需要有意实施它。
关于端口：默认情况下，WebSocket 连接到端口 80，但 API 可以接收任何端口。客户端端口是随机的，就像大多数 TCP/IP-based 协议一样。
为什么不早点实现？因为直到最近，WhatWG 和 W3C 还没有得到所有主要浏览器开发人员的统一支持，从而获得引入新标准所需的权限。这就是为什么最近在标签 HTML5 下有如此大量的新浏览器功能。
webSockets 和常规套接字不是一回事。 webSocket 在常规套接字上运行，但在常规套接字之上运行自己的连接方案、安全方案和成帧协议，并且两个端点都必须遵循这些额外的步骤才能建立连接。您可以在此处查看 webSocket 协议：https://www.rfc-editor.org/rfc/rfc6455
最大的区别是所有的 webSocket 连接都是从客户端到服务器的 HTTP 请求开始的。客户端将 HTTP 请求发送到为正常 Web 通信打开的完全相同的服务器和端口（默认端口 80，但如果 Web 服务器在不同的端口上 运行，则 webSocket 通信将跟随它另一个端口）。客户端设置了一些自定义的 headers，其中最重要的是一个 header，表示客户端希望“升级”到 webSocket 协议。此外，双方还交换了一些安全密钥。如果服务器同意“升级”，则客户端和服务器都将通过原始套接字使用的协议从 HTTP 切换到 webSocket，现在使用 webSocket 框架协议。
此外，初始 HTTP 请求可以在其中包含一个请求路径，以指示 webSocket 请求的“sub-destination”。这允许使用相同的服务器和端口发起各种不同的 webSocket 请求。
还有一个可选的 sub-protocol 说明符和 Sec-WebSocket-Protocol header 允许请求进一步识别子协议（常见的可能是“聊天”），以便双方可以就一组特定的消息标识符及其可能使用的相应含义达成一致。
webSocket 连接以 HTTP 连接开始这一事实非常重要，因为如果您可以访问 Web 服务器进行正常的 Web 通信，那么您可以访问它进行 webSocket 请求，而无需客户端和服务器之间的任何网络基础设施必须在防火墙中打开新漏洞或打开新端口或类似的东西。
您可以在此处查看有关如何启动 webSocket 连接的精彩摘要：https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_servers。
webSocket 协议还定义了 ping 和 pong 数据包，帮助双方了解空闲的 webSocket 是否仍然连接。
我们只能假设将 webSockets 引入所有常见浏览器需要一段时间的原因与许多有用的功能需要一段时间的原因相同。首先，一群有积极性的人必须确定并同意需求，然后该小组需要带头开发解决问题的方法，然后这个想法会被讨论一段时间，要么收集支持并处理反对意见，要么与其他人竞争解决此类问题的替代方法，然后它似乎有足够的动力实际上可以成为标准，然后有人决定在浏览器和匹配的服务器实现中执行 test/trial 实现（有时这一步会出现早得多）。然后，如果它仍在寻找动力并且似乎在标准轨道上，其他浏览器制造商将接受这个想法并开始实施。一旦所有浏览器制造商都有一个体面的工作实现（通常会有几轮标准改进，因为不同的实现在规范中发现漏洞，或者当早期开发人员发现问题或缺少功能或出现安全问题时）。然后，至少有两个主要浏览器在其最新版本中具有该功能，该标准被认为相对可靠，消费者开始采用这些浏览器，一些网站开始通过使用新功能来改善他们的用户体验。那时，落后的浏览器开始感受到实施它的压力。然后，有时几年后，所有主要浏览器都具有该功能，并且这些浏览器具有足够的整体用户采用率，网站可以依赖该功能（而无需在浏览器不支持该功能时使用主要的第二个回退设计） .整个过程可能需要很多很多年。
下面是启动 webSocket 连接的初始 HTTP 请求示例：
GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
并且，服务器响应：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
还有一个数据框示例：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+
根据 Wikipedia，HTTP 和 WebSocket 之间的唯一关系是 Upgrade HTTP request 形式的额外握手。在那之后，浏览器和 HTTP 服务器似乎只会通过普通套接字以旧的 C/S 范例进行通信。
所以我的问题是：
- WebSocket 只是一种普通的套接字通信吗？
- 之所以叫
WebSocket，是因为通信的目标是服务器的80端口？即port 80只是web. 的同义词
- 80端口是服务器端的，客户端用的是什么端口？
- 如果它只是浏览器和服务器之间的普通套接字通信，为什么 WebSocket 直到最近才在浏览器中实现？它似乎只不过是对 B/S 范式的一点 C/S 扩展。
添加 1（2017 年 5 月 23 日上午 9:46）
今天，我重温了@jfriend00 的精彩回答。总结一下我的理解吧。
- Socket只是一个端到端的通信通道。它不限制可以使用什么通信协议。
- webSocket 和 HTTP 一样，只是另一种独立的通信协议。虽然名称中的 socket 一开始让我感到困惑。
- webSocket利用了和HTTP相同的端口号，如果我们能通过HTTP进行通信，就可以确定webSocket通信是可以进行的。因为频道打通了，我们可以选择最合适的方式在频道中对话。
不，WebSocket 不仅仅是普通的套接字。他们使用需要握手的成帧协议，然后用 32 位随机数交换由 XORint 屏蔽的消息。如需更多信息，read the RFC which standardizes them.
这个额外编码层的原因是允许网络浏览器创建任意套接字连接会引发各种安全问题。例如，您可以让您网站的访问者通过 SMTP 连接到任意邮件服务器，并让他们在用户不知情的情况下发送垃圾邮件。这就是为什么该协议的设计方式使得任何服务器端应用程序在可以从 Web 浏览器使用之前都需要有意实施它。
关于端口：默认情况下，WebSocket 连接到端口 80，但 API 可以接收任何端口。客户端端口是随机的，就像大多数 TCP/IP-based 协议一样。
为什么不早点实现？因为直到最近，WhatWG 和 W3C 还没有得到所有主要浏览器开发人员的统一支持，从而获得引入新标准所需的权限。这就是为什么最近在标签 HTML5 下有如此大量的新浏览器功能。
webSockets 和常规套接字不是一回事。 webSocket 在常规套接字上运行，但在常规套接字之上运行自己的连接方案、安全方案和成帧协议，并且两个端点都必须遵循这些额外的步骤才能建立连接。您可以在此处查看 webSocket 协议：https://www.rfc-editor.org/rfc/rfc6455
最大的区别是所有的 webSocket 连接都是从客户端到服务器的 HTTP 请求开始的。客户端将 HTTP 请求发送到为正常 Web 通信打开的完全相同的服务器和端口（默认端口 80，但如果 Web 服务器在不同的端口上 运行，则 webSocket 通信将跟随它另一个端口）。客户端设置了一些自定义的 headers，其中最重要的是一个 header，表示客户端希望“升级”到 webSocket 协议。此外，双方还交换了一些安全密钥。如果服务器同意“升级”，则客户端和服务器都将通过原始套接字使用的协议从 HTTP 切换到 webSocket，现在使用 webSocket 框架协议。
此外，初始 HTTP 请求可以在其中包含一个请求路径，以指示 webSocket 请求的“sub-destination”。这允许使用相同的服务器和端口发起各种不同的 webSocket 请求。
还有一个可选的 sub-protocol 说明符和 Sec-WebSocket-Protocol header 允许请求进一步识别子协议（常见的可能是“聊天”），以便双方可以就一组特定的消息标识符及其可能使用的相应含义达成一致。
webSocket 连接以 HTTP 连接开始这一事实非常重要，因为如果您可以访问 Web 服务器进行正常的 Web 通信，那么您可以访问它进行 webSocket 请求，而无需客户端和服务器之间的任何网络基础设施必须在防火墙中打开新漏洞或打开新端口或类似的东西。
您可以在此处查看有关如何启动 webSocket 连接的精彩摘要：https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_servers。
webSocket 协议还定义了 ping 和 pong 数据包，帮助双方了解空闲的 webSocket 是否仍然连接。
我们只能假设将 webSockets 引入所有常见浏览器需要一段时间的原因与许多有用的功能需要一段时间的原因相同。首先，一群有积极性的人必须确定并同意需求，然后该小组需要带头开发解决问题的方法，然后这个想法会被讨论一段时间，要么收集支持并处理反对意见，要么与其他人竞争解决此类问题的替代方法，然后它似乎有足够的动力实际上可以成为标准，然后有人决定在浏览器和匹配的服务器实现中执行 test/trial 实现（有时这一步会出现早得多）。然后，如果它仍在寻找动力并且似乎在标准轨道上，其他浏览器制造商将接受这个想法并开始实施。一旦所有浏览器制造商都有一个体面的工作实现（通常会有几轮标准改进，因为不同的实现在规范中发现漏洞，或者当早期开发人员发现问题或缺少功能或出现安全问题时）。然后，至少有两个主要浏览器在其最新版本中具有该功能，该标准被认为相对可靠，消费者开始采用这些浏览器，一些网站开始通过使用新功能来改善他们的用户体验。那时，落后的浏览器开始感受到实施它的压力。然后，有时几年后，所有主要浏览器都具有该功能，并且这些浏览器具有足够的整体用户采用率，网站可以依赖该功能（而无需在浏览器不支持该功能时使用主要的第二个回退设计） .整个过程可能需要很多很多年。
下面是启动 webSocket 连接的初始 HTTP 请求示例：
GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
并且，服务器响应：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
还有一个数据框示例：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+