더디지만... 꾸준히...

Websocket 스펙인 RFC6455를 살펴봤습니다.

약 3000 라인이 조금 넘는 text 파일인데, 앞서 자료들을 찾아 읽고 나서인지 기본적인 내용을 파악하기는 힘들지 않았습니다.

주요 내용을 정리하면 다음과 같습니다.

- The protocol consists of an opening handshake followed by basic message framing, layered over TCP.

- The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections
- The WebSocket Protocol is designed to supersede existing bidirectional communication technologies that use HTTP as a transport layer to benefit from existing infrastructure (proxies, filtering, authentication).

  HTTP가 제공하는 기존의 인프라를 이용할 수 있다.
- The protocol has two parts: a handshake and the data transfer.

  Handshake와 data transfer로 구성된다.
- In a handshake, the leading line from the client follows the Request-Line format. 

  And the leading line from the server follows the Status-Line format. (HTTP Spec.)
- After a successful handshake, clients and servers transfer data back and forth in conceptual units referred to in this specification as "messages". On the wire, a message is composed of one or more frames.

  Handshake 이후에 메시지들을 주고 받게 된다.
- A frame has an associated type. Each frame belonging to the same message contains the same type of data. This version of the protocol defines six frame types and leaves ten reserved for future use.

1.3. Opening Handshake

- For this header field, the server has to take the value (as present in the header field, e.g., the base64-encoded [RFC4648] version minus any leading and trailing whitespace) and concatenate this with the Globally Unique Identifier (GUID, [RFC4122]) "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in string form, which is unlikely to be used by network endpoints that do not understand the WebSocket Protocol. A SHA-1 hash (160 bits) [FIPS.180-3], base64-encoded (see Section 4 of [RFC4648]), of this concatenation is then returned in the server's handshake.

https://not-to-be-reset.tistory.com/91를 살펴보면, 위 내용을 Python으로 실제 시험할 수 있습니다.

- The |Sec-WebSocket-Accept| header field indicates whether the server is willing to accept the connection.

1.4. Closing Handshake
- By sending a Close frame and waiting for a Close frame in response, certain cases are avoided where data may be unnecessarily lost.

1.5. Design Philosophy
- The WebSocket Protocol is designed on the principle that there should be minimal framing.
- It is expected that metadata would be layered on top of WebSocket by the application layer, in the same way that metadata is layered on top of TCP by the application layer (e.g., HTTP).

4.1. Client Requirements
- The handshake consists of an HTTP Upgrade request, along with a list of required and optional header fields.

5. Data Framing
- A client MUST mask all frames that it sends to the server
- A server MUST NOT mask any frames that it sends to the client.
- Octet i of the transformed data ("transformed-octet-i") is the XOR of octet i of the original data ("original-octet-i") with octet at index i modulo 4 of the masking key ("masking-key-octet-j"):
- Control frames are identified by opcodes where the most significant bit of the opcode is 1.  Currently defined opcodes for control frames include 0x8 (Close), 0x9 (Ping), and 0xA (Pong).  Opcodes 0xB-0xF are reserved for further control frames yet to be defined.

이후에는 필요한 시점에 참고하면 될 것 같습니다.

- End -