WebSocket

Phase 1: TCP Connection Establishment (TCP 3-Way Handshake)

이 과정은 데이터를 주고받기 전, 논리적인 연결을 만드는 과정입니다.

즉, 신뢰성 있는 전송 계층 세션을 생성하고, 양단의 시퀀스 번호(ISN)를 동기화하여 ESTABLISHED 상태로 전이합니다.

[Packet-171]: Client → Server (SYN)

1. 클라이언트가 Active Open을 수행합니다.

클라이언트가 서버에 연결을 능동적으로 요청하는 과정으로, connect() 시스템 콜을 호출하여 SYN 패킷을 전송합니다.

2. TCP 헤더의 SYN 플래그를 1로 설정하고, 자신의 초기 시퀀스 번호(ISN)를 생성하여 보냅니다.

이미지의 171번 패킷의 Info를 보면 Seq=0으로 설정되어 있습니다.

이것은 와이어샤크가 보기 편하라고 ‘가짜로 보여주는 숫자(Relative Sequence Number)’입니다.

실제로는 0이 아니라 40억 개의 숫자 중 무작위로 생성된 거대한 숫자입니다.

패킷 패널의 Transmission Control Protocol를 확장하면 확인할 수 있습니다.

이 안에 Sequence Number: 0 (relative sequence number)라고 적힌 줄이 보이고,

그 바로 밑에 Sequence Number (raw): 2669254254 라고 적힌 raw 값이 바로 클라이언트 OS가 생성한 진짜 ISN입니다.

🤔 그럼 왜 0으로 보여주나요?

• 2669254254 다음에 2669254255가 왔는지 확인하는 것보다, 0 다음에 1이 왔는지 확인하는 게 분석가 입장에서 편하기 때문에 와이어샤크가 자동으로 계산해서 보여줍니다.

3. 상태 전이: 클라이언트는 CLOSED → SYN_SENT 상태로 전이합니다.

상태 전이 부분은 와이어샤크 화면에서 찾아볼 수 없었습니다. 하지만 왜 전이되는지 알 수 있습니다.

• 패킷(Packet)은 네트워크 선을 타고 날아가는 정보입니다.

• 상태(State)는 정보 안에 있는 세부 정보입니다. 패킷 헤더에는 패킷을 전송하는 순간, 대상의 답장을 기다리는 모드(SYN_SENT)로 변합니다.

🤔 SYN_SENT 상태는 어떻게 확인할 수 있나요?

와이어샤크에서는 직접 확인할 수 없기 때문에 패킷 내부의 플래그를 통해 역추론할 수 있습니다.

• Flags의 항목을 확장하면, Syn: Set(1) 인 것을 확인할 수 있습니다.

TCP/IP State Transition Diagram (RFC 793) SYN-SENT: represents waiting for a matching connection request after having sent a connection request.

TCP 규약(RFC 793)에 따르면, SYN을 보낸 직후 OS는 무조건 SYN_SENT 상태로 바뀐다고 명시되어 있습니다. 그래서 클라이언트는 SYN_SENT 상태라고 결론을 내릴 수 있습니다.

[Packet-172]: Server → Client (SYN, ACK)

1. 서버가 Passive Open 상태에서 요청을 수락합니다.

서버는 애플리케이션이 실행되면서 이미 bind()와 listen() 시스템 콜을 호출하여 수동적 개방(Passive Open) 상태로 진입하여 LISTEN 상태입니다.

서버는 클라이언트의 연결 요청(SYN)을 기다리면서, SYN을 수신하면 이에 대한 응답 프로세스를 시작합니다.

2. TCP 헤더 설정

• SYN: 서버도 자신의 ISN을 생성하여 동기화 요청을 보냅니다.

• ACK: 클라이언트의 ISN에 1을 더한 값(ACK=1)을 승인 번호로 보냅니다.

  • Acknowledgment number (raw): 2669254255 로 나타나있습니다.

