TCP 3-way handshake & 4-way handshake

 

매일메일 백엔드 질문을 참고해 개인적으로 학습한 내용을 정리하였습니다.
오류가 있다면 언제든 피드백 주시면 바로 반영하겠습니다..!

 

 

 

TCP란?

 

TCP는 Transmission Control Protocol의 약자로, TCP/IP 모델의 전송 계층(Transport Layer)에서 작동하는 핵심 프로토콜임

=> 신뢰성 있는 데이터 전송을 보장하는 역할을 맡음

 

TCP가 신뢰성을 보장하는 방법은 다음과 같음

 

• 연결 지향(Connection-Oriented) : 데이터를 보내기 전에 반드시 상대방과 통신 채널(세션)을 미리 설정함
  
  => 이 과정이 3-Way Handshake
  
  
• 신뢰성 있는 데이터 전송(Reliable Data Transfer) : 데이터를 패킷 단위로 나누고 각 패킷에 순서 번호(Sequence Number)를 부여함
  
  => 수신 측은 이 번호를 보고 빠진 패킷이 없는지, 순서가 맞는지 확인하고 확인 응답(ACK)을 보냄
  (만약 패킷이 중간에 유실되면 재전송을 요청하여 데이터의 무결성을 보장)
  
  
• 흐름 제어(Flow Control) : 데이터를 받는 수신 측의 처리 속도에 맞춰 송신 측이 데이터 전송량을 조절함
  
  => 수신 측이 천천히 보내달라고 신호를 주면, 송신 측이 속도를 늦추는 방식으로 동작
  
  
• 혼잡 제어(Congestion Control) : 네트워크 전체의 트래픽 상황을 감지하고, 네트워크가 혼잡하다고 판단되면 데이터 전송 속도를 스스로 줄여서 네트워크가 마비되는 것을 방지함

 

이러한 특징 때문에 TCP는 이메일, 파일 전송 등과 같이 데이터가 조금이라도 유실되거나 순서가 바뀌면 안 되는 중요한 통신에 사용되는 반면, 실시간 영상 스트리밍이나 온라인 게임처럼 약간의 데이터 손실을 감수하더라도 속도가 더 중요한 경우에는 UDP라는 프로토콜이 사용됨

 

3-Way Handshake란?

 

위에서 설명했듯이, TCP는 연결 지향 프로토콜이기에 데이터를 무작정 보내는 것이 아니라, 먼저 상대방과 통신할 준비가 되었는지 확인하고 서로의 상태를 동기화하는 과정을 거치는데 이 Handshake과정을 통해 클라이언트와 서버는 다음과 같은 중요한 정보를 주고받으며 신뢰할 수 있는 통신 채널을 만듬

 

1. 연결 요청 및 수락: 양쪽 모두 통신할 의사가 있음을 확인

 

2. 초기 순서 번호(ISN) 교환: 각자 데이터를 보낼 때 사용할 고유한 시작 번호를 상대방에게 알리고 이를 통해 데이터의 순서가 뒤섞이거나 유실되는 것을 방지함

 

3. 상호 상태 동기화: 양쪽이 데이터를 주고받을 준비가 되었음을 최종적으로 확인

 

3-Way Handshake의 동작 방식

 

3-Way Handshake의 핵심 요소

 

SYN (Synchronize Sequence Numbers)

 

SYN은 새 TCP 연결을 시작하겠다는 연결 요청 플래그임

 

=> 3-way handshake의 1단계에서 클라이언트가 보냄

 

두 방향(클라이언트→서버, 서버→클라이언트)이 각자 시작 시퀀스 번호(ISN)를 합의하기 위한 신호로 SYN은 데이터가 없어도 시퀀스 번호를 1바이트 소비한 것으로 간주됨.

=> 즉, 이후에 클라이언트가 보낼 다음 바이트 번호는 ISN+1

 

ISN을 고정값이 아닌 난수(예측 어려운 값) 로 잡음으로써 예전 연결에서 떠돌다 뒤늦게 도착한 중복 세그먼트와 구분하고 시퀀스 예측을 이용한 스푸핑 공격을 어렵게 함

 

