WebSocket协议详解：RFC6455英文原版

需积分: 20 143 浏览量更新于2024-07-15 收藏 423KB PDF 举报

"WebSocket协议手册(rfc6455英文原版).pdf" WebSocket协议是互联网技术中的一个关键组件，尤其在实现实时、低延迟的双向通信方面。RFC 6455是由Internet Engineering Task Force (IETF)发布的一个标准文档，详细定义了WebSocket协议的规范。这份文档由I.Fette（来自Google, Inc.）和A.Melnikov（Isode Ltd.）共同撰写，并在2011年12月成为互联网标准。 WebSocket协议的核心在于提供一种安全的机制，允许运行在受控环境（如Web浏览器）中的不受信任的客户端代码与远程主机进行双向通信。这个安全模型基于起源（origin）原则，这是Web浏览器普遍采用的安全策略。协议由一个初始化的握手过程和随后的基本消息帧组成，基于TCP连接运行。协议的开放握手阶段是建立WebSocket连接的关键步骤。在这个阶段，客户端和服务器通过交换特定的HTTP头部信息来确认彼此支持WebSocket，并协商连接参数，如协议版本、子协议选择和随机密钥等。一旦握手成功，TCP连接就被“升级”为WebSocket连接，允许双方无限制地发送数据帧，而无需重复发起HTTP请求。 WebSocket协议的帧结构设计简洁，支持文本和二进制数据类型，可以高效地传输大量数据。它还提供了关闭连接、错误处理以及掩码数据等安全特性，以防止中间人攻击和其他安全问题。与传统的HTTP长轮询或XMLHttpRequest等技术相比，WebSocket的优势在于它只需要一个持久连接，减少了来回的HTTP头开销，从而降低了延迟，提升了效率。这对于实时应用，如在线游戏、股票交易、实时聊天和协作工具等，尤其重要。在RFC 6455中，还包含了关于协议的实施细节、错误处理机制、安全性考虑以及与其他网络协议的交互指南。这份文档对于开发者来说是一个宝贵的参考资料，它不仅阐述了WebSocket协议的基本原理，还提供了实际应用中的实践指导。 WebSocket协议通过提供浏览器与服务器之间的全双工通信能力，极大地推动了实时Web应用的发展。RFC 6455作为这一协议的官方标准，是所有 WebSocket实现和开发者的必备参考文献。

RFC 6455 The WebSocket Protocol December 2011

1.9. Subprotocols Using the WebSocket Protocol

_This section is non-normative._

The client can request that the server use a specific subprotocol by

including the |Sec-WebSocket-Protocol| field in its handshake. If it

is specified, the server needs to include the same field and one of

the selected subprotocol values in its response for the connection to

be established.

These subprotocol names should be registered as per Section 11.5. To

avoid potential collisions, it is recommended to use names that

contain the ASCII version of the domain name of the subprotocol’s

originator. For example, if Example Corporation were to create a

Chat subprotocol to be implemented by many servers around the Web,

they could name it "chat.example.com". If the Example Organization

called their competing subprotocol "chat.example.org", then the two

subprotocols could be implemented by servers simultaneously, with the

server dynamically selecting which subprotocol to use based on the

value sent by the client.

Subprotocols can be versioned in backward-incompatible ways by

changing the subprotocol name, e.g., going from

"bookings.example.net" to "v2.bookings.example.net". These

subprotocols would be considered completely separate by WebSocket

clients. Backward-compatible versioning can be implemented by

reusing the same subprotocol string but carefully designing the

actual subprotocol to support this kind of extensibility.

2. Conformance Requirements

All diagrams, examples, and notes in this specification are non-

normative, as are all sections explicitly marked non-normative.

Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in [RFC2119].

