Web-Network

채팅 서버 설계를 위한 배경지식 정리 (HTTP, WebSocket, WebRTC)

민돌v 2023. 5. 29. 22:47
728x90

===== 채팅서버 구현하기 시리즈 =====

 

오늘은 데이팅 앱 서비스를 토이프로젝트 주제로 하고있는 지금, 1 대 1 실시간 채팅 서버를 설계하기 위해 공부한 배경지식을 정리해 보고자 합니다.

 

 

📌 공부의 목적은 "1:1 실시간 채팅 서버 설계" 이며 어떤 방식으로 클라이언트와 클라이언트의 상태를 연결하고 실시간성으로 보장해 줄 것인지가 주 포커스였습니다.

 

정리는 아래의 목차 순서대로 입니다. 👏🏻 아 물론 모든 주제는 클라이언트의 연결 관점에서의 정리입니다.

[목차]

  1. HTTP 란
  2. HTTP 의 실시간 통신 방식
  3. WebSocket 이란
  4. WebSocket 작동 원리
  5. HTTP vs WebSocket
  6. WebRTC 란

✔️ 클라이언트 연결 방법 비교 - WebSocket vs HTTP

→ HTTP 와 WebSocket 이 아예 다른건 아니였고, HTTP의 단점을 보완하여 나온 것이 WebSocket 이였습니다.
    WebSocket 도 처음 연결은 HTTP 의 기반이되는 TCP 로 통신하고 그후 Socket 연결로 프로토콜을 변환하는 방식을 사용합니다.

1) HTTP

  • HTTP란, Hyper Text Transfer protocol 즉 하이퍼 텍스트를 웹 or 앱에 출력할수있도록 맞춘 통신 규약
  • HTTP 의 특징 중의 하나로 stateless(무상태성) 과 connectionless(비연결성)이 존재
  • 또한, 요청(Client) 과 응답 (Server)의 구조적인 특징도 가지고 있기 때문에 실시간 통신과는 어울리지 않음
  • HTTP 는 TCP 기반으로 만들어졌기 때문에 매 연결시 3 way handshake 과정이일어나 약간의 딜레이가 발생할 수 있다고 생각함
  • 실시간 데이터의 업데이트 주기는 예측 불허하고 매번 요청-응답의 구조로 통신하고, 응답 결과를 반영한다면 서버에 너무 많은 부하를 야기시킨다.
  • HTTP는 기본적으로 양방향 통신이 불가능합니다. 한 유저가 채팅방에 메세지를 전달했을 때 다른 채팅방은 새로운 메세지가 발생했는지 기본적으로는 알 수없습니다. → 이러한 양방향 통신을 위해 Polling 방식 혹은 소켓 통신 방식이 필요합니다.

 

2) HTTP의 실시간 통신 방식

📌 1. Polling

  • 브라우저가 일정한 주기마다 서버에 HTTP 요청을 보내는 방식

HTTP 폴링

  •  단점
    • time interval을 어떻게 잡냐에 따라 서버의 부하가 올라가거나 실시간성이 떨어지는 trade off 관계를 갖는다
  • 사용
    • 실시간성이 조금 떨어져도 되고 시간을 늘려 여러대의 클라이언트와 통신을 할 때 사용
    • 페북의 친구 리스트의 온라인 상태 확인 (1분주기)

 

📌 2. Long Polling 

  • polling의 서버 부하를 줄이면서 실시간성을 높이기 위한 방식
    1. HTTP 요청 시 서버는 해당 연결을 바로 해제하지 않고 일정시간 대기시킨다. 대기 시간 중 데이터가 업데이트(변경)가 일어났으면 바로 클라이언트에게 응답을 보내고 전달 받은 데이터를 처리한다. 응답을 받은 클라이언트는 바로 서버에 다시 요청을 보낸다
    2. 브라우저의 요청이 있어도 요청한 서버의 데이터 변경이 없으면 보내지 않는 것
    3. 응답이 와서 연결이 끊기면 클라이언트가 서버에 다시 요청한다