ACK (Acknowledgement)

 

ACK는 이 세그먼트의 Acknowledgment Number 필드가 유효하다라는 의미의 플래그임

 

=> 3-way handshake의 2, 3단계부터를 포함해, 연결 성립 이후 오는 거의 모든 세그먼트가 ACK 플래그를 켬

 

 

Sequence Number (순서 번호)

 

TCP가 전달하는 바이트 스트림에서 이 세그먼트가 실은 첫 바이트의 위치를 나타내는 32비트 번호임

 

• 바이트 단위로 번호를 매김(세그먼트 단위 아님)
  
  
• 각 방향별로 별개로 관리(클라이언트→서버, 서버→클라이언트 각각 시퀀스가 따로 돌아감)
  
  
• 32비트이므로 0~(2³²-1) 사이에서 순환
  
  
• SYN/FIN은 각각 1바이트 소비, 순수 ACK만 담긴 세그먼트는 시퀀스 소비 X
  (FIN은 TCP에서 연결을 종료할 때 쓰는 제어 플래그)

• 예시
  
  
  • 클라이언트 ISN = 1000이면, 첫 SYN의 SEQ=1000
    
    
  • SYN이 1을 소비하니, 다음에 데이터 보낼 때 시작 SEQ는 1001

 

Acknowledgement Number (확인 응답 번호)

 

Acknowledgement Number는 다음에 받기를 기대하는 바이트의 번호로 그 번호 미만은 전부 잘 받았다는 누적 확인임

 

계산 방식

• 내가 방금 받은 상대 세그먼트가 SEQ = X부터 L바이트의 데이터를 실었다면, 내가 돌려보낼 ACK 번호는 X + L임
  
  
• 만약 그 세그먼트에 SYN/FIN이 있었다면 각각 +1을 추가(SYN/FIN은 1바이트로 치므로)
  
  

누적 ACK라서 중간에 빠진(손실된) 구간이 있으면 그 지점부터는 못 받았다고 간주하고 동일한 ACK 번호를 반복(중복 ACK) → 송신자가 손실을 눈치채고 재전송 트리거

=> 이 때 SACK(선택적 응답, TCP 옵션임)을 쓰면 손실되지 않은 데이터 블록을 구체적으로 보내줘서, 송신자가 잃어버린 부분만 재전송하게 해줌
(재전송 효율을 높일 수 있음)

 

ACK는 플래그 이름이고, Acknowlegment Number는 필드 값임

=> 플래그가 켜져 있어야 그 숫자가 의미가 있음

 

3-way Handshake 예시

 

클라이언트 ISN = 1000, 서버 ISN = 4000로 가정

 

1. 클라이언트 → 서버 : SYN, SEQ=1000
   (SYN이 1 바이트 소비 -> 클라이언트의 다음 SEQ는 1001)
   
   
2. 서버 → 클라이언트 : SYN+ACK, SEQ=4000, ACK=1001
   (서버 SYN도 1 소비 -> 서버 다음 SEQ는 4001)
   
   
3. 클라이언트 → 서버 : ACK, SEQ=1001, ACK=4001
   (서버의 SYN을 잘 받았고 다음은 4001을 기대)

 

3-Way Handshake의 단계

 

1단계 : 클라이언트 → 서버 (SYN)

 

클라이언트의 동작

 

1. 클라이언트는 서버에 접속을 요청하기 위해 TCP 세그먼트를 생성함
   
   
2. SYN 플래그를 1로 설정 (연결 요청의 의미)
   
   
3. 임의의 초기 순서 번호(ISN)를 생성하여 Sequence Number 필드에 담아 보냄
   
   
4. 이 세그먼트를 서버로 전송한 후, 클라이언트는 SYN-SENT 상태가 되어 서버의 응답을 기다림

 

2단계: 서버 → 클라이언트 (SYN + ACK)

 

서버의 동작

 

1. 서버는 LISTEN 상태에서 클라이언트의 SYN 요청을 받음
   
   
2. 서버는 요청을 수락하고, 응답 세그먼트를 생성
   
   
3. SYN 플래그를 1로 설정
   
   => 서버 자신도 연결을 시작하겠다는 의미
   
   
