서론

SSE에서 최대 동시 접속 수가 브라우저당 6개까지 가능하다는
사실을 알지 못한 채, 애꿏은 코드 수정을 하며 수차례의 삽질을 했습니다.
그에 관한 기록은 여기 글에 써놨으니 확인해보실 분은 확인해보세요.
삽질Log

개발하는 과정은 선택의 연속입니다. 실시간 통신을 구현하기 위해
어떤 기술을 선택해야할지 고민의 연속이었습니다.

상황에 적절한 기술이 무엇인지 고민하는 과정에서 공부한 내용을
정리하며 두개의 기술들을 체득하고자 합니다.

본론

	WebSocket	SSE
브라우저 지원	대부분 브라우저에서 지원	대부분 모던 브라우저 지원(polyfills 가능)
통신 방향	양방향	일방향
실시간	YES	YES
데이터 형태	Binary, UTF-8	UTF-8
자동 재접속	내장되지 않음	내장
최대 동시 접속	서버 설정	HTTP를 통해서 할 때는 브라우저당 6개 까지 가능 / HTTP2로는 100개가 기본
프로토콜	WebSocket	HTTP
배터리 소모	큼	작음
Firewall 친화적	NO	YES

결론

웹소켓은 양방향 통신을 지원하며 클라이언트와 서버 간의 실시간 데이터 교환을 위해 설계되었습니다. 따라서, REST API와는 다른 프로토콜과 인터페이스를 사용하여 통신해야 합니다.

반면에 SSE(Server-Sent Events)는 REST API와 웹소켓 간의 중간 지점에 위치한 다른 종류의 API입니다. SSE는 웹소켓과 유사한 실시간 통신을 제공하지만, 웹소켓과는 다른 방식으로 동작합니다.

SSE는 클라이언트가 서버로부터 단방향으로
이벤트 스트림을 수신하는 방식으로 작동합니다.

클라이언트는 HTTP 연결을 유지한 상태에서
서버로부터 이벤트를 받아들이고 처리할 수 있습니다.

이벤트는 서버에서 비동기적으로 전송되며,
클라이언트는 이를 수신하여 이벤트에 따라
UI를 업데이트하거나 원하는 작업을 수행할 수 있습니다.

따라서, SSE는 웹소켓처럼 양방향 통신을 지원하지는 않지만,
실시간 업데이트를 필요로 하는 경우
REST API에 비해 더 나은 대안이 될 수 있습니다.

SSE는 간단한 구현과 서버의 부담을 줄일 수 있는 장점을 가지고 있으며, 특히 단방향 통신이면서도 실시간 업데이트가 필요한 경우에 유용합니다.

결론적으로, REST API는 단방향 요청-응답 형태의 통신에 적합하고,
웹소켓은 실시간 양방향 통신이 필요한 경우에 사용될 수 있습니다.
SSE는 실시간 업데이트가 필요하지만 양방향 통신이 필요하지 않은 경우에 유용한 대안이 될 수 있습니다.