웹 소켓

1. 웹 소켑이란

• 채팅뿐만 아니라 실시간으로 데이터를 주고받을 때 쓴다
• 게임, 채팅, 실시간 주식 거래 사이트 등에 사용된다

웹 소켓을 사용해야만 실시간성을 보장하는 것은 아니다

• Http에서도 Polling, Long Polling, Streaming 으로 실시간성을 보장하는 기법이 있다
• 서버쪽으로 클라이언트가 지속적으로 요청을 보내거나
• 연결을 해놓고 끊지 않으면서 서버에서 메시지를 계속 받으면 된다

1). 웹소켓 vs http

• 하지만 웹소켓을 이용하는 것이 일반적이다
• 웹소켓은 연결을 하고 끊으라는 명령이 없으면 계속 연결을 하고 있는다
• Http는 요청-응답 구조인데 웹소켓은 일방적으로 듣고있어도 된다
• http는 요청을 보낼때마다 많은 양의 정보를 주고받아야한다.
• 하지만 웹소켓은 메시지로만 데이터를 주고받는다
  

2). 웹소켓을 사용할 수 있는 환경

• 거의 대부분 환경에서 사용할 수 있지만 구버전 브라우저에서는 지원을 안하는 경우도 있다
• 이럴때 SockJs와 Socket.io 라이브러리를 사용하면 된다
• 이 라이브러리는 웹소켓을 지원하지 않는 브라우저에서도 웹소켓을 사용하는 것처럼 사용할 수 있다
• 스프링은 SockJs와 Streaming과 Polling도 지원하고 있다

3). 스프링에서 기본 웹소켓

// 환경 설정
@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {
    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        // 클라이언트가 보내오는 통신을 처리할 핸들러가 필요하다
        registry.addHandler(new SocketTextHandler(), "/user") // 핸드쉐이크할 주소와 함꼐 인자를 넣으면 된다
                .setAllowedOrigins("*")
                .withSockJS();
    }
}

// handler
public class SocketTextHandler extends TextWebSocketHandler {

    private final Set<WebSocketSession> sessions = ConcurrentHashMap.newKeySet();

    @Override
    public void afterConnectionEstablished(WebSocketSession session) throws Exception {
        sessions.add(session);
    }

    @Override
    protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception {
        String payload = message.getPayload();
        for (WebSocketSession s : sessions) {
            s.sendMessage(new TextMessage(payload));
        }
    }
}

2. Redis, Kafka, WebSocketBroker

1). Redis와 WebSocketBroker

(1). WebSocketBroker

• Brokder는 STOMP 프로토콜을 통해 WebSocket위에서 메시지를 주고받을 수 있는 Pub/Sub이다
• 클라이언트가 연결되는 동안만 실시간 메시징을 제공하면 연결이 끊어지면 메시징도 종료
• 채팅처럼 실시간 연결이 필요한 경우에는 WebSocket이 더 적합해 보인다

(2). Redis

• pub/sub 기반 시스템을 쉽게 만들 수 있다
• 서로 다른 애플리케이션 간 또는 분산된 시스템에서 메시징 처리할 때 유리하다
• 다수의 구독자가 있어도 빠르게 처리할 수 있지만 복잡한 라우팅이나 메시지 저장 X
• 주로 실시간 알림이나 이벤트 전파에 사용된다
• 채팅에는 안어울리는 이유는 메시지를 저장하지 않고, 채널을 구독하지 않으면 메시지를 받을 수 없다. 또한 네트워크가 불안정할 때도 메시지를 잃지 않도록 해야하는데 데이터 손실이 일어날 수 있다
• 채팅은 온라인/오프라인을 추적하는게 중요하지만 Redis는 지원하지 않는다
• 브로드캐스트는 지원하지만 유니캐스트는 지원하지 않는다
• 레디스는 단일 쓰레드라서 대규모 사용자 채팅은 관리가 필요하다

(3). Kafka

• 카프카는 비동기 메시징에 최적화 되어 있어서 실시간 반응이 부족할 수 있다
• 비교적 무겁고, 연결 상태를 지원하지 않는다.
• 이러한 이유로 실시간 채팅으로는 쓸 만하지 않고 WebSocket과 상호보완해야 한다

(4). kafka와 WebSocketBroker

• 둘을 사용해서 실시간성과 데이터 보존을 모두 충족시키는 강력한 채팅 시스템을 구축할 수 있다