채팅서비스는 어떻게? 이론편

여행 플래너 서비스를 진행하면서 동행끼리 채팅서비스를 추가로 구현하였다. 

실시간 웹 애플리케이션을 구현할 경우 사용되는 대표적인 방법으로 polling / websocket / SSE 가 있는데 각각의 차이점과 내가 선택한 기술에 대해서 소개해보겠다.

 

코드를 짜는 부분은 다음편에서 다루겠다

https://soddong.tistory.com/15

 

---

기술들을 비교해보자

 

1. HTTP Polling

polling은 HTTP통신으로 클라이언트가 서버에게 지속적으로 변경사항을 모니터링 하는것이다.

위와 같이 Browser가 주기적으로 Server에게 요청을 보내고 event 여부에 대한 응답을 받는다.

단, 이렇게 하면 최대 주기만큼의 지연시간이 발생하여 실시간성이 떨어지며, 잦은 모티너링으로 인해 트래픽이 증가한다는 단점이 있다.

 

그래서 등장하는 녀석이 Long Polling.

기존의 polling방식과 달리 event가 발생하지 않으면 응답을 하지 않다가, event가 발생할때마다 응답을 보내는 방식이다.

 

 

2. SSE ( Server-sent Events )

클라이언트의 요청없이 서버에서 단방향으로 이벤트 발생시 전달을 하는 기법이다.

단, 양방향 통신이 불가하여 서버에서 일방적으로 알림을 줄때에만 사용 가능하다.

 

3. WebSocket

웹 소켓은 사용자의 브라우저와 서버 사이의 인터액티브 통신 세션을 설정할 수 있게 하는 고급 기술이다.

개발자는 웹 소켓 API를 통해 서버로 메시지를 보내고 서버의 응답을 위해 서버를 폴링하지 않고도 이벤트 중심 응답을 받는 것이 가능해진다. 

출처: 샌드버드

위 3가지 기술들과 비교했을 때 웹소켓은 아래와 같은 장점을 가진다.

• 한 번의 요청으로 연결을 유지하고 데이터를 주고 받을 수 있다.
• 지속적인 전이중 통신(Full Duplex) 통신 채널을 제공한다.
• 정기적인 http 요청이 없으므로 불필요한 오버헤드를 줄일 수 있다.

즉, 서버 입장에서도 네트워크 부하가 적으니 많은 클라이언트들의 실시간 연결이 필요한 (채팅 같은거) 경우 소켓 통신을 사용하는게 성능이나 확장성 면에서 더 효율 적이라고 할 수 있다.

 

한눈에 보기

기법	설명	장점	단점	적절한 상황
HTTP Polling	클라이언트가 주기적으로 서버에 요청을 보내 변경사항을 확인	구현이 간단함	실시간성이 떨어지며, 트래픽 증가	간단한 업데이트 확인
Long Polling	이벤트가 발생할 때까지 서버가 응답을 지연시킴	실시간성 개선, 상대적으로 간단함	서버 자원 사용 증가, 지연 발생 가능	실시간 채팅, 알림
SSE	서버가 클라이언트로 단방향 이벤트를 전달	서버 푸시 방식으로 실시간 업데이트 가능, 브라우저 호환성 좋음	단방향 통신만 가능, 클라이언트 수가 많을 때 서버 부담 증가	뉴스 피드, 주식 시세, 실시간 알림
WebSocket	클라이언트와 서버 간의 양방향 통신	매우 낮은 지연 시간, 효율적인 데이터 전송	복잡한 구현, 연결 관리 필요	실시간 게임, 채팅, 실시간 협업

 

 

---

웹 소켓을 더 자세히 들여다보자

 

웹소켓은 TCP연결에 의한 전이중 통신 채널을 제공하는 통신 프로토콜이다.

웹소켓 프로토콜은 RFC6455로 표준화되었고, 웹소켓 API는 W3C에 의해 표준화되었다. 

 

웹소켓과 HTTP의 차이점을 특징적인 것말고 통신적인 측면에서 들여다보자면, 두 프로토콜 모두 OSI모델의 7계층에 위치해 있으며 4계층인 TCP에 의해 전송된다. 다만, 웹소켓은 HTTP 포트 80과 443 위에 동작하며 HTTP 프록시 및 중간 층을 지원하도록 설계되었다. 

이게 무엇을 의미하냐면, 대부분의 기업 네트워크는 보안 목적으로 방화벽과 HTTP 프록시를 사용한다. 웹소켓이 HTTP 포트(80 및 443)를 사용하고 HTTP 프로토콜과 호환되도록 설계되면 이러한 방화벽과 프록시를 통과할 수 있다. 

즉, 웹소켓 통신이 기존의 HTTP 기반 인프라와 원활하게 작동할 수 있게 하여 배포와 사용을 간편하게 만든다.

 

다만, 호환이 되기 위해서는 HTTP 프로토콜에서 WS프로토콜로의 전환이 필요하고, 그렇기 때문에 업그레이드 헤더를 두어 프로토콜 변경을 할 수 있도록 한 것이다.

 

위의 사진을 다시 들여다보면 동작순서는 아래와 같다.

 

1. HTTP 프로토콜을 통해 Handshake

이 과정에서 header에 websocket 프로토콜로 upgrade하기 위한 정보들을 실어 보내고, 101 응답을 받는다.

// client -> server
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

// server -> client
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