HTTP 롱 폴링

  •  단점
    • 여러 클라이언트와 잦은 데이터 변경이 일어나면 서버의 부담이 크다
    • 수백~수천대의 Client와 연결된 채팅 Server에서 한명이 채팅을 쓰면 데이터가 변경되어 Server는 변경된 데이터를 연결된 모든 Client에게 동시에 Response를 보내고, 다시 모든 Client에게 Request를 받으므로 순간적으로 Queue가 쌓여서 Server에 부담을 줄 수 있다
    • 즉 서버의 부하도 줄이고, 실시간성도 높여주지만 대규모 클라이언트와 연결되있고 데이터가 자주 변경되는 경우에서는 오히려 서버에 부담감을 줄수 있다.
  • 사용 : 실시간성이 필요한 적은 수의 클라이언트와 연결되있는 경우에 사용
    • 웹 1:1 채팅
    • 10명 이하의 상대와 채팅하는 경우

 

📌 3. Streaming

  • long polling의 연결구축에 대한 부하를 해결하는 방식이다
  • 서버에 연결 요청을 보내놓고 계속 응답 데이터를 다운받는다. 서버는 이벤트가 발생하면 응답을 보낸다 (클라이언트가 서버에 데이터를 보내기가 힘들다)
  • 요청에 대한 응답을 완료하지 않은 상태에서 데이터를 계속 내려받는 방식이다 → 따라서 응답을 받더라도 연결을 끊고 다시 request요청을 보내는 과정이 없고 계속 응답을 받아 처리한다
  • 단점 : 클라이언트에서 서버로 데이터를 보내는게 힘들다 → 따라서 실시간 양방향 통신이 아니라 실시간 단방향 통신이 주로 이뤄진다

 

3) WebSocket

  • HTTP 통신의 특징인 (연결 -> 연결 해제) 때문에 효율이 많이 떨어지게 되고, 웹 브라우저 말고 외부 플러그인이 항상 필요하게 되었다. 그래서 이런 상황을 극복하고자 2014년 HTML5에 웹 소켓을 포함하게 되었다. 웹소켓은 클라이언트가 접속 요청을 하고 웹 서버가 응답한 후 연결을 끊는 것이 아닌 Connection을 그대로 유지하고 클라이언트의 요청 없이도 데이터를 전송할 수 있는 프로토콜이다. 프로토콜의 요청은 [ws://~]로 시작한다.
  • 웹에서 하나의 TCP 연결을 통해 양방향 통신을 제공하는 컴퓨터 통신 프로토콜 (웹소켓은 HTTP환경에서 전이중 통신(Full Duplex, 2-way communication)을 지원하기 위한 프로토콜)
  • 실시간 서비스를 구현하기에 적합한 기술
  • HTTP 반이중 (Half-Duplex) 방식이 아닌 진짜 양방향 통신인 전이중(Full-Duplex) 방식이다
    • Half-Duplex (반이중) 이란
      • 양 방향 통신을 하지만 송-수신을 동시에 할 수없고, 무전기 처럼 한쪽에서만 통신할 수 있는 방식
    • Full-Duplex (전이중) 이란
      • 동시에 송수신을 하며 양 방향 통신을 할 수 있다.
  • 2022년 2월 현재는 일부 구버전 브라우저를 제외하고 모두 지원한다고 볼 수 있다.

→ 참고 :https://dev-gorany.tistory.com/212

 

📗 WebSocket  특징

  1. 최초 접속이 일반 HTTP 요청을 이용한 Handshaking 으로 이루어진다.
  2. TCP socket은 바이트 스트림을 사용하지만, WEB socket은 UTF-8의 텍스트와 바이너리 둘 다 보낼 수 있다.
  3. 텍스트의 경우 시작과 끝에 0x00과 0xFF를 붙여서 구분한다.
  4. statefull
    1. 서버와 클라이언트가 한번 연결되면 계속 같은 라인을 사용해 통신하므로 HTTP 사용 시 불필요하게 발생되는 연결 트래픽을 방지한다.
    2. Web Socket은 최초 접속을 제외하면 헤더 정보를 보내지 않지만, HTTP 프로토콜은 요청을 할 떄마다 헤더정보를 보내게 되므로 네트워크 비용에서 이득이다.
  5. HTTP 연결을 그대로 사용하기 때문에 HTTP는 80, HTTPS는 443 포트를 그대로 사용하면서 CORS 적용, 인증-인과 등을 기존과 동일하게 이용할 수 있습니다.

 

📗 웹 소켓 작동원리

  1. 웹소켓 연결을 위해 http통신을 한다
  2. handshake과정이 성공적으로 이뤄지면 HTTP 업그레이드 헤더를 사용하여 HTTP 프로토콜 → 웹 소켓 프로토콜로 변경하는 프로토콜 스위칭이 이뤄진다
  3. 이후 연결이 맺어지면, 어느 한쪽이 연결을 끊지 않는 이상 영구적인(persistent) 동일한 채널이 맺어지고, 웹소켓을 위한 소켓이 생성되고 해당 소켓으로 전이중 통신을 한다 (소켓은 ws[websocket], wss[websocket security] 가 있다, http, https와 동일한 차이)

 

✔️ WebSocket vs WebRTC

4) WebRTC 란 

  • Web Real-Time Communication
  • WebSocket 의 상위 기술입니다. WebSocket 은 서버 중심의 Request - Response 방식이기 대문에 메모리, 전달 속도, 비용 문제 등이 존재하는데 이를 해결하기 위해 나온게 WebRTC 입니다.
  • 쉽게 말해, 브라우저(Client)와 서버 통신이 아닌 - 브라우저(Client) 와 브라우저(Client)끼리 통신하여 중간자인 서버(Server)없이 브라우저 간 오디오, 영상 미디어, 데이터 등을 교환할 수 있도록 하는 기술입니다.

