SSE (Server Sent Event)

TCP 연결 수립
→ HTTP GET /sse
→ HTTP 200 OK (헤더)
→ SSE 이벤트 데이터 반복 전송
→ 클라이언트가 연결 종료
→ 서버 ACK
→ 예외적 RST 발생

Phase 1: TCP 3-Way Handshake

TCP 3-Way Handshake 과정은 WebSocket 분석 시와 동일하므로 생략합니다.

332~334번 패킷에서 ESTABLISHED 상태가 되었습니다.

Phase 2: SSE Handshake (HTTP Request & Response)

WebSocket은 101 Switching Protocols로 업그레이드 하지만 SSE는 표준 HTTP 요청을 유지하되 응답을 종료하지 않고 열어두는 방식입니다.

• SSE는 프로토콜 업그레이드가 아닌, HTTP 연결의 장기 유지(Long-lived HTTP Connection)

[Packet-335]: Client → Server (HTTP GET /sse)

클라이언트가 Server-Sent Events(SSE) 구독을 시작하기 위한 HTTP 요청을 전송합니다.

이 패킷은 TCP 연결이 이미 ESTABLISHED 상태인 상황에서 전송되며, SSE 통신의 시작점에 해당합니다.

클라이언트는 GET /sse HTTP/1.1 요청을 통해 서버에 이벤트 스트림을 요청합니다.

• Accept: text/event-stream → 헤더를 통해 응답 데이터가 일반적인 HTTP 리소스가 아닌, 이벤트 스트림 형식임을 명시합니다.

• Connection: keep-alive → 헤더는 서버가 응답을 즉시 종료하지 않고, 하나의 HTTP 응답을 장시간 유지하며 데이터를 지속적으로 전송할 것을 의미합니다.

HTTP Request
- Method: GET
- Header:
    - Accept: text/event-stream
        - 이 요청의 응답은 이벤트 스트림으로 보내주세요
    - Cache-Control: no-cache
        - SSE 재연결 시 이전 응답 캐시 방지
    - Connection: keep-alive

👉 이 요청의 의미:
- “이 연결을 닫지 말고, 서버가 이벤트를 계속 보내주세요.”
- HTTP 요청은 한 번, 응답은 스트림 형태로 지속

• SSE는 WebSocket과 달리 프로토콜 업그레이드(Upgrade) 과정이 존재하지 않으며, 이 단일 HTTP 요청 이후 별도의 애플리케이션 계층 핸드셰이크는 수행되지 않습니다.

• 이 요청은 데이터 Payload를 포함하지 않는 단발성 요청이며, 이후의 모든 데이터 전송은 서버가 보내는 HTTP 응답 스트림을 통해 이루어집니다.

• 따라서 이 패킷은 WebSocket에서의 Upgrade Request에 대응되는 역할을 수행하지만, 프로토콜 전이 없이 HTTP 연결을 유지한다는 점에서 근본적인 차이를 가집니다.

• TCP 계층에서는 PSH, ACK 플래그가 설정된 일반 데이터 세그먼트로 전송되며, TCP는 이후 전송될 SSE 이벤트의 경계나 의미를 인지하지 못하고 단순한 바이트 스트림으로만 처리합니다.

[Packet-336]: Server → Client (ACK)

클라이언트가 보낸 [Packet-335] (GET /sse) 요청을 "잘 받았습니다."고 서버의 OS(TCP 계층)가 응답하는 것입니다. (TCP 계층의 수신 확인 패킷)

이 ACK은 애플리케이션(Spring, Node.js 등)이 응답을 만들기도 전에, OS 레벨에서 보내는 수신 확인 패킷입니다.

[Packet-337, 339]: Server → Client (PSH, ACK)

서버가 생성한 HTTP 200 OK 응답 헤더(Response Header) 데이터의 실제 전송 구간입니다.

서버가 보낼 HTTP 응답 헤더의 양이 꽤 되기 때문에, TCP 계층에서 이를 두 개의 조각(Segment)으로 나누어 전송합니다.

이 패킷들에는 PSH(PUSH) 플래그가 설정되어 있는데, 이는 수신 측에서 데이터를 버퍼에 지연시키지 않고,

즉시 상위 계층(애플리케이션)으로 전달하도록 유도하기 위한 힌트입니다.

와이어샤크의 Info 컬럼에 표시된 [TCP PDU reassembled in 341]는 다음을 의미합니다.

• 337번, 339번 패킷은 물리적으로 분할된 TCP 세그먼트 (전송 단위로 해석 가능)

• 이 둘을 재조립하면, 341번에서 확인 가능한 완전한 HTTP 응답 메시지가 됨

• 즉, "이 패킷(337, 339)들은 조각난 데이터이니, 341번에서 조립된 완성본을 보여주겠다"는 뜻입니다.

[Packet-338, 340]: Client → Server (ACK)