4. ACK 플래그를 1로 설정
   
   => 클라이언트의 요청을 잘 받았다는 의미
   
   
5. Acknowledgement Number 필드에 클라이언트가 보낸 Sequence Number + 1 값을 담음
   
   
6. 서버 자신만의 임의의 ISN을 생성하여 Sequence Number 필드에 담음
   
   
7. 이 세그먼트를 클라이언트로 전송한 후, 서버는 SYN-RECEIVED 상태가 됩니다.

 

3단계: 클라이언트 → 서버 (ACK)

 

클라이언트의 동작

 

1. 클라이언트는 서버가 보낸 SYN+ACK 세그먼트를 받음
   
   
2. Acknowledgement Number가 자신이 보냈던 seq + 1 과 일치하는지 확인하여 서버가 자신의 요청에 응답했음을 확인
   
   
3. 서버의 연결 요청(SYN)에 대한 확인 응답으로 다시 세그먼트를 생성
   
   
4. ACK 플래그를 1로 설정
   
   
5. Acknowledgement Number 필드에 서버가 보낸 Sequence Number + 1 값을 담음
   
   
6. 이 세그먼트를 서버로 전송하고 클라이언트의 연결 상태는 ESTABLISHED가 됨
   
   

서버의 동작

 

1. 서버는 클라이언트가 보낸 ACK 세그먼트를 받고, Acknowledgement Number가 자신이 보냈던 seq + 1 과 일치하는지 확인
   
   
2. 확인이 완료되면 서버의 연결 상태도 ESTABLISHED로 변경됨

이 3가지 단계를 모두 거치면, 클라이언트와 서버 간에 신뢰할 수 있는 양방향 통신 채널이 열리고, 실제 데이터(HTTP 요청/응답 등)를 주고받기 시작함

 

 

4-Way Handshake?

 

TCP 연결을 안전하게 종료하기 위한 4-Way Handshake라는 절차도 존재함

 

=> 한쪽이 일방적으로 끊는 것이 아니라, 양쪽 모두 확인하며 연결을 순차적으로 닫는 과정임

 

간단하게 살펴보면

 

 

연결을 먼저 끊고자 하는 쪽을 클라이언트, 상대방을 서버라고 가정했을 때 

 

1. 클라이언트 → 서버 (FIN)
   
   
   • 클라이언트가 서버에게 연결 종료를 알리는 FIN (Finish) 메시지를 보내고 클라이언트는 FIN_WAIT_1 상태가 됨
     
     
2. 서버 → 클라이언트 (ACK)
   
   
   • 서버는 클라이언트의 FIN을 받았다는 확인 ACK (Acknowledgement) 메시지를 보냄
     
     => 클라이언트에서 서버로의 통신은 닫힘
     
     
   • 하지만 서버는 아직 처리하고 남은 데이터가 있을 수 있으므로, 모두 보낼 때까지 잠시 연결을 유지함
     
     => 이때 서버는 CLOSE_WAIT 상태가 됨
     
     
3. 서버 → 클라이언트 (FIN)
   
   
   • 서버가 자신의 모든 데이터 전송을 마치면, 클라이언트에게 연결을 종료하겠다는 FIN 메시지를 보냄
     
     => 서버는 LAST_ACK 상태가 됨
     
     
4. 클라이언트 → 서버 (ACK)
   
   
   • 클라이언트는 서버의 FIN을 받았다는 마지막 확인 ACK 메시지를 보냄
     
     => 서버는 이 ACK를 받으면 즉시 연결을 닫고 클라이언트는 혹시 모를 네트워크 오류에 대비해 잠시 기다린 후(TIME_WAIT 상태) 연결을 완전히 닫음
     
     (혹시 네트워크 문제로 마지막 ACK가 손실될 수 있으니 재전송에 대응하기 위해)

 

이처럼 양방향으로 각각 종료 의사를 묻고 답하는 4단계 과정을 통해 데이터 유실 없이 안전하게 연결이 종료되는 것임