Web application에서 Server to Client통신

HTTP 는 단방향인데 서버가 클라이언트에 먼저 알려야 하는 상황을 어떻게 푸는지, polling 부터 WebSocket 까지 방식별 원리와 장단점을 정리한 글이다. 마지막에 "웬만하면 WebSocket, 다만 통신이 드물면 polling" 이라는 선택 기준까지 제시한다.

핵심 포인트

필요한 상황의 예로 동일 사용자가 로그인했을 때 기존 클라이언트를 로그아웃시키는 경우, 비동기 작업이 끝났음을 알리는 경우를 든다.
polling 은 server push 가 아니라 client pull 이다. 일정 간격으로 요청해 이벤트 발생 여부를 확인하며, 구현이 쉬운 대신 매번 연결을 맺고 끊어야 한다.
comet 은 브라우저가 명시적으로 요청하지 않아도 데이터를 푸시할 수 있게 하는 모델이며, 구현 기술은 스트리밍 계열과 long polling 으로 나뉜다.
SSE 는 comet 을 표준화한 것으로 HTTP 기반이라 별도 라이브러리나 프로토콜이 필요 없지만 서버→클라이언트 단방향이다.
WebSocket 은 하나의 TCP 연결에서 full-duplex 통신을 하며, dataframe 헤더가 HTTP 헤더보다 작아 데이터를 주고받기에 유리하다.

상세 정리

hidden iframe 방식: script 태그는 응답이 완료돼야 실행되지만 iframe 은 완료 전에도 JavaScript 가 실행된다. 이 성질로 데이터를 스트리밍한다.
hidden iframe 의 장단점: 전송에 헤더가 붙지 않고 호환 범위가 넓지만, 에러 처리가 안 되고 브라우저 메모리에 데이터가 계속 쌓인다.
XMLHttpRequest 방식: `readyState` 로 진행 상태를 본다. 3 이면 새 응답이 왔다는 뜻이고 4 면 요청이 끝났다는 뜻이다.
XHR 의 장단점: 에러 처리가 되고 헤더에도 접근할 수 있지만, 일부 브라우저는 보안상 readyState 가 3 일 때 응답 결과 접근을 막는다.
long polling: 요청을 받아 두고 이벤트가 생길 때까지 응답을 미뤘다가 발생 순간 데이터와 함께 응답한다. 일반 polling 보다 서버 부하가 커질 수 있다.
SSE 동작: 클라이언트가 연결을 요청하면 서버가 전용 MIME type 으로 응답하고, 클라이언트는 연결을 끊지 않고 다음 응답을 기다린다.
WebSocket 동작: 최초 handshake 이후에는 서버든 클라이언트든 언제든 메시지를 보낼 수 있다.
호환성: IE10 이전 버전은 WebSocket 을 지원하지 않는데 socket.io 라이브러리가 이를 해결해 준다고 짚는다.
결론의 기준: 대체로 WebSocket 이면 되지만, 예컨대 1시간에 한 번 갱신이면 되는 경우에는 연결을 유지하는 비용이 새 연결을 만드는 비용보다 크므로 단순한 polling 이 낫다.