항해 8주차 마무리

최종 프로젝트 기간이다.
우리팀은 코딩을 하면서 문제가 생길 시 실시간으로 도움을 받을 수 있는 커뮤니티를 만들어 보자고 했다. 실시간이다 보니 채팅 구현이 필요했다.

WebSocket 과 Redis 공부 위주로 한주를 보냈다.

WebSocket이란?

• 기존 단방향의 HTTP 프로토콜과 호환되어 양방향 통신을 제공하기 위해 개발된 프로토콜

• 일반 Socket통신과 달리 HTTP포트(80)를 사용하므로 방화벽에 제약이 없다.

• 접속까지는 HTTP프로토콜을 이용하고 그 이후 통신은 자체적인 WebSocket 프로토콜로 통신하게 된다.

• WebSocket은 HTTP를 사용하는 네트워크 데이터 통신의 단점을 보완하는데 목적이 있다.

• 모든 HTTP를 사용한 통신은 클라이언트가 먼저 요청을 보내고 그 요청에 따라 웹 서버가 응답하는 방식이며 웹 서버는 응답을 보낸 후 브라우저와의 연결을 끊는다.

Polling, Long Polling, Streaming

• WebSocket이 존재하기 전에는 Polling이나 Long Polling, Streaming 등의 방식으로 해결했다.

Polling

• 클라이언트가 평범한 HTTP Request를 서버로 계속 요청해 이벤트 내용을 전달 받는 방식
• 가장 쉬운 방법이지만 클라이언트가 지속적으로 Request를 요청하기 때문에 클라이언트의 수가 많아지면 서버에 부담이 간다.
• HTTP Request connection을 맺고 끊는 것 자체가 부담이 많은 방식이고 클라이언트에서 실시간 정도의 빠른 응답을 기대하긴 어렵다.

Long Polling

• 클라이언트에서 버서로 HTTP Request를 요청한다. 이 상태로 계쏙 기다리며 서버에서 해당 클라이언트로 전달할 이벤트가 있다면 그 순간 Response 메시지를 전달하고 연결이 종료된다.
• 이어서 클라이언트가 다시 HTTP Request를 요청하여 서버의 다음 이벤트를 기다리는 방식이다.
• Polling 보다 서버의 부담이 줄었지만 클라이언트로 보내는 이벤트들의 시간 간격이 좁다면 Polling과 별반 차이는 없다. 동시에 다수의 클라이언트에게 이벤트가 발생될 경우 Polling과 마찬가지로 서버의 부담이 간다.

Streaming

• Long Polling과 마찬가지로 클라이언트에서 서버로 HTTP Request를 요청

• 서버에서 클라이언트로 이벤트를 전달할 때 해당 요청을 해제하지 않고 필요한 메세지만 보내기를 반복하는 방식

• Long Polling과 비교하여 서버에 메시지를 보내지 않고도 다시 HTTP Request연결을 하지 않아도 되어 부담이 줄어든다.

WebSocket

• 이처럼 HTTP통신의 특징(연결 -> 연결 해제) 때문에 효율이 많이 떨어지고 웹 브라우저 말고 외부 플러그인이 항상 필요했다.

• WebSocket은 클라이언트가 접속 요청을 하고 웹 서버가 응답한 후 연결을 끊는 것이 아닌 Connection을 그대로 유지하고 클라이언트의 요청 없이도 데이터를 전솔할 수 있는 프로토콜이다.

• WebSocket은 HTTP 환경에서 전이중 통신을 지원하기 위한 프로토콜이다.

• HTTP프로토콜에서 HandShaking을 와뇰한 후 HTTP로 동작하지만 HTTP와는 다른 방식으로 통신한다.

WebSocket 장점

• 최초 접속이 일반 HTTP Request를 통해 HandShaking과정으로 이루어져 있다.
• HTTP Request를 그대로 사용하기 때문에 기존의 80,433 포트로 접속을 하므로 추가 방화벽을 열지 않고도 양방향 통신이 간으하고 HTTP규격인 CORS 적용이나 인증 등 과정을 기존과 동일하게 가져갈 수 있는 장점이 있다.

STOMP란?

STOMP (Simple Text Oriented Messaging Protocol) 은 메세징 전송을 효율적으로 하기 위해 탄생한 프로토콜이고, 기본적으로 pub/sub구조로 되어있어 메세지를 전송하고 메세지를 받아 처리하는 부분이 확실히 정해져 있기 때문에 개발자 입장에서 명확하게 인지하고 개발할 수 있는 이점이 있다.
또한 STOMP를 이용하면 메세지의 헤더에 값을 줄 수 있어 헤더 값을 기반으로 통신 시 인증 처리를 구현하는 것도 가능하면 STOMP 스펙에 정의한 규칙만 잘 지키면 여러 언어 및 플랫폼 간 메세지를 상호 운영할 수 있다.

• STOMP는 TCP 또는 WebSocket과 같은 양방향 네트워크 프로토콜 기반으로 동작한다.
• STOMP는 Text 지향 프로토콜이나, Message Payload에는 Text나 Binary데이터를 포함할 수 있다.
• pub/sub 구조란 메시지를 공급하는 주체와 소비하는 주체를 분리해 제공하는 메시징 방법이다.
  • 우체통(Topic)이 있다면 집배원(Publisher)이 신문을 우체통에 배달하는 행위가 있고, 우체통에 신문이 배달되는 것을 기다렸다가 전달받아 보는 구독자(Subscriber)의 행위가 있다.
  • 구독자는 다수가 될 수 있다.

    채팅방 생성 : pub/sub 구조로 구현을 위한 Topic 생성
    채팅방 입장 : Topic 구독
    구독한 채팅방에서 메시지 송수신 : 해당 Topic으로 메시지 송신(pub), 메시지 수신(sub)

클라이언트는 메시지를 전송하기 위해 SEND, SUBSCRIBE COMMAND를 사용할 수 있다.

또한 SEND, SUBSCRIBE COMMAND 요청 Frame에는 메시지가 무엇이고, 누가 받아서 처리할지에 대한 Header 정보가 포함되어있다.

이런 명령어들은 destination 헤더를 요구하는데 이것을 어디에 전송할지, 혹은 어디에서 메시지를 구독할 것인지를 나타낸다.

위와 같은 과정을 통해 STOMP는 Publish-Subscribe 메커니즘을 제공한다.
즉, Broker를 통해 타 사용자들에게 메시지를 보내거나 서버가 특정 작업을 수행하도록 메시지를 보낼 수 있게 된다.

• 만약 Spring에서 지원하는 STOMP를 사용하면 Spring WebSocket 어플리케이션은 Broker로 동작하게 된다.