Skip to content

알림 기능 도입을 위한 HTTP 통신 비교 및 적합성 평가

orlzlL edited this page Apr 22, 2024 · 1 revision

1. 문제점

특정 사용자와 관련된 이벤트가 발생했을 때, 사용자는 이벤트의 발생 여부를 알지 못한다. 따라서 사용자의 요청(Request)이 없더라도 실시간으로 서버의 변경 사항을 알림으로 발송해 주어야 한다.

웹 애플리케이션에서 실시간 업데이트를 구현하는 데 사용되는 HTTP 기반의 통신 방식은 다음의 두 가지가 있다.

  Polling Long-Polling
설명 클라이언트가 일정한 주기로 서버에 업데이트 요청(Request)를 전송한다 클라이언트가 서버에 요청을 보내면 일정 시간 동안 대기하였다가 데이터가 업데이트 되면 서버는 클라이언트에 응답을 반환한다
장점 - 구현이 간단하고 HTTP 호환성이 좋음 실시간 업데이트를 구현할 수 있음
단점 - 실시간 업데이트 제공 불가능함 - 불필요한 요청이 발생하여 서버 리소스를 낭비함 - 일정한 간격으로 요청을 보내기 때문에 트래픽이 증가함 - 클라이언트와 서버 간의 연결을 유지하는 데 시간과 자원을 소비하고 불필요한 트래픽이 발생함.

Long polling은 실시간 업데이트를 제공할 수 있지만 연결 유지로 인한 자원 소모가 발생하고, 일반적인 polling은 단순하고 자원을 덜 사용하지만 실시간 업데이트를 구현하기 어렵다는 문제가 있다.

2. 해결방안

polling 이외에 웹 애플리케이션에서 실시간 통신을 구현하는 데 사용되는 기술을 비교하고 적합성을 판단한다.

  웹 소켓(WebSocket) SSE(Server-Sent Events)
설명 - 클라이언트와 서버 간 양방향으로 데이터를 주고 받음 - 실시간으로 데이터를 전송할 수 있음 - TCP 연결을 통해 지속적인 연결을 유지함 (요청-응답의 사이클이 없음) - 서버 -> 클라이언트 방향의 단방향 통신 - 클라이언트가 서버 쪽으로 특정 이벤트를 구독하면 서버에서 해당 이벤트 발생 시 이벤트를 발송함
장점 - 지속적인 연결로 양방향 통신을 할 수 있음 - 한 번 연결 요청을 보내면 연결이 종료될 때까지 재연결 과정 없이 데이터를 지속적으로 전송 가능
단점 - 지속적인 연결을 유지하기 때문에 많은 클라이언트가 동시에 연결되어 있을 경우 서버 부하가 발생할 수 있음 - 최대 동시 접속 횟수가 제한적임 (HTTP/1.1: 브라우저 당 6개, HTTP/2: 100개) - IE 지원 X

3. 결론

알림 기능의 경우, 채팅처럼 실시간 양방향 통신이 이루어 질 필요 없이 서버에서 클라이언트로 데이터를 전송하면 되므로 서버에서 클라이언트로의 방향을 지원하는 SSE를 적용하기로 하였다.

또한, SSE는 Websocket에 비해 별도의 프로토콜을 사용하지 않고 HTTP 프로토콜만으로 사용이 가능하므로 가볍게 사용할 수 있다.


Clone this wiki locally