SSE(Server Sent Event) | Polling과 SSE

SSE(Server Sent Event)

---

long-lived HTTP

• 서버에서 클라이언트에게 실시간으로 데이터를 전송하는 기술 (단방향)
• HTTP connection을 길게 유지하면서, 서버에서 클라이언트에게 데이터를 전송
• 서버에서 데이터 변경이 있을때 클라이언트에게 실시간으로 알려주기 위해 주로 사용된다.
• SSE 기술이 등장하기 전에는 Client에서 서버의 데이터 변경을 확인하기 위해 주로 polling 방식을 사용했다.

---

polling 방식의 종류

Short Polling

클라이언트에서 주기적으로 API를 호출해 서버의 데이터 변경사항을 확인하는 기법이다.

• 전통적인 AJAX 애플리케이션에서 사용되던 방식
• 일정 간격마다 요청이 이뤄지며, 클라이언트는 새로운 데이터가 있든 없든 응답을 받고 일정 시간 기다렸다가 다음 요청을 날리고 응답받고, 또 기다렸다가 다음 요청을 날리고 응답받고 … 와 같은 방식으로 동작한다.

 

Short Polling

장점

• Short Polling을 이용해 서버 호출주기를 짧게 가져간다면, 준 실시간으로 서버의 데이터 변경을 알 수 있다.
• 스포츠의 문자 중계 기능과 같이, 새로운 데이터가 일정한 간격으로 생성되는 경우엔 폴링이 효과적일 수 있다. 

 

단점

• 코인 가격 데이터와 같이 데이터가 짧은 간격마다 계속해서 업데이트되는 경우엔 비효율적일 수 있다.
  • 실시간성을 최대화하고자 요청을 보내는 간격을 줄이자니 서버 요청수가 필요이상으로 많아진다. = HTTP overhead가 증가한다.
  • 반대로 서버 부담을 덜고자 간격을 늘리게 되면 실시간성이 떨어지는 문제가 있다.

---

Long Polling (Hanging GET)

Short Polling을 개선한 방법으로 Long Polling 개념이 나왔다.

클라이언트가 요청을 했을때 서버에서 바로 응답하는게 아니라 데이터 변경이 있을때까지 기다렸다가 응답하는 기법이다.

Long Polling

장점

• Short Polling과 비교하면 클라이언트의 요청수가 감소하기 때문에 HTTP overhead는 개선되었다.
• 또한, HTTP 연결 재사용 기능을 활용하여 매 롱 폴링 요청마다 TCP/IP 연결을 새로 맺어야 하는 오버헤드를 줄일 수 있다.
  (이는 Short Polling에도 적용되지만 일반적으로 요청 사이의 간격이 더 짧은 롱 폴링의 경우에 특히 효과를 볼 수 있다.)

단점

• 어쨌든 HTTP 요청을 계속해서 날리는 것이므로 HTTP 헤더에 의한 오버헤드가 존재한다.
  • 데이터가 빈번하게 업데이트되는 상황에선 폴링방식과 별다른 차이가 없다.
  • 데이터 업데이트가 빈번한 경우 클라이언트는 요청 즉시 응답을 받게 되고, 바로 이어서 다시 요청을 보내 응답을 받게 되고, 또 바로 이어서 다시 요청을 보내 응답을 받고 … 와 같은 상황이 발생하기 때문이다.

---

SSE(Server Sent Event)

클라이언트가 서버와 HTTP connection을 맺어두면, 서버에서 데이터의 변화가 있을때마다 응답을 보낸다. 

 

장점

• HTTP connection을 한번만 맺기 때문에 HTTP overhead가 Polling 방식에 비해 월등히 개선된다.
• 사용자 입장에서 잦은 HTTP 요청을 하지 않아도 되기 때문에 응답시간이 더 빨라지고, 디바이스의 배터리 사용률도 줄어들 수 있다.
• SSE는 웹소켓 프로토콜이 제공하는 양방향 통신 기능 대신, SNS 친구들의 상태 정보, 주식 시세, 뉴스 피드와 같이 굳이 클라이언트가 서버로 데이터를 보낼 필요가 없는 경우 적합한 기술이다.

---

SSE 원리

HTTP Connection 유지

 

• HTTP 버전 1 : HTTP 연결을 하나의 트랜젝션이 끝나고 유지할지 말지 Connection 헤더 값을 이용해 설정할 수 있다.
  • HTTP/1.0 : 기본 설정이 트랜젝션이 끝난 후 연결을 끊기 때문에 Connection : keep-alive로 주면된다.
  • HTTP/1.1 : 기본 설정이 트랜젝션이 끝나더라도 연결을 유지하기 때문에 따로 설정할 필요 없다.
• HTTP 버전 2 ~ : 하나의 HTTP Connection에서 여러 HTTP 요청이 동시에 이뤄질 수 있기 때문에 HTTP Connection 관련 설정을 따로 해줄 필요가 없다.

그 외 설정

• HTTP Request 
  • Accept Header : text/event-stream
• HTTP Response
  • Content-Type Header : text/event-stream
  • Cache-Control Header : no-store

SSH Event 포맷

• field와 value로 이루어진다.
  • field 종류: event, data, id, retry
• event는 \n\n으로 구분한다.
• UTF-8로 인코딩되어 있다.

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events#event_stream_format

 

참고

https://hyuk0309.tistory.com/24

SSE(Server Sent Event) 개념 정리

https://jaehyeon48.github.io/network/polling-and-sse/

폴링, 롱폴링, HTTP 스트리밍, SSE

https://isoomni.tistory.com/entry/SERVERHTTP-AJAX-%ED%86%B5%EC%8B%A0-WebSocket-SSE-%ED%8A%B9%EC%A7%95-%EC%9E%A5%EB%8B%A8%EC%A0%90

[SERVER][HTTP, AJAX 통신, WebSocket, SSE] 특징, 장단점