이 과정은 HTTP나 SSE와는 무관하지만, 클라이언트는 서버로부터 TCP 세그먼트를 하나 수신할 때마다, 각 세그먼트에 대해 순차적으로 수신 확인(ACK)을 반환합니다.

• Packet-338 → Packet-337 수신 완료 확인

• Packet-340 → Packet-339 수신 완료 확인

쉽게 얘기하면, 서버가 보낸 조각(337번, 339번)을 하나 받을 때마다 클라이언트가 "1번 조각 받음(338)", "2번 조각 받음(340)" 하고 확인하는 과정입니다.

[Packet-341]: Server → Client (HTTP/1.1 200 OK)

서버가 클라이언트의 GET /sse 요청에 대한 HTTP 응답 헤더를 모두 전송한 결과입니다.

이 항목은 실제로 새로운 패킷이 전송된 것이 아니라, 앞서 서버가 보낸 TCP 세그먼트들([Packet-337], [Packet-339])에 담긴 바이트를 와이어샤크가 하나의 HTTP 응답으로 합쳐서 보여주는 표시입니다.

• 즉, 와이어샤크가 논리적으로 재조립(Reassembled)하여 보여주는 가상의 결과값입니다.

이 시점부터 클라이언트는 해당 연결을 SSE 이벤트 스트림으로 해석하기 시작합니다.

응답에는 다음과 같은 정보가 포함되어 있습니다.

• 상태 코드: HTTP/1.1 200 OK

• Content-Type: text/event-stream → 응답의 Body는 이벤트 스트림임을 의미

• Connection: keep-alive → 연결을 종료하지 않고 유지함

이 응답이 전달되면서, 서버는 다음을 명확히 합니다.

• 이 연결을 요청–응답으로 끝내지 않습니다.

• 하나의 HTTP 응답을 유지한 채, 서버가 필요할 때마다 이벤트 데이터를 계속 전송합니다.

따라서 이 시점 이후,

• 클라이언트는 더 이상 서버 응답을 “기다리는 상태”가 아니라, 열린 HTTP 응답 스트림을 수신하는 상태가 됩니다.

• 즉, 서버가 보내는 모든 SSE 이벤트는 이 HTTP 응답의 본문(Body)에 연속적으로 추가되며, TCP 계층에서는 이를 단순한 바이트 스트림으로만 처리합니다.

[Packet-342]: Client → Server (ACK)

클라이언트가 서버에서 전송한 HTTP 응답 데이터(337, 339 → 논리적으로 341)를 정상적으로 수신했음을 TCP 계층에서 확인(ACK)하는 패킷입니다.

이 패킷은 애플리케이션 계층(HTTP/SSE)과는 직접적인 의미가 없으며, TCP의 신뢰성 보장 메커니즘에 의해 자동으로 전송되는 수신 확인 패킷입니다.

물리적 의미:

방금 전 Packet-341은 와이어샤크에서 ‘HTTP 응답 완성본'으로 표현되었지만, 실제 물리적 네트워크상에서는 마지막 데이터(7 bytes)를 담은 패킷이었습니다.

• ACK 번호 계산: 이전까지 확인한 번호(287) + 방금 받은 데이터 크기(7) = ACK(294)

논리적 의미 (Handshake Completed):

이 패킷을 끝으로 SSE 연결 수립을 위한 초기 데이터 교환이 마무리되었다는 것을 의미합니다.

• 이 시점부터 클라이언트는 Passive Receiver로 전환되며, 서버가 이벤트를 PUSH 해줄 때마다 ACK만 보내는 역할을 수행합니다.

[Follow TCP Stream]

이 기능은 TCP 연결에서 오간 모든 바이트를 시간 순서대로 보여줍니다.

SSE는 요청 1번 + 응답 1번 + 연결 유지 + Body에 데이터를 계속 추가하는 구조이기 때문에,

• GET /sse 요청

• HTTP/1.1 200 OK 응답 헤더

• 그 뒤에 이어지는 모든 이벤트 데이터

이 모든것이 하나의 TCP 스트림 안에 들어있어서 341번 패킷을 기준으로 Follow 하면 전체 대화 내용이 보입니다.

이미지를 보면, 끝나지 않는 HTTP 응답의 Body에, 서버가 chunk 단위로 이벤트를 계속 써 내려가는 구조인 것을 확인할 수 있습니다.

Phase 3: Data Transmission (Event Stream)

HTTP 응답 헤더가 모두 전달되고(SSE 핸드셰이크 완료), 클라이언트가 이를 text/event-stream으로 해석하기 시작한 이후의 단계입니다.

• 즉, HTTP/1.1 200 OK 응답 헤더가 끝나고 Body 전송이 시작된 이후의 단계입니다.

