Please enable JavaScript.

Coggle requires JavaScript to display documents.

Spring WebSocket을 사용하는 이유는 무엇인가요? - Coggle Diagram

- - - - HTTP는 클라이언트의 요청이 있을 때만 서버가 응답하는 단방향 통신 모델입니다. 서버에서 클라이언트로 먼저 데이터를 푸시할 수 없습니다.
    - - 실시간 업데이트를 위해서는 Polling(주기적으로 서버에 요청)이나 Long Polling(서버가 응답을 지연시켜 데이터가 있을 때 응답)과 같은 방식을 사용해야 합니다. 이 방식들은 네트워크 트래픽 낭비, 서버 부하 증가, 지연 시간 발생 등의 단점이 있습니다.
        
        WebSocket의 등장
        
        양방향 통신
        
        WebSocket은 클라이언트와 서버 사이에 영구적인 양방향 통신 채널을 설정합니다. 한 번 연결이 수립되면 클라이언트와 서버는 독립적으로 언제든지 데이터를 주고받을 수 있습니다.
        
        낮은 오버헤드
        
        초기 핸드셰이크 이후에는 HTTP 헤더 없이 데이터 프레임만 전송하므로 HTTP Polling 방식에 비해 네트워크 오버헤드가 훨씬 적습니다.
        
        실시간성
        
        서버에서 데이터가 발생하면 즉시 클라이언트로 푸시할 수 있어 실시간성이 보장됩니다.
        
        polling
        
        클라이언트가 일정 주기로 서버에 지속적으로 요청을 보내 새로운 데이터가 있는지 확인하는 방식
        
        장점: 구현이 비교적 간단하고 기존 HTTP 인프라를 그대로 활용할 수 있습니다.
        
        단점: 새로운 데이터가 없어도 계속 요청을 보내므로 네트워크 트래픽 낭비가 심하고, 서버 부하를 증가시키며, 실시간성이 떨어집니다 (데이터 발생 시점과 클라이언트 수신 시점 사이에 지연 발생).
        
        Long polling
        
        클라이언트가 서버에 요청을 보내면, 서버는 새로운 데이터가 발생할 때까지 응답을 지연시키고, 데이터가 발생하면 응답하는 방식
        
        장점: Polling 방식보다 네트워크 트래픽 낭비가 적고 실시간성이 개선
        
        단점: 서버에서 연결을 계속 유지해야 하므로 서버 리소스 소모가 크고, 연결당 하나의 요청만 처리 가능하며, 여전히 양방향 통신이 아닌 단방향 요청-응답 모델입니다.
- - - - 데이터의 순서 보장, 재전송 기능 등이 있어 대부분의 웹 통신에서 사용됩니다.
        
        WebSocket은 TCP 위에서 동작합니다.
  - - - 신뢰성보다는 속도에 중점
        
        데이터 손실이나 순서 변경이 발생할 수 있지만, 오버헤드가 적어 스트리밍이나 게임 등 실시간성이 중요한 애플리케이션에서 사용되기도 합니다.
  - - - HTTP 포트(80, 443)를 사용하여 방화벽 문제를 피하면서도 양방향 통신을 제공
        
        초기 HTTP 핸드셰이크를 통해 연결을 수립한 후, 프로토콜을 WebSocket으로 전환(Upgrade)하여 동작
