실시간 통신 기술

Choi Jimin·2023년 4월 23일
0

Web

목록 보기
1/5
post-thumbnail

실시간 통신이란

  • 정의

RTC(Real Time Communication)란, 전송 지연 없이 발생하는 모든 통신을 의미하는 용어이다. RTC는 최소한의 Latency를 가지고 즉각적인 반응을 보인다. 흔히 말하는 ‘라이브’ 통신이라고 볼 수 있다.

RTC는 일반적으로(기본적으로) Broadcast 또는 Multicast가 아닌 Peer-To-Peer 통신이다.

즉 말 그대로, 무시할 수 있는 (매우 작은) 대기 시간으로 즉시 정보를 교환할 수 있는 기술이다.

실시간 통신 기술 종류

실시간 통신 기술 종류에는 크게 Polling, Long Polling, SSE, WebSocket, P2P 등이 존재한다.

1. Polling

기본적인 개념(정의)

OS에서 흔히 말하는 polling 방식과 거의 유사한 개념으로 볼 수 있다.

통신에서 polling은 한 장치(프로그램)에서 다른 장치(프로그램)들이 어떤 상태에 있는지를 지속적으로 체크하는 전송 제어 방식이다. 즉, 계속해서 주기적으로 한 장치가 다른 장치에게 확인 메시지를 보내는 것이다.

웹에서 polling도 같은 개념이다. 브라우저가 일정한 주기로 서버에게 HTTP 요청을 보내는 방식이 웹에서의 polling이다.

동작 원리

HTTP 통신은 기본적으로 stateless(connectionless)이기 때문에, 서버가 클라이언트에게 일방적으로 응답을 보낼 수 없다. HTTP 통신은 클라이언트에게 요청을 받아야지만 응답을 보내는 구조이므로, 서버가 클라이언트에게 데이터를 보내고 싶다면 클라이언트가 요청을 보낼때까지 기다려야 한다.

이러한 HTTP 통신을 통해 매우 1차원적으로 해결한 방식이 polling이다. 클라이언트가 주기적으로 요청을 보내도록 하여 요청이 보내진 시기에 서버가 전달하고자 하는 내용이 있는지 확인 후, 있다면 해당 내용을 서버가 응답으로 보내는 것이다.

예시

회사 상사 A와 사원 B가 있다고 가정하자. 상사 A는 사원 B에게 무한 개의 보고서 작성 업무를 지시하였다. 상사 A는 사원 B에게 보고서 1개가 작성 완료될 때마다 해당 보고서를 전달 받고 싶다. (이때 사원 B는 무한 개의 보고서를 1번부터 순차적으로 작성한다.)

💡 Polling 방식을 적용해보자!

  1. 상사 A는 오후 1시에 심부름 로봇에게 사원 B를 찾아가 작성 완료된 보고서를 요청하도록 명령한다.
  2. 사원 B는 아직 보고서 작성을 완료하지 않아 전달이 불가능하다고 응답한다. 심부름 로봇은 해당 응답을 들고 상사 A에게 돌아간다.
  3. 상사 A는 오후 1시 10분에 심부름 로봇에게 사원 B를 찾아가 작성 완료된 보고서를 요청하도록 명령한다.
  4. 사원 B는 아직 보고서 작성을 완료하지 않아 전달이 불가능하다고 응답한다. 심부름 로봇은 해당 응답을 들고 상사 A에게 돌아간다.
  5. 이와 같이 상사 A는 10분마다 심부름 로봇을 통해 사원 B를 찾아가 작성 완료된 보고서를 요청하고, 사원 B는 보고서 작성이 완료되지 않았기 때문에 계속해서 전달이 불가능하다고 응답한다.
  6. 사원 B는 오후 4시 11분에 첫 번째 보고서 작성을 완료하였다.
  7. 상사 A는 오후 4시 20분에 심부름 로봇을 통해 사원 B를 찾아가 작성 완료된 보고서를 요청한다.
  8. 사원 B는 완료된 보고서를 전달함으로써 응답한다.