🤔 그렇다면 왜 1을 더할까요?

TCP Segment의 Len=0인 것을 보면, 이 패킷에는 데이터(Payload)가 없다는 것을 알 수 있습니다.

일반적으로 데이터가 없으면 ACK 번호는 증가하지 않아야 합니다. 하지만 TCP 규약(RFC 793)에는 특수한 규칙이 있습니다.

“The segment length (SEG.LEN) includes both data and sequence space occupying controls. When a SYN is present then SEG.SEQ is the sequence number of the SYN.”

이는, 다음과 같이 해석할 수 있습니다.

"SYN 플래그와 FIN 플래그는 데이터가 없더라도 논리적으로 1바이트의 시퀀스 번호를 소비(Consume)한다.”

즉, 서버 입장에서 172번 패킷(SYN + ACK)을 보낼 때 논리는 다음과 같습니다.

• 클라이언트가 보낸 171번 패킷을 받습니다.

• 데이터(Payload)는 없지만, SYN 플래그가 존재합니다.

• SYN 플래그를 데이터 1byte 처럼 취급해서 처리합니다.

• 그래서 서버는 받은 번호(2669254254) + 1인 2669254255를 다음 번호로 기대하고 응답(ACK)합니다.

이러한 설계의 장점은 다음과 같습니다.

• 일관된 스트림 모델

  • 연결 설정/종료가 모두 하나의 연속된 시퀀스 번호 공간 위에 놓입니다.

  • 송수신 양쪽이 ‘어디까지 처리했는지’를 하나의 숫자(ACK)로만 표현할 수 있습니다.

• 재전송/중복 처리 단순화

  • SYN/FIN도 시퀀스 번호를 갖기 때문에, ‘이 시퀀스 구간은 이미 받은 건가?’만 확인하면 중복/지연/재연송 여부를 판단할 수 있습니다.

  • 제어 플래그라고 해서 별도 예외 처리 로직을 두지 않아도 됩니다.

3. 상태 전이: 서버는 LISTEN → SYN_RCVD 상태로 전이합니다.

클라이언트의 SYN 패킷을 받으면, 서버는 이에 대한 응답으로 SYN-ACK를 보내 연결 요청을 확인(ACK)하고 연결 수립 과정에 진입합니다.

SYN-ACK를 보냈으므로, 이제 클라이언트의 마지막 응답을 기다리기 위해 서버의 OS 소켓 상태를 SYN_RCVD로 변경합니다.

[Packet-173]: Client → Server(SYN, ACK)

1. 클라이언트가 서버의 동기화 요청을 확인합니다.

• 서버의 ISN에 1을 더한 값(ACK=1)을 보냅니다.

2. 상태 전이

• 클라이언트는 이 패킷을 전송하며 SYN_SENT → ESTABLISHED 상태가 됩니다.

• 서버는 이 패킷을 수신하며 SYN_RECEIVED → ESTABLISHED 상태가 됩니다.

• 이는 클라이언트와 서버 간 논리적인 데이터 전송 경로가 생성됨을 의미합니다.

Phase 2. Protocol Upgrade Handshake (HTTP → WebSocket)

이 과정은 Application Layer(L7) 프로토콜을 HTTP/1.1에서 WebSocket으로 전환합니다.

[Packet-174]: Client → Server (HTTP GET /ws)

클라이언트가 WebSocket Handshake를 위한 Request를 전송합니다.

Hypertext Transfer Protocol 섹션은 TCP 페이로드를 해석한 결과입니다.

• Upgrade: websocket → 프로토콜 변경 요청

• Connection: Upgrade → 홉(Hop)간 업그레이드 옵션 명시 (필수 헤더)

• Sec-Websocket-Key: tgK1hM8wU7SHuWxUJds40Q== → 무작위 16bytes 값을 Base64 인코딩한 챌린지 키

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

서버 TCP 계층의 수신 확인입니다.