• GET
  반드시 GET 메서드야 하며, HTTP 버전은 1.1 이상이어야 한다.
• Upgrade반드시 websocket 라는 키워드를 포함해야 한다.
  만약 이 값이 없거나 다른 값이면 cross-protocol attack 이라고 간주하고 WebSocket 접속과정을 중지한다.
• Sec-Websocket-Key
  베이스64 인코딩된 16바이트 값으로 구성되어야 하며, sha1 으로 해싱해서 Sec-Websocket-Accept 헤더로 응답해야 한다. 즉, Sec-Websocket-Accept 헤더는 서버가 웹소켓 프로토콜을 이해한다는 의미이다.
• Sec-Websocket-Version
  반드시 13이어야 한다. 예약어라고 한다.
• Sec-WebSocket-Protocol
  클라이언트가 요청하는 여러 서브프로토콜을 의미한다. 공백문자로 구분되며 순서에 따라 우선권이 부여된다. 서버에서 여러 프로토콜 혹은 프로토콜 버전을 나눠서 서비스할 경우 필요한 정보이다.

 

2. ws 프로토콜을 통해 Data 송수신

• FIN : 뒤에 오는 데이터가 더 있는지 확인하기 위한 패킷. (긴 데이터 전송시 쪼개서 보냄)
• OPCODE : Frame의 종류, 2바이트
  • continue = 0x0
    text = 0x1
    binary = 0x2
    close: 0x8
    Ping: 0x9
    Pong: 0xA
• MASK : 페이로드 데이터가 마스크되었는지 여부를 나타내는 단일 비트
• MASK-KEY : 페이로드 데이터(마스크된 경우)의 마스크를 해제하는 데 사용되는 32비트 값
• Payload Length : 페이로드 데이터의 길이를 나타내는 7비트, 16비트 또는 64비트 값
• Payload Data : 프레임이 전달하는 데이터

---

웹소켓의 한계는?

• 웹소켓은 HTML5 사양의 일부로, HTML5를 지원하지 않는 브라우저에서 사용할 수 없다. 
  → Socket.io나 Socket.js 라이브러리 사용
  
• 지속적인 연결을 유지하므로 서버의 부하가 증가 할 수 있다.
  → 연결 최적화 (타임아웃과 연결 수명 주기를 관리)
  → 서버를 관리 (로드밸런서를 이용한 트래픽 분산 등)
  → 효율적인 데이터 전송 (최소한의 데이터만 주고받도록 프로토콜 최적화)
  
• 웹소켓이 끊어졌을때 에러처리가 어렵다.
• 자동으로 재연결 되지 않으므로, 재연결을 할수있도록 구현해야 한다.
  → Socket.io 라이브러리 사용 (에러 처리할 수 있도록 내장되어있음)

---

지식 한스푼

 

웹소켓의 하위 프로토콜은 기본 웹소켓 프로토콜 위에 구축된 애플리케이션 프로토콜이다.

사용자가 정의한 통신 규칙을 더하여 기능을 더욱 확장할 수 있는데, 사용하기 위해서는 Sec-WebSocket-Protocol 헤더를 포함하여 하나 이상의 지원되는 하위 프로토콜을 지정할 수 있다.

 GET /websocket HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Version: 13 Sec-WebSocket-Protocol: subprotocol1, subprotocol2 Origin: http://example.com

 

요청을 받으면 서버는 제안된 하위 프로토콜을 검토하고 지원하는 하위 프로토콜을 선택합니다. 그런 다음 핸드셰이크 응답의 Sec-WebSocket-Protocol 헤더에 선택한 하위 프로토콜을 포함한다.

 HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= Sec-WebSocket-Protocol: subprotocol1

 

핸드셰이크가 완료되면 클라이언트와 서버는 해당 규칙과 규칙에 따라 선택한 하위 프로토콜을 사용하여 통신하게 된다.

 

이러한 방식으로 사용되는 하위 프로토콜로는 IoT 장치 통신용 프로토콜인 MQTT와 메시징 애플리케이션용 프로토콜인 XMPP가 있다.

 

 

STOMP 도 공부 후 올리기.

 

---

참고 페이지

https://techblog.woowahan.com/2681/?ref=codenary

우리도 채팅있으면 좋을 것 같아요. | 우아한형제들 기술블로그

https://teamblog.joonggonara.co.kr/%EC%A2%8C%EC%B6%A9%EC%9A%B0%EB%8F%8C-%EC%B1%84%ED%8C%85-%EA%B0%9C%EB%B0%9C-%EA%B8%B0-1-e67e3160f89e

채팅 만든 썰 푼다.

https://hudi.blog/websocket-with-nodejs/

채팅서비스를 구현하며 배워보는 Websocket 원리 (feat. node.js)

https://datatracker.ietf.org/doc/html/rfc6455

 

RFC 6455: The WebSocket Protocol

https://appmaster.io/ko/blog/websocket-peurotokol-jagdong-bangsig

WebSocket 프로토콜: 작동 방식에 대한 심층 분석 | AppMaster

https://ko.wikipedia.org/wiki/%EC%9B%B9%EC%86%8C%EC%BC%93

 

웹소켓 - 위키백과, 우리 모두의 백과사전

https://www.w3.org/TR/2009/WD-websockets-20091222/

The Web Sockets API

https://developer.mozilla.org/ko/docs/Web/API/WebSocket

WebSocket - Web API | MDN