TCP 연결 종료: 안전한 종료 과정

TCP(Transmission Control Protocol)는 신뢰성 있는 데이터 전송을 보장하기 위해 설계된 프로토콜이며, 연결 종료(Connection Termination) 과정 또한 안정적인 통신을 유지하고 시스템 자원을 효율적으로 해제하는 중요한 역할을 합니다.

TCP 연결이 끝나는 과정은 단순히 "연결을 끊는다"는 개념이 아니라, 모든 데이터가 정상적으로 전송되었음을 보장하고 양측이 연결 종료를 명확하게 인지하는 절차를 포함합니다. 이를 통해 네트워크 혼잡을 방지하고 불필요한 자원 낭비를 최소화할 수 있습니다.

---

1. TCP 연결 종료 개요

TCP 연결 종료는 주로 4-way 핸드셰이크(Four-Way Handshake) 과정을 통해 이루어집니다. 이 과정은 클라이언트와 서버가 서로 데이터를 더 이상 전송하지 않을 것을 확인하고, 각 측에서 독립적으로 연결 종료를 요청하고 승인하는 방식으로 진행됩니다.

연결 종료 과정이 필요한 이유는 다음과 같습니다:
✅ 데이터 무결성 보장 – 모든 데이터가 정상적으로 도착했음을 확인한 후 종료해야 함.
✅ 자원 해제 – 불필요한 연결을 유지하는 것은 시스템 성능 저하와 네트워크 혼잡을 초래할 수 있음.
✅ 정확한 종료 프로세스 필요 – 연결이 불완전하게 종료되면 포트가 장기간 점유되거나 데이터 손실이 발생할 가능성이 있음.

---

2. 4-way 핸드셰이크 과정

TCP 연결 종료는 네 개의 메시지 교환을 통해 이루어지며, 각 메시지는 연결 종료 의사를 명확히 전달하는 역할을 합니다.

📌 4-way 핸드셰이크 단계

1️⃣ FIN 패킷 전송 (클라이언트 → 서버)

• 데이터 전송을 완료한 측(예: 클라이언트)은 FIN(마침, Finish) 플래그가 설정된 패킷을 서버로 보냅니다.

• 이는 더 이상 데이터를 보내지 않겠다는 의사를 상대방에게 알리는 역할을 합니다.

  💡 예시:

• 사용자가 웹사이트를 닫거나, 파일 다운로드를 완료하면 브라우저가 웹 서버에 FIN 패킷을 전송합니다.

2️⃣ ACK 패킷 응답 (서버 → 클라이언트)

• 서버는 클라이언트의 FIN 요청을 받고, ACK(확인 응답) 패킷을 보냅니다.

• 하지만 서버는 아직 데이터 전송을 종료한 것은 아니며, 추가적인 데이터 전송이 필요할 수 있습니다.

  💡 예시:

• 웹 서버는 브라우저의 FIN 요청을 받고 "네, 요청을 확인했습니다!"라는 의미로 ACK 패킷을 응답합니다.

3️⃣ 서버의 FIN 전송 (서버 → 클라이언트)

• 서버도 모든 데이터 전송을 마친 후, FIN 플래그가 설정된 패킷을 클라이언트에게 전송하여 더 이상 데이터를 보내지 않겠다고 선언합니다.

  💡 예시:

• 웹 서버가 더 이상 추가 응답을 보낼 필요가 없다고 판단하면 자신의 FIN 패킷을 브라우저에게 보냅니다.

4️⃣ ACK 패킷 응답 및 연결 종료 (클라이언트 → 서버)

• 클라이언트는 서버의 FIN 패킷을 확인한 후, ACK 패킷을 전송하며 연결 종료를 최종 확정합니다.

• 이 패킷이 수신되면 연결이 완전히 종료되며, TCP 세션이 해제됩니다.

  💡 예시:

• 클라이언트는 서버로부터 받은 FIN 패킷을 확인한 후, "네, 이제 연결을 종료하겠습니다."라는 의미로 최종 ACK를 전송합니다.