L7 애플리케이션이 패킷 174번 요청을 처리하여 응답(101 Switching Protocols)을 생성하는 동안, L4(OS 커널)는 수신 버퍼에 데이터가 적재되는 즉시 독립적으로 TCP ACK(Packet-175)를 송신 측에 보냅니다.

• 이는 TCP의 신뢰성 보장 메커니즘이며, ‘데이터가 유실 없이 도착했음’을 송신 측에 알리는 절차입니다.

[Packet-193]: Server → Client (HTTP 101 Switching Protocols)

서버가 Handshake Response를 전송하며 프로토콜 전환을 승인합니다.

• HTTP/1.1 Status Code: 101: 프로토콜 전환 승인 응답 상태 코드

• Sec-WebSocket-Accept: fVka1UgF5mcoCU07ZlpLj/mPUR0=: 클라이언트가 보낸 Key와 Magic GUID를 결합 후 SHA-1 해싱하고, 이를 다시 Base64 인코딩하여 생성한 응답 키입니다.

• 이 과정을 통해 상호 연결을 검증합니다.

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

클라이언트 측 OS가 서버의 193번 패킷(Handshake Response) 수신을 확인합니다.

이 시점 이후 해당 TCP 세션의 Payload는 더 이상 HTTP 규칙이 아닌 WebSocket Frame 규격을 따르며, 양방향 통신(Full-Duplex)이 시작됩니다.

Phase 3. Data Transmission (WebSocket Frames)

클라이언트와 서버는 HTTP 101 Switching Protocols 응답 이후,

TCP 연결 위에서 WebSocket 프로토콜을 사용하여 프레임 단위의 Full-Duplex 통신을 수행합니다.

이 단계에서는 HTTP 메시지가 아닌, RFC 6455에 정의된 WebSocket Frame 형식이 TCP Payload에 담깁니다.

[Packet-199]: Server → Client (WebSocket Text [FIN])

1. 서버가 클라이언트에게 텍스트 메시지(데이터)를 PUSH 합니다.

Wireshark에 WebSocket 트리가 표시되는 것은, 이 패킷이 TCP Payload를 HTTP가 아니라 WebSocket 프로토콜로 해석했다는 의미입니다.

프레임 구조는 다음과 같습니다.

• FIN: True

• Opcode: Text (1) → 1은 텍스트 프레임 종류이며 Payload가 UTF-8 Text를 의미합니다.

• Mask: False → 서버 to 클라이언트는 보통 False입니다.

• Payload length: 81 → 실제 데이터 길이를 의미합니다.

1. Payload 내용

Line-based text data는 이미 WebSocket 프레임 안에 있는 페이로드를, Wireshark가 사람이 읽기 좋게 풀어서 보여주는 영역입니다. 이미지에 보여지는 JSON 메시지는 Payload를 UTF-8 텍스트로 디코딩한 결과입니다.

1. WebSocket Opcode 종류 (RFC 6455)

메시지 데이터 프레임 (Data Frames): 텍스트/바이너리 메시지를 전송하는 프레임

Opcode	이름	의미
0x0	Continuation Frame	이전 프레임의 연속 데이터
0x1	Text Frame	UTF-8 텍스트 데이터
0x2	Binary Frame	바이너리 데이터

제어 프레임 (Control Frames): 연결 관리·상태 제어를 위한 프레임

Opcode	이름	의미
0x8	Connection Close	연결 종료 요청
0x9	Ping	상태 확인(Ping) 요청
0xA	Pong	Ping에 대한 응답

[Packet-199]: Server → Client (WebSocket Text [FIN])

TCP 계층의 수신 확인 과정입니다.

WebSocket은 TCP 위에서 동작하므로, 서버가 보낸 [Packet-199]의 TCP 세그먼트에 대해 클라이언트는 TCP ACK 패킷을 보내 수신을 확인합니다.

TCP Stream과 WebSocket Frame 관계