딱 봐도 고생스럽다. 웹에 이를 적용해보자면 10분마다 발생하는 요청과 응답이, HTTP 요청과 응답이 될 것이고, 이는 엄청난 HTTP 오버헤드 발생의 결과를 낳는다. 심지어 실제 웹 개발 시에는 polling 주기가 10분보다 훨씬 짧기 때문에 더더욱 HTTP 오버헤드 증가가 심해질 것이다. 또한 6번에서 처럼 작업이 완료되어 응답을 바로 보낼 수 있는 상황에서도 주기적으로 오는 다음 요청을 기다린 후 작업 결과를 보낼 수 있기 때문에 실시간성도 떨어진다. 물론 개발 자체는 매우 간단하고 기존 개발 상태에서 어렵지 않게 확장 구현 가능하다는 장점이 있다.

적합한 서비스(적합한 상황)

  • 실시간 통신이 중요하지 않은 서비스 (실시간 통신을 위한 기술인데 이렇게 모순될 수 있을까…)
  • 높은 HTTP 요청 빈도에도 안정적으로 대응할 수 있는 서버 구축 환경을 갖춘 서비스
  • 간단한 토이프로젝트

2. Long Polling

기본적인 개념(정의)

이름에서부터 느껴지듯이, polling 방식의 응용 버전이다. HTTP 요청 시 서버가 응답을 보낼 때까지 일정 기간동안 해당 요청을 대기시키는 방식이다.

동작 원리

polling이 계속해서 요청을 보내는 방식이었다면, long polling은 요청을 보낸 후 응답이 올 때까지 일정 기간 대기를 하는 방식을 반복하는 것이다. 즉, polling 하나의 생명주기를 늘려, 서버에게 요청을 보낸 후 대기 시간 안에 서버에서 데이터가 업데이트되면(응답할 데이터가 생기면) 클라이언트에게 응답을 보내는 동작을 반복하는 것이다. 이때 만약 대기 시간 안에 서버에서 데이터 업데이트가 일어나지 않으면, time out이 되고, 클라이언트는 재요청을 보내게 된다.

일반적으로 polling 방식보다 HTTP 요청 수가 줄어든다는 장점이 있다. 하지만 서버의 데이터 업데이트가 자주 일어날 경우 polling에 비해 성능상 큰 장점은 없다.

예시

회사 상사 A와 사원 B가 있다고 가정하자. 상사 A는 사원 B에게 무한 개의 보고서 작성 업무를 지시하였다. 상사 A는 사원 B에게 보고서 1개가 작성 완료될 때마다 해당 보고서를 전달 받고 싶다. (이때 사원 B는 무한 개의 보고서를 1번부터 순차적으로 작성한다.)

💡 Long Polling 방식을 적용해보자!

  1. 상사 A는 오후 1시에 사원 B를 찾아가 작성 완료된 보고서를 요청한다. 그리고 30분동안 그 자리에서 대기한다.
  2. 사원 B는 계속 보고서를 작성했지만 30분 후에도 아직 완료하지 못하여 전달이 불가능하다고 응답한다.
  3. 자리에 돌아온 상사 A는 다시 사원 B를 찾아가 작성 완료된 보고서를 요청한다. 마찬가지로 30분동안 그 자리에서 대기한다.
  4. 2번 반복
  5. 이와 같이 상사 A는 지속적으로 사원 B를 찾아가 작성 완료된 보고서를 요청하면서 그 자리에서 30분 동안 대기하고, 사원 B는 매 30분 뒤 보고서 작성이 완료되지 않았기 때문에 계속해서 전달이 불가능하다고 응답한다.
  6. 상사 A는 오후 4시에 7번째로 사원 B를 찾아가서 역시나 완료된 보고서를 받기 위해 대기한다.
  7. 사원 B는 오후 4시 11분에 보고서 작성을 완료하였고, 이를 바로 기다리고 있던 상사 A에게 전달한다.

polling에 비해 덜하지만 여전히 고생스럽다. polling에 비해 덜하지만, 응답할 준비가 안됐는데 지속적인 HTTP 요청이 발생하는 것은 사실이다.

적합한 서비스(적합한 상황)

  • 실시간 통신이 비교적 중요하지만 잦은 데이터 전달이 없는 서비스
  • 간단한 토이프로젝트

3. SSE(Server Sent Events)

기본적인 개념(정의)

HTTP 통신 기반의 서버에서 클라이언트로의 단방향 통신 기술이다. 클라이언트가 서버로 요청을 보내지 않아도 서버에서 필요할 때마다 클라이언트로 데이터를 보낼 수 있는 기술로, 서버에서 클라이언트로 실시간 스트리밍이 가능한 방법이다. 이를 위해 서버와 클라이언트 간에 단일 단방향 채널을 유지한다.