- - - - HTTP와 유사하게 CONNECT, SUBSCRIBE, SEND, DISCONNECT와 같은 프레임을 사용하여 메시지를 교환
  - - - 발행(Publish)/구독(Subscribe) 모델을 쉽게 구현할 수 있습니다. 특정 주제(Topic)를 구독한 모든 클라이언트에게 메시지를 발행하거나, 특정 사용자에게만 메시지를 전송할 수 있습니다.
    - - 클라이언트와 서버 모두에서 메시지를 보내고 받는 과정을 표준화된 프레임으로 처리하여 개발을 용이하게 합니다.
    - - 다양한 언어와 플랫폼에서 STOMP 클라이언트를 사용할 수 있어 상호 운용성이 높습니다.
    - - Spring은 STOMP를 완벽하게 지원하여 복잡한 메시징 로직을 손쉽게 구현할 수 있도록 돕습니다.
      - Spring WebSocket의 장점
        
        높은 추상화 수준
        
        WebSocket API를 직접 다루는 대신, Spring의 추상화된 API를 통해 간단하게 WebSocket 핸들러를 구현할 수 있습니다.
        
        STOMP 지원
        
        STOMP over WebSocket을 완벽하게 지원하여 메시지 라우팅, 메시지 브로커 설정 등을 간편하게 할 수 있습니다.
        
        SimpMessagingTemplate을 사용하여 서버에서 클라이언트로 메시지를 쉽게 보낼 수 있습니다.
        
        Annotation 기반 설정
        
        MessageMapping, SendTo, SubscribeMapping 등과 같은 애노테이션을 사용하여 컨트롤러 방식으로 메시지 처리를 정의할 수 있습니다.
        
        Security 통합
        
        Spring Security와 연동하여 WebSocket 통신에 대한 인증 및 권한 부여를 쉽게 적용할 수 있습니다.
        
        확장성
        
        외부 메시지 브로커(예: RabbitMQ, ActiveMQ)와 연동하여 분산 환경에서도 안정적인 메시징 시스템을 구축할 수 있습니다.
        
        개발 생산성
        
        Spring의 강력한 기능(DI, AOP 등)을 WebSocket 애플리케이션에서도 활용할 수 있어 개발 생산성이 높습니다.
- - - - 고성능 비동기 이벤트 기반 네트워크 프레임워크
        
        매우 낮은 수준에서 네트워크 통신을 제어
        
        뛰어난 성능과 유연성을 제공하며, 대규모 동시 접속 처리에 강점
    - - 학습 곡선이 높고, 직접 모든 프로토콜 및 메시징 로직을 구현해야 하므로 개발 복잡도가 높습니다.
        
        Spring WebSocket에 비해 개발 생산성이 낮을 수 있습니다.
    - - Kafka, Cassandra 등 많은 오픈소스 프로젝트에서 Netty를 사용
  - - - 특정 요구사항에 맞춰 완전히 커스터마이징된 서버를 구축
        
        불필요한 의존성을 제거하고 경량화된 서버를 만들 수 있습니다.
    - - WebSocket 프로토콜 구현, 메시지 라우팅, 세션 관리, 에러 처리 등 모든 것을 직접 구현해야 하므로 개발 시간과 노력이 매우 많이 소요
        
        안정성 및 확장성 확보가 어렵습니다.
    - - 매우 특수하고 제약적인 환경에서만 고려될 수 있습니다.
  - - - JavaScript 기반으로 프론트엔드와 백엔드를 동일 언어로 개발할 수 있어 풀스택 개발에 용이합니다.
        
        Socket.IO 라이브러리는 WebSocket을 포함한 다양한 실시간 통신 기술을 추상화하여 제공하므로 개발이 매우 쉽고 빠릅니다.
    - - 대규모 동시 접속 환경에서 Java 기반 서버에 비해 성능이 떨어질 수 있다는 의견도 있습니다. (물론 Node.js도 충분히 고성능을 낼 수 있습니다.)
    - - 실시간 채팅, 게임, 알림 등 다양한 실시간 웹 애플리케이션.
  - - - Go 언어의 뛰어난 동시성(Goroutine, Channel) 덕분에 고성능 WebSocket 서버를 쉽게 구축할 수 있습니다.
        
        낮은 메모리 사용량과 빠른 실행 속도가 특징입니다.
    - - Java나 Node.js에 비해 생태계가 작을 수 있으며, 개발자 수가 적을 수 있습니다.
    - - 고성능 실시간 시스템, 마이크로 서비스 아키텍처.