🙋🏻‍♀️야구 실시간 소통 플랫폼의 라이브 채팅 기능 구현 중,
websocket + stomp를 사용해 실시간 채팅기능을 구현했다.
실시간 통신을 위한
1. websocket 등장 이전의 방식 2. 단방향 통신(SSE) 3. 양방향 통신(Websocket) 에 대해 정리했다

기존의 Http 통신은
클라이언트가 서버에게 요청을 보내고, 응답을 받는 HTTP 기반 단방향 통신이다

🚫한계 : HTTP 통신의 Stateless, Connectionless한 특성

예를 들어, 내가 지금 구현하고자 하는 실시간 채팅의 경우,
채팅방에 참여중인 모든 상대방의 메세지를 받기위해서는 매번 요청을 보내야함

내가 먼저 메세지를 보낼 순 있지만, 서버는 선톡을 하지 않는다..^^
이를 해결하기 위한 Http 에서의 기술은 아래와 같다

📖 HTTP Polling

📌 Polling

클라이언트가 일정 주기로 http request를 보낸다

🚫 단점

• HTTP 오버헤드 발생 : 불필요한 요청 多
• 커넥션 맺을 때마다 비용 발생
• 클라이언트가 많아질 때마다 서버의 부담 ↑

---

📌 Long Polling

클라이언트의 request를 서버는 일정시간 대기 후 응답을 준다
응답까지의 시간을 최대한 늘려서 이벤트 발생시까지 대기한다

1. 클라이언트에서 서버로 http request를 보내면
2. 서버는 연결을 안끊고 기다림
3. 이벤트 발생시 서버는 응답을 주고 연결 종료
4. 클라이언트는 3번에서 응답을 받고 다시 요청을 보낸다

🚫 단점

• 데이터가 대기시간에 비해 변화가 잦을 경우, 일반 polling보다 <요청-응답>이 많아짐
• 다수의 클라이언트에 동시 이벤트 발생시, 응답 받은 후 마찬가지로 동시에 요청을 보내므로 서버 부담 급증

📖 SSE(Server Sent Event)

---

서버에서 클라이언트에게 실시간으로 데이터를 전송하는 기술이다
기본적으로 HTTP 연결을 길게 유지하면서 서버 ➝ 클라이언트로 데이터를 전송한다

polling 이후로 등장한 기술로 HTTP통신을 기반으로 단방향 통신 기술이다
주로 서버의 데이터 변경이 있을때 클라이언트에게 실시간으로 알려주기 위해 사용한다

✅ 동작 방식

1. Client : SSE Subscribe 요청

GET /connect HTTP/1.1
Accept: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

클라이언트 - EventSource 라는 인터페이스로 SSE 연결 요청을 한다

2. Server: Subscription에 대한 응답

HTTP/1.1 200
Content-Type: text/event-stream;charset=UTF-8
Transfer-Encoding: chunked

서버 - SseEmitter 를 이용해 구독 요청에 대한 응답을 한다

3. Server: 이벤트 전달

• 서버가 이벤트 스트림을 전송하여 실시간으로 업데이트된 정보를 제공한다
• 데이터는 UTF-8로 인코딩된 텍스트 데이터만 가능(바이너리 데이터❌)

🔍 데이터 형식 - name:value

event: type1
data: An event of type1.

event: type2
data: An event of type2.

📌 장단점

⭕️ 장점

• HTTP 프로토콜을 사용하기에 구현이 비교적 간단하다
  (특별한 라이브러리/추가설정 없이도 사용가능)
• 클라이언트 측에서 데이터를 이벤트로 처리하기 용이하다
• 네트워크 단절시 EventSource가 자동으로 재연결을 시도함

❌ 단점

• payload의 크기가 제한적이다
• 브라우저 호환성
• 단방향 통신만 가능하다

📖 Websocket

---

WebSocket은 기본 HTTP 핸드셰이크를 통해 연결을 시작하고,
이후에는 지속적인 TCP 연결을 통해 양방향 통신이 가능한 프로토콜이다

🔍 TCP = 연결지향 프로토콜 (http의 connectionless와 대비됨)

✅ 동작 방식

Websocket의 동작은 1️⃣ handshake , 2️⃣ Data transfer, 3️⃣ Close Handshake 의 과정을 거친다
과정 별로 자세히 살펴보자 !

📌 ❶ Handshake

• 처음 연결 시에는 HTTP 요청을 보낸다 GET
• 이후 응답이 101 Switching Protocols면 WebSocket 연결 성공!
• 🔍 port
  • ws://의 기본 포트는 80
  • wss://의 기본 포트는 443

✔️ Request 예시

GET /ws-endpoint HTTP/1.1 
Host: server.example.com 
Upgrade: websocket ---------------------------> ✅ 웹소켓 프로토콜로 변경할래
Connection: Upgrade ---------------------------> ✅ Upgrade 헤더를 사용한다
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 
Origin: http://example. com 
Sec-WebSocket-Protocol: chat, superchat ---------------------------> ✅ 서브 프로토콜
Sec-WebSocket-Version: 13 

✅ Upgrade, Connection 헤더 → 웹소켓 전환 요청임을 표시
✅ Sec-WebSocket-Key → 서버가 인증을 위해 확인하는 값

---

✔️ Response 예시

HTTP/1.1 101 Switching Protocols -------------------> ✅ 웹소켓 연결 성공 (101)
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

