REST API vs WebSocket 차이점 정리 feat.Polling, LongPolling, Streaming, SSE

REST API, WebSocket

프로젝트에 채팅기능을 만들려고한다.
WebSocket을 사용하여 실시간 통신을 하지만
WebSocket 이전의 양방향 통신 Rest 방법도 함께 정리해보려고 한다.
 
Rest는 일반적으로 요청을 하고 서버에서 응답받는 방식이다.
 
WebSocket을 많이 들어보고 알고는있지만 REST API와는 어떤것들이 다를까?
 
가장 큰 차이는 접속을 유지하고 있는지의 차이가 있다.
REST 방식은 요청을 하고 응답을 받는다.
그러나 WebSocket은 한번 요청을 하게되면 그 뒤로 계속해서 업데이트 해주는 방식의 API이다. 구독형 API라고도 한다.
 
배달 어플을 생각해보자.
고객과 배달기사는 서로의 위치를 알려면?
REST 고객 -> 서버에 배달기사의 위치를 요청하고 서버에서 배달기사의 위치를 받아서 받아볼 수 있다. 
WebSocket 고객 -> 고객과 서버가 연결, 배달기사와 서버가 연결 되어있다. 배달기사는 위치가 바뀔때마다 고객에게 바뀐 위치를 계속해서 정보가 갈 수 있게 연결되어있다. 즉 양방향으로 서버가 연결되어 있다.

---

REST API

- REST API는 요청을 보내고 받아와야 한다.
- REST API를 사용해서 WebSocket처럼 실시간 요청을 구현할 수 있기도 하다.
그 방법중에서는 Pilling, LongPolling, Streaming 등의 방식등이 있다. 이 방법을 먼저 알아보고 WebSocket에 대해서 알아보자.
 

Polling

- 클라이언트가 일정한 간격으로 서버에 요청을 보내서 결과를 전달받는 방식
- 구현이 쉬운 장점을 가지고 있지만 서버의 상태가 변하지 않았을때도 계속 요청을 보내고 받아와야 하기 때문에
필요없는 요청이 많아지며, 요청 간격을 정해야한다.

setInterval(() => {
	fetch("https://test.com“)
}, 1000)

- 폴링 주기가 짧으면 서버의 성능에 부담
- 주기가 길면 실시간성이 좋지 않음
- 서버에서 바뀐 데이터가 없어도 계속 요청을 해야하고 결과를 받아야함
 
 

LongPilling

- Polling의 단점으로 인해 새롭게 고안해 낸 방식
- Polling처럼 계속 요청을 보내지만 주기적으로 요청을 보내는게 아닌 요청을 보내면 서버가 대기를 하고 있다가 이벤트, 타임아웃이 발생한 후 응답을 해준다.
- 서버의 상태가 변화가 많이 없다면? Polling방식 보다 서버의 부담이 줄어들게 된다.
- 이러한 특징으로 서버의 상태 변화가 자주 발생하지 않는 서비스라면 적합할 수 있다.
 
 

Streaming

- 클라이언트에서 서버에 요청을 보내고 끊기지 않는 연결상태에서 계속 데이터를 수신한다.
- 양방향 소통보단 서버에서 계속 요청을 받는것에 더 유용하다.
- 그러나 서버 및 클라이언트 간의 연결을 유지하는 것이 필요하므로 리소스 소비 문제가 발생할 수 있다.
- 주로 비디오, 오디오 등과 같은 멀티미디어 데이터를 실시간으로 전송하는데 사용된다.
 
 
Polling, LongPilling, Stremaing 의 공통점
- HTTP 프로토콜 : 모든 접근 방식이 HTTP 프로토콜 기반으로 작동한다.
- HTTP 요청과 응답: 클라이언트가 서버에 데이터 요청을 하고 서버는 해당 데이터를 응답으로 반환한다.
- Header 데이터 부담: HTTP 요청와 응답에는 Header가 포함되며, 이는 요청 및 응답의 메타데이터를 포함한다. Header는 데이터 전송에 추가 부담을 줄 수 있다. 따라서 많은 요청 및 응답 교환이 발생할 때 이로 인한 오버헤드가 발생할 수 있다.
 
 

SSE

- HTTP기반 프로토콜: 웹 브라우저에 내장된 기능으로 서버로부터 데이터를 수신한다.
- 클라이언트가 서버로 요청을 보내는것이 아니라 서버가 클라이언트로 데이터를 주기적으로 보내는 방식이다. 이로 인해 서버에서 새로운 정보가 있을때마다 데이터를 보낼 수 있다.
- EventStream 형식 : MIME타입이 "text/event-stream"으로 설정되며, 연속적인 이벤트들을 스트림으로 전송하는 방식이다.
- 양방향 통신은 아니지만 서버로부터 연결을 계속 유지되며 서버는 주기적으로 데이터를 보내며 연결을 유지한다.
- 간단한 실시간 업데이트 또는 알림에 필요한 경우에 사용된다.

---

WebSocket

- 처음 접속 확립(Handshake)을 위해서 HTTP 프로토콜을 사용한다. 그 이후부터는 독립적인 프로토콜 ws를 사용하게 된다.

* HandShake : 처음 HTTP 프로토콜을 사용하여 클라이언트와 서버 사이의 초기 연결 설정
* WS 프로토콜(WebSocket 프로토콜) : 양방향 통신을 지원하는 프로토콜으로 한번 연결 설정 이후 별도의 헤더 정보 없이 데이터만 주고 받는다.
 

- HTTP 요청은 응답이 온 후 연결이 끊기게 되지만 WebSocket은 Handshake가 완료되고 임의로 연결을 끊기 전까지는 계속 연결되어 있다.
- 클라이언트와 서버는 양방향으로 데이터를 주고 받을 수 있다.
- 주로 실시간 대화, 실시간 게임, 주식 시장 데이터 스트리밍 등과 같은 실시간 양방향 통신에 사용된다.
- 대용량 트래픽에서는 서버가 클라이언트 수만큼의 연결을 유지해야한다는 부담이 있다.