본문으로 건너뛰기

1. 실시간 채팅을 위한 통신 프로토콜 선택​

  • 실시간 채팅 애플리케이션을 개발하면서 가장 먼저 마주치는 기술적 의사결정 중 하나는 클라이언트-서버 간 통신 프로토콜의 선택입니다.
  • HTTP Long Polling, Server-Sent Events(SSE), WebSocket 각각의 장단점을 분석하고, 우리 프로젝트에서 하이브리드 방식을 선택하게 된 과정을 공유하고자 합니다.

1.1 HTTP Long Polling​

  • 폴링은 클라이언트가 주기적으로 서버에 새 메시지가 있냐고 물어보는 방식입니다.
  • 폴링 비용은 주기가 짧을수록 높아지며, 답해줄 메시지가 없을 때도 계속해서 요청을 보내야 합니다.
  • 롱 폴링의 경우 클라이언트는 새 메시지가 반환되거나 타임 아웃 될 때까지 연결을 유지합니다.
Client -----> Request -----> Server
Client <---- Response <---- Server (data available)
Client -----> New Request -> Server

장점:

  • 구현이 단순함
  • 기존 HTTP 인프라 활용 가능
  • 모든 브라우저에서 지원

단점:

  • 불필요한 연결 생성/해제로 인한 오버헤드
  • 서버 리소스 비효율적 사용
  • 실시간성 보장이 어려움 (polling 간격에 따른 지연)

1.2 Server-Sent Events (SSE)​

  • 서버에서 클라이언트로 단방향 이벤트 스트림을 전송하는 기술입니다.
  • 클라이언트는 한 번 연결하면 서버가 메시지를 보낼 때까지 연결을 유지합니다.
  • 서버에서 클라이언트로만 데이터를 보낼 수 있으므로 단방향 통신에 적합합니다.
Client -----> Initial Request -----> Server
Client <---- Event Stream <-------- Server
Client <---- Event Stream <-------- Server
Client <---- Event Stream <-------- Server

장점:

  • HTTP 기반으로 기존 인프라 활용 가능
  • 단방향 통신에 최적화
  • 자동 재연결 메커니즘 내장

단점:

  • 클라이언트→서버 통신 불가 (단방향)
  • IE 미지원
  • 동시 연결 수 제한 (브라우저당 6개)

1.3 WebSocket​

  • 웹소켓은 서버가 클라이언트에게 비동기 메시지를 보낼 때 가장 널리 사용되는 프로토콜입니다.
  • 웹 소켓 연결은 클라이언트가 시작하며 처음에는 HTTP 연결이지만 업그레이드 요청을 통해 웹 소켓으로 전환됩니다.
  • 이후에는 양방향 통신이 가능하며, 서버와 클라이언트는 연결을 유지하고 메시지를 주고받을 수 있습니다.
Client -----> Upgrade Request -----> Server
Client <==== Bi-directional ======> Server

장점:

  • 진정한 양방향 실시간 통신
  • 단일 연결로 효율적인 리소스 사용
  • 최소한의 프로토콜 오버헤드
  • 높은 실시간성

단점:

  • 전용 서버 인프라 필요
  • 연결 유지 관리 필요
  • 프록시/방화벽 이슈 가능성
  • 메시지 전송 보장을 위한 추가 구현 필요

2. 우리의 선택: 하이브리드 접근 방식​

  • 우리 프로젝트에서는 HTTP API와 WebSocket을 조합한 하이브리드 방식을 선택했습니다.
  • 이 방식은 안정적인 메시지 전송과 효율적인 실시간 메시지 수신을 모두 만족시킬 수 있습니다.

2.1 프로토콜 조합​

  1. 메시지 전송: HTTP API
    • 신뢰성 있는 메시지 전송 보장을 위해 메시지 전송에는 HTTP API를 사용
    • 요청-응답 패턴으로 명확한 전송 상태 확인
    • 파일 첨부 등 복잡한 요청 처리 용이
    • 재시도 로직 기본 지원
  2. 실시간 메시지 수신 및 접속 상태 관리: WebSocket
    • 서버로부터의 실시간 메시지 수신은 WebSocket을 사용
    • 하트비트를 통해 사용자 접속 상태 관리
    • 사용자의 채팅방 포커스 상태 전달
    • 효율적인 실시간 이벤트 처리

3. 운영 시 고려사항​

3.1 연결 관리​

  • 하트비트를 통한 연결 상태 모니터링
  • WebSocket 자동 재연결 메커니즘 구현
  • 연결 풀링으로 메모리 관리
  • HTTP 요청 재시도 전략

3.2 보안​

  • JWT 기반 인증
  • SSL/TLS 적용
  • 메시지 검증 및 필터링

3.3 모니터링​

  • WebSocket 연결 상태 모니터링
  • HTTP API 응답 시간 추적
  • 리소스 사용량 관찰

4. 하이브리드 방식의 장단점​

4.1 장점​

  • 신뢰성과 실시간성의 균형
    • HTTP를 통한 안정적인 메시지 전송
    • WebSocket을 통한 효율적인 실시간 수신
  • 구현 복잡도 감소
    • WebSocket의 메시지 전송 보장 메커니즘 구현 불필요
    • 기존 HTTP 인프라 활용
  • 확장성 개선
    • 메시지 전송과 수신의 독립적 스케일링 가능
    • 각 프로토콜의 장점 활용

4.2 단점​

  • 프로토콜 관리 복잡성
    • 두 가지 연결 방식 관리 필요
    • 클라이언트 구현 복잡도 증가
  • 리소스 사용량
    • HTTP와 WebSocket 연결 모두 필요
    • 서버 리소스 사용량 증가

5. 결론​

  • 하이브리드 방식의 채택은 신뢰성과 실시간성이라는 두 가지 요구사항을 모두 만족시키는 균형 잡힌 선택이었습니다
    • HTTP를 통한 메시지 전송으로 신뢰성 있는 메시지 전달을 보장하면서도
    • WebSocket을 통한 실시간 수신으로 즉각적인 사용자 경험을 제공할 수 있었습니다