WebSocket 통신은 연결 수명 동안 하나의 TCP 연결(TCP Stream) 위에서 수행됩니다.

TCP 계층에서 WebSocket 데이터는 연속된 바이트 스트림의 일부(Payload) 로 전달되며, TCP는 WebSocket 프레임의 경계를 인지하지 않습니다.

따라서, WebSocket 프레임의 메시지 경계는 애플리케이션 계층(WebSocket 프로토콜) 에서만 의미를 가지며, 신뢰성, 순서 보장, 재전송은 TCP 계층에서 담당합니다.

Phase 4. WebSocket Closing Handshake (Graceful Shutdown)

WebSocket은 Application Layer에서 양측이 종료 의사를 명시적으로 교환하여, 비정상 종료와 정상 종료를 구분합니다.

• 정상 종료: Close Frame을 주고받는 Closing Handshake 절차를 완료한 후 TCP 연결을 끊는 것.

• 비정상 종료: 이 절차 없이 갑자기 TCP 연결이 끊기는 경우.

[Packet-322]: Server → Client (WebSocket Connection Close [FIN])

1. 서버가 먼저 Close Frame을 전송하며 Websocket 연결 해제 절차를 개시합니다.

WebSocket 연결을 끊을 때도 종료 요청·응답은 모두 HTTP가 아닌 WebSocket 프레임으로 주고받고, 이 프레임이 실린 TCP 세그먼트는 흔히 PSH, ACK 플래그를 가진 일반 데이터 세그먼트처럼 전송됩니다.

누가 먼저 Close Frame을 보내는지 정해진 규칙은 없고, 현재 글에서는 서버가 먼저 Close 프레임을 전송합니다.

• 종료 요청의 주체는 클라이언트가 될 수도 있으나, 현재 패킷 흐름에서는 서버가 주체입니다.

• FIN bit=1: 프레임 종료를 의미하며, TCP FIN과는 다른 개념

프레임 구조:

• Opcode=0x8: 연결 종료 요청

• Payload: 상태 코드(Status Code, 예: 1000 Normal Closure) 포함.

1. 상태: WebSocket 계층은 OPEN → CLOSING 상태로 진입합니다.

OPEN 상태에서 한쪽이 Close Frame을 보내면 그 순간부터 해당 WebSocket 구현은 CLOSING으로 들어가고, 응답 CLOSE를 주고받은 뒤 CLOSED로 이동합니다.

즉, 이 시점에서 서버 WebSocket 상태는 OPEN → CLOSING으로 전이되고, 클라이언트의 응답을 기다립니다.

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

클라이언트 OS가 TCP 계층에서 Close Frame 데이터가 유실 없이 도착했음을 확인하고 ACK 패킷을 전송합니다. 이는 Application Layer의 응답이 아니라, L4 수준의 수신 확인 메커니즘입니다.

• ACK는 TCP 레벨의 신뢰성 보장 과정

[Packet-324]: Client → Server (WebSocket Connection Close [FIN])

라이언트가 종료 요청을 승인하고, 이에 대한 응답으로 자신의 종료 프레임(Close Frame)을 전송합니다. 이는 서버 Close 요청에 대한 응답이며 Close Echo라고도 표현됩니다.

이 Close Frame을 송신한 클라이언트의 WebSocket 상태 역시 OPNE → CLOSING으로 전이됩니다.

프레임 구조:

• Mask=1: 클라이언트 → 서버 전송이므로 마스킹 적용

• Opcode=0x8: 연결 종료 요청

• FIN bit=1: WebSocket Frame 종료

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

서버 TCP 계층에서 클라이언트의 Close Frame이 성공적으로 도착했음을 확인하며, 수신을 확인하고 ACK를 전송합니다.

이 시점에서 L7 레벨(WebSocket)의 논리적 연결은 안전하게 종료되었고, 이후 TCP FIN 교환을 통해 Socket과 같은 물리적 리소스가 해제됩니다.