동작 원리

HTTP 통신 기반이지만, 서버와 클라이언트 간의 단방향 state를 유지해야 한다. 초기에 이 채널(세션)을 생성하고 유지함으로써 서버가 필요할 때마다 클라이언트에 데이터를 보낼 수 있게 된다. 별도의 프로토콜을 사용하지 않고 HTTP 프로토콜만을 사용할 수 있기 때문에 개발이 비교적 수월하다.

그러나 주의할 점이 몇 가지 존재한다.

  • 단방향 연결이기 때문에 SSE를 사용할 경우 클라이언트에서 서버로의 요청은 기존 HTTP 요청을 사용해야 한다. (연결된 세션 사용 불가)
  • 접속에 문제가 발생할 시 자동으로 재연결을 시도하지만, 클라이언트에서 연결을 close 해도 서버가 이를 감지하지 못한다.
  • HTTP 사용 시 브라우저당 6개의 연결까지만 가능하다. (HTTP2 사용 시 100개 연결 가능)
    • 연결 해제를 제대로 안해주면 서버 및 브라우저가 터진다…

예시

회사 상사 A와 사원 B가 있다고 가정하자. 상사 A는 사원 B에게 무한 개의 보고서 작성 업무를 지시하였다. 상사 A는 사원 B에게 보고서 1개가 작성 완료될 때마다 해당 보고서를 전달 받고 싶다. (이때 사원 B는 무한 개의 보고서를 1번부터 순차적으로 작성한다.)

⚠️ SSE 방식부터 다른 방식들의 예시와 약간은 독립적으로 바라볼 필요가 있습니다.

💡 SSE 방식을 적용해보자!

  1. 상사 A와 사원 B는 ‘사원 B가 보고서 작성을 완료할 때마다 상사 A에게 보고서를 전달하기’로 약속한다. 이때 보고서 전달은 서로만이 연결된 사내 메신저를 사용하도록 한다. 해당 사내 메신저는 특이하게 사원 B만이 메시지를 작성하여 보낼 수 있고, 상사 A는 열람만이 가능하다.
  2. 사원 B는 보고서를 작성하고, 작성이 완료된 보고서가 생길 때마다 메신저를 통해 상사 A에게 보고서를 보낸다.
  3. 상사 A는 메신저를 통해 그때그때 작성 완료된 보고서를 전달 받아 확인한다.
  4. 이때, 상사 A가 사원 B에게 전달받은 보고서에 대한 수정을 요청하고자 한다. 이를 위해 상사 A는 직접 사원 B를 찾아가 요청을 한다.

확실히 polling 기반 방식들에 비해 효율적이다. 다만 단방향 통신이기 때문에 만약 클라이언트가 서버로 통신하고자 한다면 HTTP 요청을 보내야 한다. 이는 양방향 연결 통신에 비해 부하가 크다.

적합한 서비스(적합한 상황)

  • 서버에서 클라이언트로의 일방적 데이터 전달이 필요한 상황 (예를 들어 알림 서비스 등)
  • (주문형) 스트리밍 서비스

4. WebSocket

기본적인 개념(정의)

TCP 기반의 WS(WSS) 통신 프로토콜을 이용하는 양방향 통신 기술이다. stateless한 HTTP와 다르게 stateful하며, 클라이언트와 서버가 서로 필요할 때마다 메시지를 주고 받을 수 있다.

socket 통신을 위해서는 클라이언트와 서버가 socket 연결을 맺어야 하는데, 이때 HTTP 통신에서 socket 통신으로 전환되기 위해 HTTP로 HandShake를 하는 과정을 거친다.

동작 원리

연결을 맺는 방식(및 HandShake 과정, 동작 원리 등)에 대해서는 더 자세히 공부할 필요성이 있기 때문에 추후 따로 정리를 할 예정이다.

단순하게 생각하면 다음과 같다.

  1. 클라이언트와 서버에서 각각 socket 세션을 생성한 뒤, 클라이언트에서 서버에 socket connect 요청을 보냄으로써 연결을 맺는다.
  2. 연결을 맺은 후, 클라이언트와 서버는 서로 필요할 때 메시지를 보낼 수 있다.

