Polling, Long Polling, Socket, SSE

웹 어플리케이션은 클라이언트가 서버에 데이터를 요청하는 클라이언트 서버 모델을 중심으로 발전해왔다. 그렇기에 서버가 클라이언트의 요청 없이 독립적으로 데이터를 보내고 받는 매카니즘은 없었다. 하지만 시대는 계속해서 변화하고 다양한 상황에 대응하기 위한 다양한 통신 방법의 필요성이 증가했다. 이에 아래와 같은 네트워크 기술들이 등장하기 시작했다.

HTTP의 비연결성 특징을 해결하기 위한 기술

• Polling, Long Polling, WebSocket, SSE

Polling, Long Polling, Socket, SSE 비교하기

Polling

HTTP Long Polling 기술은 서버가 사용자에게 가능한 빠르게 정보를 전달하는데 사용되는 기술이다. 그러니 서버는 클라이언트가 요청을 보낼 때까지 기다릴 필요가 없어졌다.

Long Polling 방식에서 서버는 사용자에게서 요청을 한번 받고 연결을 끊는 것이 아니라, 어떤 메시지든 유효하다면 혹은 타임아웃되지 않는 이상 응답을 보낸다.

• 클라이언트가 http request 를 서버로 계속 전달하여 이벤트 내용을 전달받는 방식
• 클라이언트의 지속적인 요청을 전송하여 클라이언트가 많아지면 서버 부담이 급증
• http request connection 을 맺고 끊는 것 자체가 부담스러운 방식이다.
• 실시간에 가까운 빠른 응답을 기대할 수 없다.
• http 오버헤드 발생
• 일정한 간격으로 데이터가 갱신되는 서버에 적합

💡 HTTP OverHead !

• 정보의 신뢰성을 판단하기 위해 보내지는 헤더 정보(전송 데이터와 관련없는 정보)로 인해 발생
• 데이터량과 처리 시간이 급증한 상태

 

클라이언트가 응답을 받으면 즉시 새로운 요청을 서버에게 보내고 클라이언트에게 데이터를 전송할 연결을 지속한다. 이런 과정은 반복되는 것이다. 이렇게 닿음으로 서버는 마치 실시간 전송과 같은 역할을 한다.

Polling 이 이뤄지는 방식

1. 클라이언트는 초기 요청을 전송하고 응답을 기다린다.
2. 서버는 요청을 받고 갱신이 유효할 때까지 어떤 응답이든 지연한다.
3. 유효한 응답데이터가 생성될 때 응답은 클라이언트에게 전해진다.
4. 클라이언트는 응답을 받고 즉시 혹은 일정 간격을 두고 다시 연결을 시도하며 새로운 요청을 만든다.

 

Long Polling

• 서버에서 접속 시간을 길게 하는 방식
• 클라이언트에서 서버로 http request 전송
• 서버 응답 데이터가 없을 시 대기
• 이벤트가 존재하면 response 메시지를 전달한 후 연결 해제
• 클라이언트에서 다시 http request 를 전송하여 서버의 다음 이벤트 대기
• Polling 에 비해 서버 부담이 줄지만 이벤트 시간 간격이 좁다면 차이가 없다.
• 다수의 클라이언트에게 이벤트가 동시발생할 시 서버 부담 급증
• 서버 구현을 위해 무한 iframe 에 스크립트 태그 같은 걸 추가해야 한다.

Long Polling 방식의 장점

• 구현이 쉽고 작은 규모의 프로젝트에 적합
• 거의 보편적으로 지원됨

단점

가장 큰 단점은 보통 측정할 수 없다는 것이다.

• 매 시간마다 서버에 부담이 될 수 있는 연결을 생성한다.
• 신뢰할 수 있는 메시지를 요청하는 것은 여러 요청에 문제될 수 있다.
• 서버가 새로운 요청을 기다릴 수록 대기 시간이 증가한다.

webSocket

• 양방향 채널을 이용한 양방향 통신
• WS 프로토콜을 통해 웹소켓 포트에 연결되어 있는 모든 클라이언트에게 이벤트 방식으로 응답
• 최초 접속이 http request 를 통한 handshaking 과정을 통해 이뤄진다.
  • 80, 433 포트로 접속
  • 방화벽을 열지 않고도 CORS적용, 인증 등 동일하게 처리 가능
• Websocket 프로토콜을 위한 전이중 연결과 웹소켓 서버 필요

Socket.io

• node js 기반으로 만들어진 기술
• 자체 스펙으로 만들어진 Socket.io 서버를 만든다.
• Socket.io 클라이언트와 브라우저에 구애받지 않고 실시간 통신 가능

 