Phase 5. TCP Connection Termination (Teardown)

TCP 연결 종료는 FIN 기반의 종료 절차를 통해 소켓(Socket) 리소스 및 포트 바인딩을 OS에 반환합니다.

일반적으로는 4-Way Handshake를 수행하지만, 상황에 따라 FIN + ACK가 합쳐져 3-Way처럼 보이는 최적화가 발생할 수 있습니다.

이 예시에서는 일반적인 4‑Way 종료가, FIN과 ACK를 묶어서 보내는 형태로 3‑Way처럼 최적화된 케이스입니다.

Full-Duplex(전이중) 연결을 해제하는 과정입니다.

1. Server Output Close: 326번 패킷으로 서버의 송신 채널이 닫혔습니다.

2. Client Output Close: 327번 패킷으로 클라이언트의 송신 채널이 닫혔습니다.

3. Complete Teardown: 328번 패킷으로 양쪽의 상태가 동기화되며 세션이 완전히 종료되었습니다.

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

1. 서버가 Active Close를 시도하며 먼저 FIN을 전송합니다.

플래그:

• FIN=1:더 이상 보낼 데이터가 없음을 의미합니다.

• ACK=1: 이전까지 수신한 데이터를 정상적으로 확인했음을 의미합니다.

1. 상태 전이 서버는 ESTABLISHED → FIN_WAIT_1 상태로 진입합니다.

이 시점에서 서버는 클라이언트의 ACK를 기다리고 있으며, 이후 클라이언트의 FIN을 별도로 수신해야 합니다.

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

1. 클라이언트가 Passive Close를 수행합니다. 서버의 FIN에 대한 ACK와 자신의 FIN을 합쳐서 전송합니다.

서버의 FIN에 대한 ACK와 자신이 보낼 FIN을 하나의 세그먼트에 합친 최적화된 패턴입니다.

이 동작으로 인해 4-Way가 3-Way처럼 보이는 형태가 됩니다.

플래그:

• FIN=1: 클라이언트도 더 이상 보낼 데이터가 없음

• ACK=1: 서버 FIN에 대한 확인

1. 상태 전이:

💡 일반적으로 CLOSE_WAIT에서는 애플리케이션이 마지막으로 write를 수행할 수 있는 기회를 주지만, 여기서는 남은 데이터가 없기 때문에 바로 FIN

• 클라이언트는 ESTABLISHED → CLOSE_WAIT를 거쳐 즉시 LAST_ACK 상태가 됩니다.

  • 즉시 FIN을 보내므로 CLOSE_WAIT를 거치지 않고 LAST_ACK 상태로 진입합니다.

• 서버는 이 패킷(ACK)을 받고 FIN_WAIT_2로 갔다가, 동시에 들어온 FIN을 처리하며 TIME_WAIT 상태로 진입합니다.

  • 클라이언트 ACK 수신 → FIN_WAIT_2

  • 클라이언트 FIN 수신 → TIME_WAIT

  • 동시에 두 이벤트를 처리하기 때문에 중간 상태가 순식간에 변경됩니다.

TCP 스택 구현에 따라 중간 상태를 어떻게 업데이트하는지 로그 상에서는 잘 보이지 않을 수 있지만,

논리 흐름은 FIN_WAIT_1 → (ACK) → FIN_WAIT_2 → (FIN) → TIME_WAIT 입니다.

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

1. 서버가 클라이언트 FIN에 대한 최종 확인(ACK)를 전송하며 종료 절차를 마무리합니다.

2. 상태 전이:

   • 클라이언트는 LAST_ACK → CLOSED 상태가 되어 즉시 소켓 리소스를 반환합니다.

   • 서버는 TIME_WAIT 상태를 유지(지연 패킷 처리 보장)한 후 CLOSED 됩니다.

     • 지연된 세그먼트 소거

     • 이전 연결의 세그먼트가 새로운 연결로 혼입되지 않도록 보장