我们为什么使用 在 websocket 握手响应中？

Question

为什么我们在 JS WebSocket 握手

\r\n

的 HTTP 标头中使用

response

并在最后使用两次

\r\n\r\n

，但在握手

request

中却没有使用？是否可以在不添加

\r\n

的情况下进行握手响应？

\r\n

也用于TCP套接字还是仅用于JS WebSocket？

例如：

"Upgrade: something\r\n".
"Connection: something\r\n".
// ...
"Sec-WebSocket-Accept: something\r\n\r\n";

Answer 1

为什么我们使用 在 JS WebSocket 握手响应的 HTTP 标头中...

最初的Websocket握手是HTTP。所以所使用的消息格式是在HTTP规范中定义的。 HTTP 本身从早期的标准（例如 RFC 821（邮件格式））中继承了这个想法，而 RFC 821（邮件格式）又从旧的东西中得到了这一点 - 我们只能说它的演变方式与语言的演变方式类似。人们可能会采取不同的做法，但现在是这样的。

重要的是，所有人都以相同的方式使用它并以相同的方式理解它，包括理解它既不是您所说的

\n\r

，也不是常用的

\n

，而是

\r\n

。

是 是也用在 TCP socket 上还是没有只用在 JS WebSocket 上？

TCP 是一个八位字节流，仅当不同的传输字节在 TCP 级别没有特定含义时。 HTTP 或 WebSocket 等应用层协议为字节添加了含义，从而定义了传输数据的结构。最终，WebSocket 使用 TCP 套接字来传输消息，即 WebSocket 本质上定义了结构化消息以及它们如何序列化为字节以便在 TCP 提供的数据流中传输。

Answer 2

初始的WebSocket握手请求是标准的HTTP升级请求。 HTTP 使用 CRLF（在许多语言（包括 C 和 C++）中可以使用

\r\n

转义序列来表示）来终止消息标头中的每一行，并使用 2 个 CRLF 将消息标头与其正文分开。格式化初始握手时必须遵循 HTTP 规范。

阅读 RFC 6455 了解 WebSocket 协议规范，这一切都包含在其中。