[Network] 실시간 통신을 위한 여러가지 방식들

일반적으로 네트워크 통신은 HTTP를 사용하여 클라이언트에서 요청을 보내면 서버에서 해당 요청에 대한 응답을 전달하는 방식으로 이루어진다. 여기서 중요한 점은, 클라이언트의 요청이 있기 전까지는 서버는 데이터를 전송할 수 없다는 것이다.

 

하지만, 기술이 점점 발전하고 다양한 서비스가 생김에 따라 실시간 네트워크 통신이 필요한 상황이 생기게 되었다. 예를 들어, 채팅 서비스 같이 실시간으로 서버로부터 채팅 데이터를 받아와야 하는 상황에서는 이런 실시간 통신이 매우 중요한 요소이다.

 

이렇게 실시간 통신의 필요성이 증가함에 따라 이를 위한 여러가지 통신 방식이 등장하게 되었다. 이 글에서는 이런 실시간으로 통신할 수 있는 여러가지 방식을 알아보도록 할 것이다.

 

 

Polling & Long Polling

---

실시간성을 보장하기 위해서는 서버에서 데이터에 변화가 생겼을 경우, 클라이언트에 즉시 해당 변화 이벤트가 일어났음을 알려줌과 동시에 변화된 데이터를 응답할 수 있어야 한다.

 

하지만, 일반적인 HTTP 통신의 경우에는 클라이언트가 요청을 보내는 경우에만 서버가 그에 대한 응답을 전달하는 방식을 사용하기 때문에 실시간성을 보장하기 어렵다는 문제가 있다.

 

이런 HTTP 통신의 특성 때문에 초기에는 실시간 통신을 위하여 Polling과 Long Polling이라는 방식이 등장하게 되었다.

 

Polling

일정 주기마다 서버에 API 요청을 보내는 방식이며, 데이터 변경사항의 유무에 관계 없이, 주기적으로 요청과 응답을 반복하게 된다. 예를 들어, 클라이언트에서 서버로 5초마다 한번씩 알림 목록 요청을 보내면 알림이 새로 생겼을 경우에 클라이언트가 해당 변경 사항을 주기적으로 확인할 수 있다.

 

장점

• 기본적인 HTTP 통신을 기반으로 이루어지기 때문에 호환성이 높다.
• 구현이 쉽다.

단점

• 서버에서 이벤트가 발생하지 않아 보낼 데이터가 없다면 불필요한 통신을 주고 받게 된다.
• 요청 주기를 길게 설정할 경우 → 완벽한 실시간성을 보장하기 어렵다.
• 요청 주기를 짧게 설정할 경우 → 어느 정도 실시간성을 보장할 수 있지만, 그만큼 불필요한 네트워크 리소스를 낭비하게 되며, 서버 부하가 증가할 수 있다.

 

Long Polling

기존 Polling 방식에서 서버가 바로 응답을 보내는 것이 아니라 이벤트가 발생했을 경우, 혹은 timeout이 발생할 때까지 기다리다 응답을 보내는 방식이다.

 

클라이언트가 서버로부터 응답을 받은 후에는 다시 서버로 새로운 요청을 보낸다. 만약 변경사항이 없어 timeout이 발생해도 다시 요청한다.

 

장점

• Polling 방식의 단점 중 하나인 서버가 불필요한 응답을 보낼 수 있는 상황을 줄일 수 있다.
• 게다가 클라이언트는 매 요청마다 갱신된 데이터를 응답받기 때문에 Polling 방식보다 더 높은 실시간성을 보장한다.

단점

• 이벤트가 빈번하게 발생하는 상황이라면, 그만큼 통신도 빈번하게 발생하게 되므로 서버 부하 또한 늘어나게 된다.
  • 이는 Polling 방식에서 주기를 짧게 설정할 경우 생기는 단점과 비슷한 현상이다.

 

Polling vs. Long Polling

 

 

더 발전된 방식들

