Intro 🐈

오늘은 Server Push와 Server Push의 구현 기술들인 Polling, Long Polling, Streaming, SSE(Server Side Event), WebSocket에 대해 알아보는 시간을 가지도록 하겠습니다.

📍 Server Push

HTTP/1.xx대에서 HTTP/2로 버전 업그레드가 되면서 HTTP/2의 주요 특징 중 하나로 Server Push 기능이 추가 되었습니다.

기존 통신 방식

HTTP 통신 방식은 기본적으로 클라이언트가 요청을 보내면 서버가 실행되는 선 클라이언트 요청 후 서버 실행의 동작 방식을 가지고 있습니다. 클라이언트 요청 없이는 서버를 실행할 수 없다는 것을 뜻입니다. 이러한 제약을 없애고 능동적으로 서버가 클라이언트에게 데이터를 보낼 수 있도록 하고자 HTTP/2부터 Server Push가 추가되었습니다.

Server Push

클라이언트 요청이 없어도 서버가 클라이언트로 데이터를 전달할 수 있는 방식 입니다. 서버가 자체적으로 클라이언트에게 데이터를 보낼 수 있게 되면서 푸쉬 알림이나 채팅 등의 기능도 가능해지게 되었습니다.

---

📍 Server Push 구현 기술

Server Push는 클라이언트 요청 없이 서버에서 클라이언트로 데이터를 보내는 방식이고, 이를 구현하고자 여러 기술들이 존재합니다.

📌 Polling

단방향 통신 : client ➡️ server

주기적으로 서버에 요청을 보내어 서버에 event가 발생했는지 확인 후, 발생하였다면 http 연결 후 통신하는 방식
서버가 클라이언트로 요청을 보낼 때마다 HTTP 연결 필요

Polling은 클라이언트가 서버로 요청을 보내야만 응답하는 단방향 통신이나 주기적으로 서버에 요청을 보내어 마치 서버가 발생한 event를 알아차리고 클라이언트에게 주도적으로 요청을 보내는 것처럼 보이도록 합니다. 그러나 실제로는 클라이언트에 의해 움직이다 보니 여러 한계들이 있습니다.

👎 주기적으로 요청을 계속 보내더라도 그 요청 사이 텀 존재(실시간 ❎)
👎 그렇다고 요청 주기를 짧게 하면 부하가 더 커짐
👎 클라이언트에 요청을 보낼 때 마다 연결 비용이 발생 (실시간 ❎) ➡️ 이를 해결하고자 Long Polling 사용

📌 Long Polling

Polling 방식에서 HTTP 연결이 되어있는 텀을 더 길게 가져서 요청 보낼 때마다 연결하는 것을 방지

👎 높은 HTTP 연결 비용
(Polling 방식보다는 연결이 길지만 SSE나 WebSocket에 비하면 HTTP 연결이 지속되는 시간이 짧기 때문에 지속 시간이 끝나면 또 다시 HTTP 연결을 해주어야 합니다.)

📌 Streaming

단방향 통신 : client ➡️ server

한 번 요청이 들어온 경우, 응답을 한 후에도 연결을 끊지 않고 다음에 발생하는 이벤트에서도 해당 응답을 사용하는 방식

👍 실시간 전송 가능
👎 계속 연결되어 있어야 하기 때문에 서버 리소스를 많이 차지

📌 SSE ( Server Side Event )

단방향 통신 : server ➡️ client

서버에서 event 발생 시, 서버가 이를 인지하고 클라이언트로 데이터 전송하는 방식

👎 클라이언트에서 서버로 통신이 불가능
👎 오래 연결되어 있는 경우 부하 발생
(그에 비해 WebSocket은 오래 연결되어 있어도 효율적인 트래픽을 유지)

📌 WebSocket

양방향 통신 : client ↔️ server

HTTP 연결 후 이를 WebSocket Protocol(ws/wss)로 변환한 뒤,
event 발생 시 서버가 이를 인지해 데이터 통신을 하는 방식

👍 빠른 통신
👍 SSE보다 효율적인 트래픽
👎 WebSocket 프로토콜을 사용해야하므로 구현 난이도가 높음

---

[참고자료1]
[참고자료2]