[SSE] SSE(Server-Sent Events)와 소켓 통신 정리

1. 모든 통신의 근본: Socket

• 네트워크 통신의 기본은 Socket이다.

• 소켓은 양 끝단에서 데이터를 주고받기 위한 연결 통로이며, 바이트 스트림(Byte Stream) 기반으로 동작한다.
• 소프트웨어 개발에서는 비트 단위까지 생각할 필요는 거의 없지만, 위성 통신, 우주 탐사 등 초정밀 환경에서는 비트 단위까지 고려하기도 한다.

• 소켓의 버퍼(Buffer):
• 데이터가 버퍼에 채워지면 자동으로 flush가 발생해 전송된다.

2. 통신 방식

비유:

전이중은 선 두 개(양방향)

반이중은 선은 하나지만 버퍼가 두 개라서 한쪽씩 번갈아 사용.

3. SSE(Server-Sent Events)의 본질

특징

1. 단방향: 서버 → 클라이언트로만 데이터 전송
• 서버가 클라이언트에 실시간 푸시(push) 가능.
• 클라이언트에서 서버로는 일반 HTTP 요청 사용.

2. 요청은 1회, 연결은 계속 유지
• 클라이언트가 한 번 요청을 보내면 서버가 응답 연결을 끊지 않고 유지한다.
• 이후 서버가 데이터가 생길 때마다 클라이언트로 지속적으로 푸시한다.

4. SSE와 HTTP의 관계

기본 HTTP의 한계

• 일반 HTTP 통신은 반이중(Half Duplex) → 요청과 응답이 한 번 끝나면 연결 종료.

• 실시간 통신이 어렵다 → 매번 요청-응답 반복 필요 (Polling)

SSE의 해결 방식

• HTTP 응답 선(Response Line) 만 유지(persist).

• 헤더에 Connection: keep-alive를 설정하여 응답 연결을 끊지 않고 유지.

• Content-Type:

Content-Type: text/event-stream

• 이를 통해 브라우저나 클라이언트가 "지속적인 이벤트 스트리밍" 모드임을 인식.
• 서버가 지속적으로 데이터를 푸시할 수 있게 됨.

5. HTTP/1.1 vs HTTP/2.0

HTTP/2.0은 구조적으로 스트리밍을 지원하기 때문에 SSE가 더욱 안정적이고 효율적으로 동작.

6. SSE와 소켓, Kafka의 관계

• Socket은 모든 통신의 기반이다.
→ SSE 역시 내부적으로는 소켓 위에서 동작.

• Kafka:
• 메시지 브로커 역할.
• 단일 진입점을 제공하여 대용량 트래픽 처리에 최적화.
• Kafka를 사용하는데 소켓 개념을 모른다면, 근본을 모른 채 잡기술만 배우는 것과 같음.

7. SSE 동작 흐름

[클라이언트]
    |
    | 1. 최초 HTTP 요청
    v
[서버]
    |
    | 2. 서버가 Connection: keep-alive로 응답
    |    Content-Type: text/event-stream
    v
[응답선 유지]
    |
    | 3. 서버에서 이벤트 발생 시마다 클라이언트로 Push
    |
    | (연결 유지, 클라이언트는 계속 수신)

8. 정리

• Socket은 통신의 근본.

• HTTP는 반이중, SSE는 이를 포장(Wrapping) 하여 실시간 단방향 푸시를 가능하게 한다.

• SSE 핵심 조건:
1. Connection: keep-alive
2. Content-Type: text/event-stream

• SSE는 요청은 한 번, 응답 연결만 계속 유지해 서버가 이벤트를 푸시한다.

• Kafka 등 고급 기술도 결국 소켓 기반이므로, 소켓 이해가 선행되어야 한다.

9. SSE vs WebSocket 비교

최종 요약

SSE는 HTTP 연결을 끊지 않고 유지하며, 서버가 클라이언트로 실시간 데이터를 푸시할 수 있도록 돕는 기술이다.

내부적으로는 소켓을 기반으로 동작하며, Connection: keep-alive와 Content-Type: text/event-stream이 핵심이다.

Kafka 같은 대규모 메시징 시스템도 결국 소켓 기반이므로, 소켓을 근본부터 이해하는 것이 중요하다.