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

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 -

물론 스펙을 정독하고 이해하는 것이 정석이겠습니다만, 항상 쉬운 길을 찾게되네요.

하지만, 그 길을 걷다 보면 무슨 내용인지 전혀 파악이 되지 않을 때도 많습니다. ㅠㅠ

몇가지 reference link들을 정리하면서, websocket에 대해서 파악해 봅니다.

1. https://en.wikipedia.org/wiki/WebSocket

• WebSocket is located at layer 7 in the OSI model and depend on TCP at layer 4. 
• WebSocket enables streams of messages on top of TCP.

2. https://www.mischianti.org/2020/12/07/websocket-on-arduino-esp8266-and-esp32-client-1/

• WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection.
• The big difference from REST server is that in an http request you send request and you must wait response to have the data and start new request on the same connection, with the WS you can stream requests and stream responses than operate when you want.

그리고, 가장 중요한 그림이 나옵니다.

3. https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers

• A WebSocket server is nothing more than an application listening on any port of a TCP server that follows a specific protocol.
• WebSocket servers are often separate and specialized servers (for load-balancing or other practical reasons), so you will often use a reverse proxy (such as a regular HTTP server) to detect WebSocket handshakes, pre-process them, and send those clients to a real WebSocket server. This means that you don't have to bloat your server code with cookie and authentication handlers (for example).
• First, the server must listen for incoming socket connections using a standard TCP socket.
• The Sec-WebSocket-Accept header is important in that the server must derive it from the Sec-WebSocket-Key that the client sent to it. To get it, concatenate the client's Sec-WebSocket-Key and the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" together (it's a "magic string"), take the SHA-1 hash of the result, and return the base64 encoding of that hash.

Frame format

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

• HTTP와 유사하게 OSI 모델의 7 layer에 위치하는 application
• Full duplex로, client의 요청 없이도 서버가 데이터의 전송을 시작할 수 있음

결론적으로 "TCP protocol 상에서 돌아가는 application으로 서버와 clients간에 full duplex를 지원하는 프로토콜" 정도로 이해할 수 있어 보입니다.

- End -