이번에 웹소켓에 대해서 공부하면서 HTTP/2.0에서 SSE 방식으로도 충분히 효율적인 실시간 채팅을 구현할 수 있음을 알게 됐다.
여기서는 HTTP의 Keep-alive를 통해서 연결을 계속 유지하는 것을 전제로 두고 내용을 작성한다.
HTTP2는 이제 웹소켓을 대체할 수 있다.
이제 HTTP2는 양방향 스트리밍을 지원한다. 다중화(multiplexing)기능도 내장돼 있어 여러 스트림을 하나로 연결하고, 흐름제어도 가능해 스트림의 우선순위를 지정할 수 있다.
이런 측면에서 웹소켓과 큰 차이가 없다고 볼 수 있다.
바이너리 데이터는 여전히 웹소켓이다.
서버에서 클라이언트로 바이너리 데이터(jpg,오디오 등등)을 보낼 때는 여전히 웹소켓이 필요하다. HTTP/2에서도 보낼수는 있지만, JS에서 이를 화면으로 보여주지 못한다.오디오나 비디오 프레임을 보낼 때는 웹소켓이 필요하다.
SSE를 사용해서 클라이언트로 메시지를 보낼 수 있다.
Server-Sent Events 를 이용하면 서버에서 클라이언트로 메시지를 푸시하고, 클라이언트는 Fetch api를 통해서 메시지를 보낼 수 있다.
HTTP/2를 지원하는 브라우저는 TCP연결 하나만을 갖고서 메시지를 모두 전송한다. 이때, 웹소켓보다 효율적일 수 있는데 그 이유는 페이지에서 진행되는 다른 요청들까지 이 TCP연결로 요청-응답을 처리할 수 있어서다. 여러 스트림이 필요하면 여러 EventSource를 열면 된다. 자동으로 다중화된다.
SSE는 리소스가 더 효율적이고 웹소켓 핸드셰이크보다 초기 지연이 적으며, HTTP/1.1에서도 잘 작동한다는 특성도 있다.
내용을 정리해보면
- 텍스트 기반 실시간 애플리케이션(예: 채팅)의 경우 HTTP/2와 SSE+Fetch 조합이 효과적일 수 있다.
- 바이너리 데이터 스트리밍, 서버 주도 푸시, 그리고 특정 유형의 실시간 애플리케이션에서는 웹소켓이 여전히 더 적합할 수 있다.
다른 의견도 있다.
1) 웹소켓의 PUSH는 특정 상황에서 무시될 수 있으며
2) HTTP/2 연결은 일정 시간 후 닫힐 수 있다.
여기에 대해서
1) 웹소켓도 영원히 열려 있지 않고.
2) 보안과 서버 무결성 측면에서 HTTP/2가 웹소켓보다 더 좋다.
이런저런 논쟁들이 오가고 있는 걸 확인했다.
굉장히 딥한 내용들이고 이해하기 쉽지 않았는데
채팅 메시지를 꼭 웹소켓으로 하지는 않고 SSE를 활용할 수도 있다는 걸 배우게 됐다.
참고자료
