서버 진행 알림을 브라우저로 보내려 합니다. SSE와 WebSocket을 어떤 통신 요구로 선택하나요?
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
서버에서 클라이언트로 주로 텍스트 이벤트를 보내면 SSE가 단순할 수 있고 양방향 빈번한 메시지나 바이너리 교환에는 WebSocket이 적합할 수 있습니다. 연결 방식보다 재연결·순서·백프레셔·프록시 지원을 함께 봅니다.
동작 원리와 전제
SSE는 HTTP 응답 스트림으로 이벤트를 전달하며 브라우저 EventSource의 재연결 동작을 활용할 수 있습니다. 이벤트 ID와 재생은 서버가 보관·구현해야 하며 자동 exactly-once가 아닙니다. WebSocket도 연결 복구와 메시지 재생을 앱이 설계해야 합니다.
선택과 실패 처리
SSE의 브라우저 인증 헤더 제약·프록시 버퍼링·연결 한도와 WebSocket의 upgrade·idle timeout·서버 자원 점유를 비교합니다. 느린 클라이언트에 무한히 버퍼링하지 않고 위치 상태는 합치거나 이벤트 재생 지점을 제공합니다.
구체적인 사례와 검증
진행률 이벤트는 마지막 상태만 중요할 수 있지만 결제 완료 알림은 누락 복구가 필요합니다. 같은 채널에 실었다고 동일한 재전송 정책이 맞는 것은 아닙니다. 마지막 이벤트 ID를 보내 재생할 수 있게 하려면 서버가 그 ID 이후 데이터를 보관하고, 보관 범위 밖이면 현재 snapshot으로 복구하는 절차를 제공해야 합니다. EventSource가 연결을 다시 시도해도 서버의 이벤트 로그가 생기는 것은 아닙니다. WebSocket은 양방향 메시지를 제공하지만 요청 상관관계·중복·순서와 인증 갱신을 별도 설계합니다. 두 방식 모두 느린 클라이언트의 버퍼 상한과 연결 종료 정책이 필요합니다.
프록시 뒤 지연·연결 끊김·탭 중단·중복 이벤트·마지막 수신 위치를 시험합니다. 진행 알림과 실제 작업 완료는 별도 상태 조회로 확인할 수 있게 합니다. 단순 알림 요구에 양방향 채널을 도입하는 비용을 정당화하겠습니다.
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- 핵심 구분: 서버에서 클라이언트로 주로 텍스트 이벤트를 보내면 SSE가 단순할 수 있고 양방향 빈번한 메시지나 바이너리 교환에는 WebSocket이 적합할 수 있습니다.
- 선택 조건: SSE의 브라우저 인증 헤더 제약·프록시 버퍼링·연결 한도와 WebSocket의 upgrade·idle timeout·서버 자원 점유를 비교합니다.
- 검증 기준: 프록시 뒤 지연·연결 끊김·탭 중단·중복 이벤트·마지막 수신 위치를 시험합니다.
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- SSE나 WebSocket의 재연결이 모든 이벤트를 정확히 한 번 복구한다고 한다.
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
- 연결 재수립 뒤 누락·중복 이벤트를 어떤 수신 위치와 snapshot으로 복구하나요?
- 원본이 조금씩 보내도 중간 프록시가 묶어 전달하는지 어떤 시각을 비교하나요?
- 수락한 요청이 계속 쌓이면 실행 수와 대기 수를 어떤 별도 상한으로 제한하나요?
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.