물론 1번과 2번 사이에 적절한 end-point를 구독해놓는 등의 작업이 필요하다.

WebSocket은 양방향 통신이라는 엄청난 장점을 가지지만, 지속적으로 연결이 끊어지지 않게 관리를 해주어야 하며, 서버에서 연결된 클라이언트 만큼의 세션을 유지해야 한다는 문제가 있다. 또한, 클라이언트단에서 일방적으로 연결을 끊을 경우, 서버에서도 이를 감지하여 해당 세션을 제거해야 메모리 누수가 발생하지 않는다. 이와 같이 안정적인 socket 통신을 위해서는 고려해주어야 할 부분이 많다.

예시

회사 상사 A와 사원 B가 있다고 가정하자. 상사 A는 사원 B에게 무한 개의 보고서 작성 업무를 지시하였다. 상사 A는 사원 B에게 보고서 1개가 작성 완료될 때마다 해당 보고서를 전달 받고 싶다. (이때 사원 B는 무한 개의 보고서를 1번부터 순차적으로 작성한다.)

⚠️ WebSocket은 다른 방식들의 예시와 약간은 독립적으로 바라볼 필요가 있습니다.

💡 WebSocket 방식을 적용해보자!

  1. 상사 A와 사원 B는 ‘사원 B가 보고서 작성을 완료할 때마다 상사 A에게 보고서를 전달하기’로 약속한다. 이때 보고서 전달은 서로만이 연결된 사내 메신저를 사용하도록 한다.
  2. 사원 B는 보고서를 작성하고, 작성이 완료된 보고서가 생길 때마다 메신저를 통해 상사 A에게 보고서를 보낸다.
  3. 상사 A는 메신저를 통해 그때그때 작성 완료된 보고서를 전달 받아 확인한다.
  4. 이때, 상사 A가 사원 B에게 전달받은 보고서에 대한 수정을 요청하고자 한다면 사내 메신저를 통해 요청을 할 수 있다.

양방향 소통에서는 확실히 polling 기반 방식이나 SSE에 비해 효율적이다. 다만 HTTP 프로토콜과 WS 프로토콜을 모두 사용해야 하므로, 두 프로토콜을 고려하여 개발 환경을 구축해야 한다.

적합한 서비스(적합한 상황)

  • 서버와 클라이언트의 양방향 데이터 전달이 잦고, 중요하게 필요한 상황 (예를 들어 채팅 등)
  • socket 통신을 위한 안정적인 서버 구축이 가능한 상황
  • (실시간) 스트리밍 서비스

5. P2P(Peer-To-Peer)

기본적인 개념(정의)

Peer-To-Peer의 약어로, 중앙 서버 없이 클라이언트들이 직접적으로 연결되어 통신하는 기술이다. 즉, 각 Peer(브라우저)들은 중앙 서버의 개입 없이 서로 클라이언트와 서버 역할을 하며 네트워크에서 동등한 권한을 가지게 된다.

동작 원리

P2P 통신을 위해서는 각 클라이언트가 직접 연결되어야 한다. 이러한 연결을 맺기 위해서는 각 클라이언트가 본인의 Public IP, Port 번호 등 정보를 얻어 서로 주고 받아야 한다. 이러한 정보를 클라이언트들이 서로 주고 받기 위해서는 중앙 서버를 이용해야 한다. 즉, 초기 클라이언트간의 연결을 위해서 중앙 서버를 통해 서로의 정보를 주고 받아야 하고, 이를 통해 클라이언트간의 연결이 성립되면 그 이후로는 서버의 도움 없이 서로 데이터를 주고 받을 수 있게 된다.

가장 대표적으로 P2P통신이 가능하도록 제공하는 API로는 WebRTC가 있다.

적합한 서비스(적합한 상황)

  • 실시간 통신이 메인 기능인 서비스 (매우 높은 실시간성이 요구되는 서비스)
  • 1:1 대상 서비스
  • 미디어 스트리밍 서비스

NEXT and BASE

  • HTTP vs Socket (Socket 딥 다이브)
  • Socket 실습(native, 기타 라이브러리)
  • SSE 딥 다이브
  • P2P 딥 다이브
profile
Choi Jimin
다음 포스트

[WebRTC] OpenVidu 분석

0개의 댓글

관련 채용 정보