이 Phase에서는 새로운 HTTP 요청이나 응답이 오가지 않습니다. 이미 열려 있는 단 하나의 HTTP/1.1 200 OK 응답의 Body에 서버가 시간 간격을 두고 데이터를 계속 추가(Append)합니다.

• 전체 패킷을 나타낸 이미지는 서버가 약 5초 간격으로 총 3번의 이벤트를 클라이언트에게 PUSH 하는 과정입니다.

• 각 사이클은 [서버의 데이터 전송(PSH)] → [클라이언트의 수신 확인(ACK)] 패턴이 동일하게 반복됩니다.

Follow TCP Stream 섹션에 이미지를 보면, id=0까지 SSE 연결 수립에 필요한 데이터를 나타내고,

id=1 부터 890~2899번 패킷에서 오간 데이터가 표시됩니다. (Packet Bytes에서 확인 가능)

[Packet-890 ~ 894]: Server → Client (첫 번째 이벤트 전송)

id:1
event:update
data: {"type":"update", "timestamp":..., "count":1}

• 이벤트: id:1 메시지 발생

• 동작:

  • SSE 연결이 맺어지고 약 5초(핸드셰이크 시간 포함) 뒤, 서버가 첫 번째 데이터를 보냅니다.

  • 데이터가 TCP 세그먼트 여러 개(890, 892 등)로 분할되어 전송

  • Wireshark는 이를 Packet-894에서 하나의 HTTP PDU로 재조립하여 표시

• 내용:

  • Follow TCP Stream에서 확인한 첫 번째 JSON 데이터가 이 패킷들에 담겨 있습니다.

  • 새로운 HTTP 응답이 아니라, 기존 200 OK 응답 Body의 일부입니다.

[Packet-895]: Client → Server (ACK)

클라이언트가 서버로부터 첫 번째 이벤트 데이터(890~894번 내용)를 모두 잘 받았음을 의미하는 패킷입니다.

• 클라이언트가 서버로부터 수신한 데이터 바이트 범위에 대해 다음에 기대하는 시퀀스 번호를 ACK로 응답한 패킷입니다.

• Len=0 → Payload 없음

[Packet-900]: Client → Server (FIN, ACK)

클라이언트의 연결 종료 의사 (Active Close)

• 상황:

  • 사용자가 브라우저 탭을 닫았거나, 페이지를 이동하여 클라이언트가 "이제 연결 끊을게요."라고 선언했습니다.

• FIN 플래그:

  • "클라이언트는 더 이상 서버한테 보낼 요청(데이터)이 없어요. 클라이언트의 말하기(Write) 기능은 끌게요."

  • 이 시점에서 클라이언트는 FIN_WAIT_1 상태가 됩니다.

  • FIN은 연결 전체 종료가 아니라, 송신 방향(write side) 종료를 의미합니다.

[Packet-901]: Server → Client (ACK)

서버는 클라이언트의 FIN 패킷 수신 확인

• 상황:

  • 서버의 OS(TCP 계층)가 클라이언트의 FIN 패킷을 수신하고, 확인했다는 응답 포함

• 상태 변화:

  • 서버는 CLOSE_WAIT 상태가 됩니다.

  • 중요: OS는 알았지만, 서버 애플리케이션(Spring 등)이 아직 소켓을 안 닫음, 응답 스트림도 유지 중

  • 클라이언트는 FIN_WAIT_2 상태가 됩니다.

[Packet-1676 ~ 1680]: Server → Client (두 번째 이벤트 전송)

• 이벤트: id:2 메시지 발생

• 동작:

  • 첫 번쨰 이벤트 전송과 완전히 동일한 TCP 전송 과정(PSH, ACK)을 거칩니다.

  • 1676번(헤더 부분) + 1678번(바디 부분)으로 나뉘어 전송된 후, 1680번에서 하나로 조립(Reassembled)되어 보입니다.

• Point:

  • 클라이언트가 FIN을 보냈음에도 서버는 여전히 데이터를 전송하고 있습니다.

  • 서버는 아직 CLOSE_WAIT 상태

  • 응답 스트림을 닫지 않았기 때문에 쓰기(write)가 가능합니다.

[Packet-1681]: Client → Server (ACK)

앞에서 클라이언트는 이미 Packet-900에서 FIN을 보냈는데, 왜 이후에 서버가 보낸 데이터에 대해 다시 ACK(현재 패킷, 1681)를 보낼까요?

원인은 TCP Half-Close 동작 규칙에 있습니다.

TCP에서 FIN은 연결 전체 종료가 아니라 송신 방향 종료를 의미합니다.

즉, Client FIN (Packet-900)는 더 이상 서버로 보낼 데이터가 없다는 것을 의미합니다.

• 서버로부터 더 이상 데이터를 받지 않겠다는 의미가 아닙니다.

• 클라이언트 OS는 FIN_WAIT_2 상태로, 들어오는 데이터에는 ACK 응답을 전송합니다.

