Similar to HTTP, WebSocket is just an application layer protocol, which is transparent to the lower layer, so it does not involve TCP/IP.
Since the browser supports WebSocket, there is no need to consider the encoding and decoding of data when writing the client in JS.
The following is mainly for the server side.
[To receive data, what needs to be done is to decode, that is, decode]
To receive WebSocket data, an endpoint listens for underlying network connections.
Incoming data must be parsed as WebSocket frames. https://tools.ietf.org/html/rfc6455#section-5.2
If a control frame is received, this frame must be processed. https://tools.ietf.org/html/rfc6455#section-5.5
When the data frame is received, https://tools.ietf.org/html/rfc6455#section-5.6
Endpoints must interpret /type/ of data as a defined opcode (frame-opcode). https://tools.ietf.org/html/rfc6455#section-5.2
The application layer data (Application data) in the frame is defined in /data/ of the message.
If the frame contains an unfragmented message, https://tools.ietf.org/html/rfc6455#section-5.4
It is saying that a WebSocket message containing type /type/ and data /data/ has been received.
If the frame is part of a fragmented message, subsequent data frames of application data (Application data) are concatenated to form data.
When the last fragment (fragment) is received as a FIN bit (frame-fin) flag,
Indicates that the WebSocket message has received data /data/ (including application layer data consisting of fragments) and type /type/ (the first frame of the fragmented message).
Subsequent data frames must be interpreted as new WebSockets.
Extensions may change the semantics of how data is read, https://tools.ietf.org/html/rfc6455#section-9
In particular include - what constitutes the boundaries of the message.
In a payload, extensions may also modify application layer data (by compressing it) in order to prepend extension data to application layer data.
The server MUST remove the masking of data frames received from the client. https://tools.ietf.org/html/rfc6455#section-5.3
[To send data, what needs to be done is to encode, that is, encode]
To send a WebSocket message containing /data/ over a WebSocket connection, the endpoint must perform the following steps.
1. The endpoint must ensure that the WebSocket connection is in the OPEN state (after the handshake operation). If on any endpoint, the WebSocket connection state changes, the endpoint MUST terminate the following steps.
2. The endpoint MUST encapsulate /data/ into a WebSocket frame. https://tools.ietf.org/html/rfc6455#section-5.2
3. The data contained in the opcode (frame-opcode) of the first data frame must be set to an appropriate value for the data to be interpreted by the receiver as text data or binary data. https://tools.ietf.org/html/rfc6455#section-5.2
4. The last frame FIN bit (frame-fin) containing data, must be set to 1. https://tools.ietf.org/html/rfc6455#section-5.2
5. If data is being sent by the client, the frame must be masked. https://tools.ietf.org/html/rfc6455#section-5.3
6. If extensions to WebSocket connections have been agreed upon, additional considerations may apply as defined by those extensions. https://tools.ietf.org/html/rfc6455#section-9
7. The formed frame must be transmitted over the underlying network connection.
I believe you also understand that this process is an interaction and elaboration. The implementation needs to be coded according to the explanation in section-5, and as long as the function is implemented, there is no limit to the method.