웹소켓은 단일 TCP 연결에서도 양방향 연결 채널을 만들어준다. 이 연결은 클라이언트와 서버 사이의 지속적인 연결이고, 서버와 클라이언트는 언제든 데이터를 전송을 시작하기 위해 웹소켓을 사용한다.

클라이언트는 웹소켓 핸드쉐이크 과정으로 연결을 생성한다. 그러고 서버와 클라이언트는 언제든 양방향으로 데이터를 교환한다. 웹소켓 프로토콜은 클라이언트와 서버 사이의 커뮤니케이션을 낮은 부하로 이뤄낼 수 있으며 서버로부터, 서버로 실시간 데이터를 가능케 한다.

이는 서버가 요청을 받지 않고 클라이언트에게 콘텐츠를 보낼 수 있는 표준화된 방법을 제공하고 연결을 열어둔 상태에서 메시지를 앞뒤로 전달할 수 있도록 한다.

웹소켓은 연결이 유지되는 동안 클라이언트에게 묻거나 요청하는 과정 없이 서버가 데이터를 전송할 수 있는 기본이 되는 방법을 제공할 수 있다.

WebSocket 동작 방식

1. 클라이언트는 요청을 전송하여 웹소켓 핸드쉐이크 과정을 초기화한다.
2. 해당 요청은 HTTP Upgrade 헤더를 포함하며 이것은 웹소켓 프로토콜로 전환을 요청하는 내용이다. ws://
3. 서버는 클라이언트에게 응답을 보내서 웹소켓 핸드쉐이크 요청을 허락한다.
4. 웹소켓 연결은 클라이언트가 핸드 쉐이크 응답을 성공적으로 받은 후 한번만 열린다.
5. 이제 클라이언트와 서버는 양 방향에서 데이터를 보내는데 실시간 커뮤니케이션으로 이뤄진다.
6. 해당 연결은 서버나 클라이언트가 연결 해지를 결정하는 순간 닫힌다.

웹소켓 장점

• 양방향 비동기 메시지 처리
• 서버와 클라이언트 양측에 부하가 적다.

웹소켓 단점

• 닫힌 연결은 자동으로 복구되지 않는다.
• 오래된 브라우저는 웹소켓을 지원하지 않는다.

 

SSE(Server-Sent-Events)

• 서버 데이터를 실시간, 지속적으로 스트리밍하는 기술
• html 5 표준, 웹 소켓 역할
• 서버에서 클라이언트로 데이터가 흐르는 단방향
  • ajax 로 쉽게 이용 가능
• 재접속의 저수준 처리 자동 지원
• 서버에서 클라이언트로 실시간 이벤트를 전달하는 웹 기술
• 단방향 통신
• 클라이언트의 별도 추가 요청 없이 서버에서 업데이트를 스트리밍 할 수 있다.

Server-Sent Events (SSE)

Server-sent Events (SSE) 는 장시간 클라이언트와 서버가 연결을 수립하는 과정으로 서버는 클라이언트 측으로 사전에 데이터를 전송할 수 있다.

 

단방향이므로 클라이언트가 요청을 전송하면 동일한 연결을 통해 새 요청을 전송할 수 없이 응답만 받을 수 있습니다.

동작과정

1. 클라이언트가 서버에게 요청을 전송한다
2. 서버와 클라이언트 사이 연결이 수립되고 개방된다.
3. 서버는 새로운 데이터가 유효할 때 반응이나 이벤트를 사용자에게 전송한다.

SSE 이점

• 클라이언트와 서버 모두에게 구현과 사용이 용이하다.
• 대부분의 브라우저에서 지원된다.
• 방화벽 관련 문제가 없다.
• HTTP를 통해 통신하므로 다른 프로토콜은 불필요하며 구현이 쉽다.
• 네트워크 연결이 끊겼을 때 자동으로 재연결을 시도한다.
• 서버에서 클라이언트로 실시간 데이터 전송한다.
• 폴링 방식의 실시간이라고 보기 어려운 한계를 극복

SSE 단점

• 방향성이 없는 상황에서 제한될 수 있다.
• 활성화된 연결의 최대 개수에 제한이 있다.
• 2진 데이터를 지원하지 않는다.
• GET 메소드만 지원하며 파라미터를 보내는 데 한계가 있다.
• 단방향 통신이며 한번 보내면 취소가 불가능하다.
• 클라이언트가 페이지를 닫아도 서버에서 감지하기 어렵다.
• 지속적인 연결을 유지해야 하므로 많은 클라이언트가 동시 연결을 유지할 경우 서버 부담이 커진다.