장점

  1. WebRTC 는 영상, 오디오, 임의의 데이터 통신이 high-performance, high-quality 이도록 설계되었다. (?)
  2. WebRTC 는 브라우저간 직접 통신이어서 훨씬 빠르다
  3. WebRTC 는 지연시간이 훨씬 짧다. (Low-Latency)

특징

  1. WebRTC 도 WebSocket 을 사용함
    1. P2P 연결을 통해 직접 통신하지만 WebRTC만으로 제어하기 어려운 심각한 부하를 다룰 수 있기 때문에 WebSocket혹은 socket.io (websocket js 라이브러리) 를 사용하여 Signaling 서버를 필요로합니다.

단점

  1. 러닝 커브가 높음
  2. p2p 방식을 사용하는 기술이기 때문에 up - down Link 의 수가 각 노드당 (n-1)개의 링크로 연결되어 있어 동시에 많은 유저가 접근할 경우 그 수만큼 데이터를 보내고 받아오는 과정을 거쳐야 합니다.
  3. WebRTC 종류

 

 

👏🏻 결론

1. HTTP, WebSocket, WebRTC 3개가 전부 무관한 서비스들이 아니고 각각의 단점들을 보완해서 나온 것이다.

2. HTTP 를 사용하여 실시간성을 보장하기에는 서버에 많은 부하가 갈 수 있고, 실시간성을 보장하여 구현하기에는 신경써야할 게 많다.

3. WebSocket을 사용하면 비교적 쉽게 실시간성을 보장한 통신이 가능하다. 하지만 큰 용량의 데이터를 매우 많이 통신할 때는 서버에 또 큰 부하가 간다.

4. WebRTC를 사용하면 브라우저 to 브라우저로 통신이 주를 이루기 때문에 오디오, 영상미디어등 큰 용량의 파일들도 부담없이 통신할 수 있고, 지연시간도 매우 낮다. 그러나 그만큼 러닝커브도 높고 → 1:1 텍스트 기반 통신에서는 오버스펙이란 느낌이 들었다.

 

 

🔥고로 WebSocket 을 사용해보고자 합니다!

반응형

'Web-Network' 카테고리의 다른 글

[Nginx] linux 실시간 access 로그 보기  (0) 2022.10.13
HTTP HEAD 메소드  (0) 2022.07.29
[mac] Nginx Tomcat 연동 - nginx 스프링 내장 톰캣 리다이렉트 방법 (Proxy Server)  (0) 2022.07.24
jar 파일 생성하고, local 에서 Jar 실행하기  (4) 2022.07.23
[Nginx] mac 로컬 환경에 nginx 설치 실행하기 (local os)  (0) 2022.07.22

'Web-Network'의 다른글

  • 현재글채팅 서버 설계를 위한 배경지식 정리 (HTTP, WebSocket, WebRTC)

관련글

티스토리툴바