---

3. TIME_WAIT 상태와 자원 해제

🔹 TIME_WAIT 상태란?

클라이언트가 마지막 ACK 패킷을 보낸 후에도 일정 시간 동안 연결을 유지하는 상태를 TIME_WAIT 상태라고 합니다.

✅ 이 상태가 필요한 이유:

• 마지막 패킷이 네트워크에서 지연될 가능성을 대비하여 동일한 패킷이 다시 도착할 경우 올바르게 처리할 수 있도록 하기 위함입니다.
• 네트워크에서 지연되거나 손실된 패킷이 재전송되었을 때 이를 잘못된 응답으로 간주하지 않도록 보호하는 역할을 합니다.

⏳ TIME_WAIT 지속 시간

• TIME_WAIT 상태는 일반적으로 2배의 RTT(Round Trip Time) 만큼 지속됩니다.
• RTT는 패킷이 송신 측에서 수신 측까지 왕복하는 데 걸리는 시간을 의미합니다.

💡 예시:

• 브라우저가 웹 서버에 최종 ACK를 보낸 후, TCP 소켓이 일정 시간 동안 여전히 열려 있는 이유가 바로 TIME_WAIT 상태 때문입니다.

---

4. 실생활 예시

✅ 웹 브라우저와 웹 서버 간 연결 종료

1️⃣ 사용자가 웹사이트를 탐색한 후 탭을 닫거나 페이지 이동을 수행.
2️⃣ 브라우저가 웹 서버에 FIN 패킷을 전송하여 연결 종료 요청.
3️⃣ 서버가 FIN 요청을 수락하고, ACK 패킷을 응답.
4️⃣ 서버도 모든 데이터를 처리한 후 자신의 FIN 패킷을 브라우저로 전송.
5️⃣ 브라우저가 마지막 ACK 패킷을 보내며 연결 종료 확정.
6️⃣ 브라우저는 일정 시간 동안 TIME_WAIT 상태 유지 후, TCP 소켓을 해제.

---

✅ 온라인 쇼핑몰에서 결제 후 연결 종료

1️⃣ 사용자가 결제를 완료하고 결제 페이지를 닫음.
2️⃣ 쇼핑몰 웹사이트(클라이언트)는 서버에 FIN 요청을 전송.
3️⃣ 서버는 결제 데이터 처리가 끝날 때까지 ACK를 전송하여 연결을 유지.
4️⃣ 결제 프로세스가 완료되면, 서버는 FIN 패킷을 클라이언트에 전송하여 연결 종료를 요청.
5️⃣ 클라이언트는 최종 ACK를 전송하여 안전하게 연결 종료.

---

5. 3-way 핸드셰이크와의 비교

구분	3-way 핸드셰이크	4-way 핸드셰이크
목적	연결을 설정하는 과정	연결을 안전하게 종료하는 과정
패킷 교환 횟수	3번 (SYN → SYN-ACK → ACK)	4번 (FIN → ACK → FIN → ACK)
상태 유지	연결 상태를 확립하여 데이터 전송 준비	데이터 전송이 끝난 후 연결을 종료하는 과정
주요 특징	서버와 클라이언트가 동시에 데이터 전송 가능	양측이 독립적으로 종료 요청을 할 수 있음

---

6. 결론

🔹 TCP의 4-way 핸드셰이크는 연결 종료 과정에서 신뢰성을 보장하기 위해 설계된 필수 절차입니다.
🔹 각 단계를 통해 송신자와 수신자가 정상적으로 데이터를 전송하고 연결을 종료했음을 확인할 수 있습니다.
🔹 TIME_WAIT 상태를 유지하여 네트워크 상의 지연된 패킷을 방지하고, 안정적인 자원 해제가 가능합니다.
🔹 웹 브라우징, 결제 시스템, 데이터 전송 종료 등 다양한 네트워크 환경에서 필수적으로 사용됩니다.