Requirements phrased in the imperative as part of algorithms (such as

"strip any leading space characters" or "return false and abort these

steps") are to be interpreted with the meaning of the key word

("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.

Fette & Melnikov Standards Track [Page 12]

RFC 6455 The WebSocket Protocol December 2011

Conformance requirements phrased as algorithms or specific steps MAY

be implemented in any manner, so long as the end result is

equivalent. (In particular, the algorithms defined in this

specification are intended to be easy to follow and not intended to

be performant.)

2.1. Terminology and Other Conventions

_ASCII_ shall mean the character-encoding scheme defined in

[

ANSI.X3-4.1986].

This document makes reference to UTF-8 values and uses UTF-8

notational formats as defined in STD 63 [RFC3629].

Key terms such as named algorithms or definitions are indicated like

_this_.

Names of header fields or variables are indicated like |this|.

Variable values are indicated like /this/.

This document references the procedure to _Fail the WebSocket

Connection_. This procedure is defined in Section 7.1.7.

_Converting a string to ASCII lowercase_ means replacing all

characters in the range U+0041 to U+005A (i.e., LATIN CAPITAL LETTER

A to LATIN CAPITAL LETTER Z) with the corresponding characters in the

range U+0061 to U+007A (i.e., LATIN SMALL LETTER A to LATIN SMALL

LETTER Z).

Comparing two strings in an _ASCII case-insensitive_ manner means

comparing them exactly, code point for code point, except that the

characters in the range U+0041 to U+005A (i.e., LATIN CAPITAL LETTER

A to LATIN CAPITAL LETTER Z) and the corresponding characters in the

range U+0061 to U+007A (i.e., LATIN SMALL LETTER A to LATIN SMALL

LETTER Z) are considered to also match.

The term "URI" is used in this document as defined in [

RFC3986].

When an implementation is required to _send_ data as part of the

WebSocket Protocol, the implementation MAY delay the actual

transmission arbitrarily, e.g., buffering data so as to send fewer IP

packets.

Note that this document uses both [

RFC5234] and [RFC2616] variants of

ABNF in different sections.

Fette & Melnikov Standards Track [Page 13]

RFC 6455 The WebSocket Protocol December 2011

Clients running in controlled environments, e.g., browsers on mobile

handsets tied to specific carriers, MAY offload the management of the

connection to another agent on the network. In such a situation, the

client for the purposes of this specification is considered to

include both the handset software and any such agents.

When the client is to _Establish a WebSocket Connection_ given a set

of (/host/, /port/, /resource name/, and /secure/ flag), along with a

list of /protocols/ and /extensions/ to be used, and an /origin/ in

the case of web browsers, it MUST open a connection, send an opening

handshake, and read the server’s handshake in response. The exact

requirements of how the connection should be opened, what should be

sent in the opening handshake, and how the server’s response should

be interpreted are as follows in this section. In the following

text, we will use terms from Section 3, such as "/host/" and

"/secure/ flag" as defined in that section.

1. The components of the WebSocket URI passed into this algorithm

(/host/, /port/, /resource name/, and /secure/ flag) MUST be

valid according to the specification of WebSocket URIs specified

in Section 3. If any of the components are invalid, the client

MUST _Fail the WebSocket Connection_ and abort these steps.

2. If the client already has a WebSocket connection to the remote

host (IP address) identified by /host/ and port /port/ pair, even

if the remote host is known by another name, the client MUST wait

until that connection has been established or for that connection

to have failed. There MUST be no more than one connection in a

CONNECTING state. If multiple connections to the same IP address

are attempted simultaneously, the client MUST serialize them so

that there is no more than one connection at a time running

through the following steps.

If the client cannot determine the IP address of the remote host

(for example, because all communication is being done through a

proxy server that performs DNS queries itself), then the client

MUST assume for the purposes of this step that each host name

refers to a distinct remote host, and instead the client SHOULD

limit the total number of simultaneous pending connections to a

reasonably low number (e.g., the client might allow simultaneous

pending connections to a.example.com and b.example.com, but if

thirty simultaneous connections to a single host are requested,

that may not be allowed). For example, in a web browser context,

the client needs to consider the number of tabs the user has open

in setting a limit to the number of simultaneous pending

connections.

Fette & Melnikov Standards Track [Page 15]

剩余70页未读，继续阅读

JackJiang9999

粉丝: 74
资源: 15

WebSocket协议详解：RFC6455英文原版

HTML5 WebSocket权威指南 PDF电子书下载 带书签目录 高清完整版

http权威指南-http入门手册

websocketpp.zip

javax.websocket-api-1.0.jar.zip

websocket协议

前后端分离项目使用WebSocket,报错 The remote party closed the WebSocket connection without completing the close handshake. 怎么解决，或者给一个完整的.net core案例

websocket协议手册 中文

什么是WebSocket协议，有何特点？

WebSocket webSocket = wsContext.WebSocket;

http升级成websocket协议步骤

最新资源

HTML5 WebSocket权威指南 PDF电子书下载带书签目录高清完整版

websocket协议手册中文