---

Polling과 Long Polling 방식은 네트워크 리소스를 많이 소모하고 완벽한 실시간성을 보장하기에는 부족한 부분이 많다는 문제가 있다. 이후, 이 방식들의 단점을 해결한 여러 실시간 통신 방식들이 등장하게 된다.

 

SSE (Server-Sent Event)

클라이언트에서 구독 요청을 보내면, 서버는 응답 후 바로 연결을 종료하지 않고 연결을 유지한 상태로 이벤트 발생 시 마다 클라이언트로 응답을 보내는 방식이다.

 

HTML5 표준 기술이기 때문에 대부분의 브라우저에서 지원하는 방식이며, 반드시 서버에서 Content-Type 헤더를 text/event-stream으로 지정해서 응답해야 SSE 통신이 이루어진다.

 

장점

• 한번의 HTTP 연결을 지속적으로 유지하기 때문에 네트워크 리소스를 아낄 수 있으며, 높은 실시간성을 보장할 수 있다.
• 중간에 연결 문제가 발생하면 브라우저에서 자동으로 재연결을 지원한다.

단점

• 서버에서 클라이언트로 단방향 전송만 가능하고, 동시에 접속하는 클라이언트의 수가 많을 수록 서버의 처리 부하가 증가할 수 있다는 단점이 있다.

 

WebSocket

위에서 설명한 실시간 통신 방식들은 모두 HTTP를 기반이기 때문에 요청과 응답 시 HTTP 헤더도 함께 전달하여 불필요한 리소스 낭비가 발생한다는 단점이 있다. 이를 해결하기 위해 등장한 방식이 WebSocket이다.

 

WebSocket은 HTML5에서 등장한 클라이언트와 서버의 양방향 통신을 위한 방식으로, HTTP 대신 ws(혹은 wss) 프로토콜을 사용한다.

 

WebSocket 서버와의 연결을 위해서 프로토콜 변경을 위한 HTTP 요청을 보내고 서버에서는 해당 요청에 대한 응답을 하므로써 WebSocket 통신을 위한 준비를 진행하는데, 이를 WebSocket handshake라고 한다. 이후 ws로 프로토콜을 변환하게 되고, 클라이언트와 서버 간 통신이 열려있는 상태로 WebSocket frame을 통해 클라이언트와 서버가 데이터를 주고 받게된다.

 

데이터의 변경사항을 빠르게 확인하고 반영해야 하는 상황(e.g. 채팅, 스트리밍, 문서 동시 편집)에 많이 사용되는 방식이다.

 

장점

• 지속적으로 양방향 통신이 가능하며, 높은 실시간성을 보장한다.

단점

• 지속적으로 연결을 유지해야 하는 부담이 생기고 하나의 WebSocket 서버가 다수의 클라이언트를 제어하기 때문에 서버에 부하가 집중된다는 단점이 있다.

 

Polling vs. SSE vs. WebSocket

 

WebRTC (Web Real-Time Communication)

WebRTC는 WebSocket과 같이 HTML5 표준 기술 중 하나이다.

 

WebSocket이 하나의 서버에서 여러 클라이언트를 제어하는 방식이라면, WebRTC는 각각의 클라이언트를 직접 연결하여 통신을 지원하는 일종의 P2P(Peer to Peer) 방식이다.

장점

• 중간 서버를 거치지 않고 클라이언트끼리 직접 데이터를 주고 받기 때문에 굉장히 빠르다는 특징이 있다. 그래서 영상 스트리밍이나 화상 채팅 등 실시간 통신이 매우 중요시 여겨지는 서비스에 적합한 방식이다.

단점

• P2P 방식으로 통신하기 때문에 사용자가 많아질 수록 속도가 느려질 수 있다.

 

 

참고

---

클라이언트와 서버간 실시간 통신을 하는 방법

[백엔드 스프링부트] 알림 기능은 어떻게 구현하는게 좋을까?