서버는 아직 소켓을 닫지 않았고 클라이언트 역시 수신 경로는 열린 상태입니다.

[Packet-2879 ~ 2899]: Server → Client (세 번째 이벤트 전송)

• 이벤트: id:3 메시지 발생

• 동작:

  • 마지막으로 count:3 데이터를 전송합니다.

[PSH(PUSH) 플래그의 의미]

이 구간의 서버 패킷 다수에는 PSH 플래그가 설정되어 있습니다.

이는 TCP 스택에서 다음과 같은 의미를 가집니다.

• “이 데이터는 버퍼에 쌓아두지 말고”,

• 즉시 애플리케이션 계층(브라우저)으로 전달하라는 신호입니다.

SSE는 실시간 전달이 핵심이기 때문에, 이 Phase에서 PSH가 자주 등장하는 것은 정상적이고 의도된 동작입니다.

Phase 4: Exceptional Termination (RST)

클라이언트가 송신 종료(FIN)를 했음에도 서버가 데이터를 계속 보낼 때 발생할 수 있는 마지막 단계입니다.

[Packet-2900]: Client → Server (RST)

상황:

• 서버가 세 번째 데이터(id:3)를 전송했을 때 클라이언트가 보내는 패킷입니다.

RST(Reset) 플래그:

• "나는 이 연결에 대해 더 이상 처리할 수 없으니, 즉시 연결을 강제 종료(Abort)하겠다"는 강력한 신호입니다.

발생 원인:

1. 애플리케이션 계층의 부재: 클라이언트 브라우저가 이미 탭을 닫았거나 페이지를 완전히 떠나서 수신 버퍼에 있는 데이터를 처리할 프로세스가 사라진 경우입니다.

2. 부적절한 데이터 수신: TCP 계층은 살아있어 ACK를 보냈더라도(1681번), 애플리케이션이 이미 소켓을 닫아버린 상태에서 데이터가 계속 들어오면 OS는 RST를 보내 연결을 파괴합니다.

결론:

• SSE는 서버가 연결의 주도권을 갖지만, 클라이언트가 종료를 원할 때 서버가 이를 감지하지 못하고 계속 데이터를 푸시하면 이처럼 RST와 함께 연결이 비정상적으로 끝날 수 있습니다.

• 따라서 서버 측에서도 클라이언트의 요청 종료를 적절히 핸들링(Exception Handling)하여 자원을 해제하는 것이 중요합니다.

Summary

1. 연결 수립 (Handshake)

• 표준 HTTP 활용:

  • WebSocket과 달리 101 Switching Protocols 과정 없이, 일반적인 GET 요청을 장기 유지(Long-lived)하는 방식입니다.

  • 기존 HTTP 1.1 이상의 인프라를 그대로 사용합니다. 이는 방화벽이나 프록시 서버 환경에서도 별도 설정 없이 실시간 통신이 가능하다는 강력한 장점이 됩니다.

• 필수 클라이언트 헤더:

  • Accept: text/event-stream: 서버에게 이벤트 스트림 형식의 응답을 요구합니다.

  • Cache-Control: no-cache: 브라우저가 이전 이벤트를 캐싱하지 않고 실시간으로 받도록 보장합니다.

  • Connection: keep-alive: TCP 연결을 끊지 않고 계속 유지합니다.

2. 데이터 전송 방식

• 단방향(Unidirectional): 서버에서 클라이언트로만 데이터를 보냅니다. 클라이언트에서 서버로 데이터를 보낼 때는 별도의 HTTP 요청을 사용해야 합니다.

• 실시간성 보장 (PSH Flag): TCP 계층에서 PSH 플래그를 적극적으로 사용하여, 버퍼링 없이 즉시 상위 애플리케이션으로 데이터를 전달합니다.

• 자동 재연결(Auto Reconnect): 브라우저의 EventSource API는 연결이 끊기면 자동으로 재연결을 시도하며, 서버가 id 값을 함께 보내주면 마지막 받은 지점부터 복구가 가능합니다.

3. 연결 종료 및 자원 관리

• Half-Close의 함정: 클라이언트가 탭을 닫아 FIN을 보내더라도, 서버는 이를 감지하기 전까지 데이터를 계속 보낼 수 있습니다.

• RST 패킷의 경고: 클라이언트 애플리케이션이 이미 종료된 상태에서 서버가 데이터를 푸시하면 RST 패킷이 발생하며 강제 종료됩니다.

• 서버 측 대응: 서버는 클라이언트의 연결 상태를 주기적으로 확인하거나, 데이터 송신 시 발생하는 예외(Broken Pipe 등)를 캐치하여 사용하지 않는 연결을 즉시 정리해야 서버 자원 누수를 막을 수 있습니다.

  • 사용중인 스레드 등