• 웹소켓 연결 성공은 상태코드 101 (그 외의 코드 응답시 http 통신 유지)
• Sec-WebSocket-Accept 작동 방식
  • 서버는 Sec-WebSocket-Key에 고정 문자열258EAFA5-E914-47DA-95CA-C5AB0DC85B11을 붙이고
  • SHA-1 해시 → Base64 인코딩하여 응답함 👉 연결 위조 방지용 보안 절차

📌 ❷ Data Transfer

WebSocket은 양방향(bidirectional) 통신이 가능하며,
데이터는 메시지 단위로, 그 메시지는 프레임(Frame) 단위로 분할 전송된다

🔍 Bidirectional WebSocket Message

• 서버 ↔ 클라이언트 모두 메시지를 자유롭게 보낼 수 있음
• 메시지를 프레임으로 나눠 보내는 구조

✔️ Websocket Frame 구조

[WebSocket 메시지]
 └── 하나 이상의 프레임으로 구성됨
       └── 각 프레임은 다음을 포함:
           - FIN (메시지의 끝인지)
           - Opcode (텍스트인지, 바이너리인지 등)
           - Masking key (보안용)
           - Payload (실제 데이터)

타입, 길이, 실제 데이터(payload) 등을 포함한다 !
.... 만약 조금 더 자세히 웹소켓의 프레임을 살펴보면 다음과 같다
( 여기서부턴 진짜 안봐도 된다 나는 그냥 실제 프레임 모습이 궁금했다 )

💡 Websocket Frame

 0               1               2               3
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S| (4)   |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
 4               5               6               7
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
 8               9               10              11
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
 12              13              14              15
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

• FIN : 마지막 메세지임을 나타냄 / FIN = 0이면 다음 메세지 있음, FIN = 1이면 전체메세지 도착완료
• opcode : payload의 데이터 포맷을 나타냄
  • 0x0은 continuation, 0x1은 텍스트(UTF-8), 0x2 바이너리 데이터...
• MASK : 메세지의 마스킹 여부 / 클라이언트 - 서버로 가는 메세지는 항상 마스킹되어야..
• payload : 보내고자 하는 실제 데이터
• payload length : 페이로드의 길이

🔍 opcode 0x0 ?
하나의 메세지를 여러 프레임으로 나눠 전송할 때 사용!
이거 n개의 메세지 중 중간이야! 뒤에 더 있음 근데 한 메세지임~을 표시

✔️ ping pong으로 연결 상태 확인

• ping : Websocket 연결 중이라면 클라이언트는 ping을 보낼 수 있음 opcode = 0x9
• pong : 서버는 ping을 받으면 payload를 그대로 담아 pong을 보냄 opcode = 0xA
  🌟 ping pong을 활용해 웹소켓 연결의 Open-Close 여부를 주기적으로 확인 가능

➕ 실제 코드 예시로 이해하기

• Websocket은 양방향 메세지를 send() 메서드로 보내고,
• onmessage나 handleTextMessage() 같은 이벤트 핸들러에서 수신 메세지를 처리한다

클라이언트 → 서버로 메시지 보내기

const socket = new WebSocket("ws://localhost:8080/ws-endpoint");
socket.send("Hello, Server"); // 메시지 전송
socket.onmessage = (event) => {
  console.log("Message from Server:", event.data); // 서버로부터 메시지를 받으면 실행되는 리스너
};

서버 → 클라이언트로 응답 처리 (Spring WebSocket)

@Override
protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception {
    String payload = message.getPayload(); // 클라이언트가 보낸 메시지 추출
    session.sendMessage(new TextMessage("Received: " + payload)); // 응답 보내기
}

❗ 다수의 클라이언트에게 브로드캐스트하려면?

for (WebSocketSession sess : sessions) {
    sess.sendMessage(new TextMessage("Broadcast: " + payload));
}

📌 ❸ Close

• Websocket 연결 종료를 의미한다 opcode = 0x8
• 클라이언트, 서버 어느 쪽이든 종료를 요청할 수 있다.
• Websocket에도 상태코드가 존재하지만, 연결 종료시 (Close Frame)에서만 쓰인다!
  ( 최초 Handshake시 성공 응답인 101은 Http status code임 )

📎Websocket Close Status Code
1000 : 정상 종료
1001 : 연결 주체 중 한쪽 소실
1009 : 메세지가 커서 처리 실패
1011 : 서버의 비정상 에러 발생

---

🚫 Websocket의 한계점

1. 데이터 해석의 어려움

• payload에 실제 데이터를 담아 전송하지만, 일정한 형식(json, xml 등,,,)이 정해져 있지않다
• 따라서 서버나 클라이언트에서는 문자열을 해석하는 작업(파싱)이 필요한데

📌 해결책 : 서브 프로토콜을 사용한다 (대표적인 하위 프로토콜 : stomp)

2. 연결 유실 및 호환성 이슈

• 일부 브라우저는 WebSocket의 Upgrade 헤더를 인식하지 못하거나
• 오랜 유휴상태일 TCP 연결을 조기 종료시킬 수 있음
  ➝ HTTP와 달리 WebSocket은 기존 인프라와 완전히 호환되지 않을 수 있다

📌 해결책 : SockJS(스프링>stomp) , Socket.io(노드)로 웹소켓 미지원환경에서 우회 연결 시도할 수 있음

🙋🏻‍♀️이렇게 실시간 통신을 위한 몇가지 기술들을 살펴봤다
SSE는 실시간 통신이 필요한 서비스에서 Polling을 대체할 수 있는 간단하고 강력한 옵션이지만,
양방향 통신이나 고급 메시징 구조가 필요하다면 WebSocket 기반으로 넘어가는 것이 일반적이다.
따라서 나는 Websocket + 서브 프로토콜인 STOMP를 사용했다