SSE(Server-Sent Events)

HTTP에서는 데이터를 가져올 때 기본적으로 Request-Response 중심으로 진행됨.
서버에서 변경된 데이터를 가져오기 위한 기존 방법은?

Pooling: 클라이언트가 서버에 데이터를 반복적으로 요청.
Long pooling: pooling의 변형. 서버는 새 데이터를 사용할 수 있을 때까지 응답 보류.
Websocket: 클라이언트와 서버 간 양방향 저지연 통신 채널 생성. HTTP를 사용하여 연결한 뒤 Websocket 프로토콜을 사용할 수 있는 독립 실행형 TCP 연결로 업그레이드.

SSE는 이러한 방식들의 대안으로, 서버의 데이터를 실시간으로, 지속적으로 Streaming하는 기술.

동작 원리

일반적인 HTTP는 TCP를 기반으로 1회성으로 데이터를 주고받은 뒤 연결을 종료하지만, 연결 상태를 유지하고 계속해서 데이터를 보내는 경우도 있음.

많은 양의 데이터를 보내야 하는 파일 전송 등.

첫 연결 시 데이터를 주고 받고, 이후 연결된 상태를 유지한 채 서버가 일방적으로 데이터 전송.

서버에서 첫 request에 대한 응답 시 다음과 같이 헤더를 보내야 함.

Content-Type: text/event-stream		// text 형태의 event-stream을 전송할 것임.
Cache-Control: no-cache				// 새로운 데이터를 받기 위함이므로 캐시 필요 없음.
Connection: keep-alive				// connection을 계속 유지해야 함.

keep-alive

HTTP/1.1부터 지원해주며, Handshake를 생략하고 이미 연결되어 있는 TCP 연결을 재사용.
연결된 Socket에 I/O Access가 마지막으로 종료된 시점부터 정의된 시간까지 Access가 없더라도 세션 유지.

정의된 시간 내에 Access가 이루어진다면 연결 상태 계속 유지.

정적 자원으로만 구성된 웹 서버에 keep-alive를 사용할 경우 약 50%의 성능 향상 기대.

Websocket vs SSE

	Websocket	Server-Send Events
통신 방향	양방향	서버 -> 클라이언트 일방향
실시간성	완전히 실시간	비교적 실시간
데이터 형태	Binary, UTF-8	UTF-8
자동 재접속	X	일정 시간마다 재시도(Default 3초)
최대 동시 접속 수	서버 셋업에 따라 다름	브라우저 당 6개 혹은 100개
배터리 소모량	큼	작음
프로토콜	Websocket	HTTP
Firewall 친화적	X	O

통신 방향

Websocket은 양방향 통신이 가능한 반면 SSE는 일방향 통신만 가능하므로, 양방향 통신이 필요하다면 websocket을 사용해야 함.

실시간성

Websocket이 더욱 정밀한 실시간성을 지원하므로 실시간이 매우 중요한 게임 등의 어플리케이션은 websocket을 사용하는 게 나을 수 있음.

최대 동시 접속 수

HTTP/2 이전: 브라우저 당 6개까지만 허용.

즉 Tab을 6개 이상 열면 동작하지 않을 수 있음.

HTTP/2 이후: 서버와 negotiate 가능.(Default 100)

배터리 및 데이터 사용량

Websocket은 계속해서 handshake를 하지만 SSE는 한 번 열어두고 계속 기다리므로 websocket의 부하가 더 큼.

프로토콜

Websocket은 HTTP 위에서 작동하지 않으므로 HTTP의 여러 이점을 얻을 수 없음.

HTTP 압축을 지원하지 않음.
HTTP/2 멀티플렉싱을 지원하지 않음.
- 동일한 호스트에 대한 여러 요청/응답들이 동일한 TCP 연결을 공유.
Websocket을 지원하지 않는 프록시에서 문제가 발생할 수 있음.
Cross-Site Websocket Hijacking으로부터 보호되지 않음.
- Origin 헤더 확인 및 승인되지 않은 도메인으로부터의 연결 차단을 직접 수행해야 함.

반면 SSE의 경우 HTTP를 통해 전송되므로 특별한 프로토콜이나 서버 구현이 필요하지 않음.