Network_03) 손 3개가 아닌 3개의 단계별 악수법 입니다.

Topic (오늘의 주제)

3-way handshake는 TCP(Transmission Control Protocol)에서 두 호스트 간의 연결을 설정하기 위해 수행하는 3단계 과정입니다. 클라이언트와 서버가 서로의 통신 준비 상태를 확인하고 시퀀스 번호를 동기화하여 신뢰성 있는 연결을 수립합니다.

---

Why (왜 사용하는가? 왜 중요한가?)

• TCP는 연결 지향형 프로토콜이므로 데이터 전송 전에 연결을 설정해야 합니다. 3-way handshake를 통해 양쪽 모두 통신 준비가 되었음을 확인하고, 시퀀스 번호를 동기화하여 데이터의 순서를 보장할 수 있습니다.

• 3-way handshake의 각 단계에서 사용되는 플래그(SYN, ACK)의 의미, 시퀀스 번호와 확인 응답 번호의 역할, 그리고 연결 해제 과정인 4-way handshake와의 차이를 이해해야 합니다.

---

1. 3-way Handshake란?

3-way Handshake의 정의

3-way handshake는 TCP 연결을 설정하기 위해 클라이언트와 서버가 3번의 패킷을 주고받는 과정입니다.

왜 3번인가?

• 1번: 클라이언트 → 서버 (연결 요청)
• 2번: 서버 → 클라이언트 (연결 수락 + 확인)
• 3번: 클라이언트 → 서버 (확인 응답)

양쪽 모두 상대방의 통신 준비 상태를 확인하기 위해 최소 3번의 패킷 교환이 필요합니다.

---

2. 3-way Handshake 과정

전체 흐름도

클라이언트                    서버
    |                         |
    |---- SYN (seq=x) ------->|  [1단계: 연결 요청]
    |                         |
    |<-- SYN-ACK (seq=y, ack=x+1) --|  [2단계: 연결 수락 + 확인]
    |                         |
    |---- ACK (ack=y+1) ------>|  [3단계: 확인 응답]
    |                         |
  [연결 설정 완료]
  [데이터 전송 시작 가능]

1단계: SYN (Synchronize) - 연결 요청

클라이언트 → 서버

클라이언트가 서버에 연결을 요청합니다.

TCP 헤더:
- SYN = 1 (연결 요청 플래그)
- Sequence Number = x (초기 시퀀스 번호, 랜덤 값)
- ACK = 0

의미:

• 클라이언트가 서버에 "연결하고 싶다"고 요청
• 초기 시퀀스 번호(x)를 서버에 알림
• 클라이언트는 서버의 응답을 기다림 (SYN_SENT 상태)

2단계: SYN-ACK (Synchronize-Acknowledgment) - 연결 수락 + 확인

서버 → 클라이언트

서버가 연결을 수락하고 클라이언트의 요청을 확인합니다.

TCP 헤더:
- SYN = 1 (연결 수락 플래그)
- ACK = 1 (확인 응답 플래그)
- Sequence Number = y (서버의 초기 시퀀스 번호, 랜덤 값)
- Acknowledgment Number = x + 1 (클라이언트의 시퀀스 번호 + 1)

의미:

• 서버가 "연결을 수락한다"고 응답
• 서버의 초기 시퀀스 번호(y)를 클라이언트에 알림
• 클라이언트의 요청(x)을 받았다는 확인 (ack = x + 1)
• 서버는 클라이언트의 최종 확인을 기다림 (SYN_RECEIVED 상태)

3단계: ACK (Acknowledgment) - 확인 응답

클라이언트 → 서버

클라이언트가 서버의 응답을 확인합니다.

TCP 헤더:
- ACK = 1 (확인 응답 플래그)
- Acknowledgment Number = y + 1 (서버의 시퀀스 번호 + 1)
- SYN = 0 (이제 일반 데이터 전송 단계)

의미:

• 클라이언트가 서버의 응답(y)을 받았다는 확인 (ack = y + 1)
• 이제 양쪽 모두 연결이 설정되었음을 확인
• 데이터 전송 시작 가능 (ESTABLISHED 상태)

---

3. 각 단계의 상태 변화

클라이언트 상태 변화

CLOSED
  ↓
[1단계: SYN 전송]
  ↓
SYN_SENT (서버 응답 대기)
  ↓
[2단계: SYN-ACK 수신]
  ↓
[3단계: ACK 전송]
  ↓
ESTABLISHED (연결 완료, 데이터 전송 가능)

서버 상태 변화

LISTEN (연결 요청 대기)
  ↓
[1단계: SYN 수신]
  ↓
[2단계: SYN-ACK 전송]
  ↓
SYN_RECEIVED (클라이언트 확인 대기)
  ↓
[3단계: ACK 수신]
  ↓
ESTABLISHED (연결 완료, 데이터 전송 가능)

---

4. 시퀀스 번호(Sequence Number)의 역할

시퀀스 번호란?

시퀀스 번호(Sequence Number)는 TCP에서 데이터의 순서를 보장하기 위해 사용하는 번호입니다.

3-way Handshake에서의 시퀀스 번호

1단계: 클라이언트의 초기 시퀀스 번호 (ISN - Initial Sequence Number)

클라이언트: seq = x (랜덤 값, 보안을 위해 예측 불가능하게 설정)

2단계: 서버의 초기 시퀀스 번호

서버: seq = y (랜덤 값)
서버: ack = x + 1 (클라이언트의 다음 시퀀스 번호 기대)

3단계: 클라이언트의 확인 응답

클라이언트: ack = y + 1 (서버의 다음 시퀀스 번호 기대)

시퀀스 번호 동기화의 의미

양쪽 모두 상대방의 초기 시퀀스 번호를 알고 있으므로, 이후 데이터 전송 시 순서를 보장할 수 있습니다.

클라이언트는 서버의 초기 시퀀스 번호 y를 알고 있음
  → 서버로부터 받을 데이터의 시작 번호를 알 수 있음

서버는 클라이언트의 초기 시퀀스 번호 x를 알고 있음
  → 클라이언트로부터 받을 데이터의 시작 번호를 알 수 있음

---

5. 3-way Handshake가 필요한 이유

1. 양방향 통신 준비 확인

TCP는 전이중 통신(Full-duplex)을 지원하므로 양쪽 모두 송신과 수신이 가능해야 합니다.

클라이언트 → 서버: 클라이언트의 송신 준비 확인
서버 → 클라이언트: 서버의 송신 준비 확인

2. 시퀀스 번호 동기화

데이터의 순서를 보장하기 위해 양쪽 모두 상대방의 초기 시퀀스 번호를 알아야 합니다.

클라이언트: 서버의 초기 시퀀스 번호 y를 알고 있음
서버: 클라이언트의 초기 시퀀스 번호 x를 알고 있음

3. 연결의 유효성 검증

양쪽 모두 상대방이 실제로 존재하고 통신 가능한 상태인지 확인합니다.

클라이언트: 서버가 SYN-ACK로 응답 → 서버 존재 확인
서버: 클라이언트가 ACK로 응답 → 클라이언트 존재 확인

4. 중복 연결 방지

이미 존재하는 연결과 구분하여 새로운 연결을 설정합니다.

---

6. 4-way Handshake (연결 해제)

연결 해제 과정

TCP 연결을 해제할 때는 4-way handshake를 사용합니다.

클라이언트                    서버
    |                         |
    |---- FIN (seq=x) ------->|  [1단계: 연결 종료 요청]
    |                         |
    |<---- ACK (ack=x+1) -----|  [2단계: 종료 요청 확인]
    |                         |
    |                         |  [서버가 남은 데이터 전송]
    |                         |
    |<---- FIN (seq=y) -------|  [3단계: 서버 종료 요청]
    |                         |
    |---- ACK (ack=y+1) ------>|  [4단계: 종료 확인]
    |                         |
  [연결 해제 완료]

왜 4번인가?

TCP는 전이중 통신이므로 양쪽 모두 독립적으로 연결을 종료할 수 있습니다.

• 클라이언트 → 서버: 클라이언트의 송신 종료
• 서버 → 클라이언트: 서버의 송신 종료

각각 2단계씩 필요하므로 총 4단계가 필요합니다.

---

7. 3-way Handshake의 문제점과 해결

SYN Flooding 공격

공격 방법:

공격자가 서버에 대량의 SYN 패킷을 전송
  → 서버는 SYN_RECEIVED 상태로 대기
  → 서버의 리소스 고갈

해결 방법:

• SYN Cookie: 서버가 리소스를 할당하지 않고 쿠키로 응답
• 연결 수 제한: 동시 연결 수를 제한
• 방화벽 설정: 의심스러운 IP 차단

---

요약

• 3-way handshake는 TCP 연결을 설정하기 위해 클라이언트와 서버가 3번의 패킷을 주고받는 과정입니다.

• 1단계 (SYN): 클라이언트가 서버에 연결 요청 (초기 시퀀스 번호 x 전송)

• 2단계 (SYN-ACK): 서버가 연결 수락하고 클라이언트의 요청 확인 (초기 시퀀스 번호 y 전송, ack = x + 1)

• 3단계 (ACK): 클라이언트가 서버의 응답 확인 (ack = y + 1)

• 목적: 양방향 통신 준비 확인, 시퀀스 번호 동기화, 연결의 유효성 검증

• 연결 해제는 4-way handshake를 사용하며, 양쪽 모두 독립적으로 종료할 수 있기 때문에 4단계가 필요합니다.

---

참고 자료

• RFC 793 - Transmission Control Protocol
• TCP/IP Illustrated, Volume 1

---

예상 꼬리질문 정리

1. 왜 2-way handshake가 아닌 3-way handshake인가?

2-way handshake의 문제점:

만약 2-way handshake만 사용한다면:

클라이언트                    서버
    |                         |
    |---- SYN (seq=x) ------->|
    |                         |
    |<-- SYN-ACK (seq=y, ack=x+1) --|
    |                         |
  [연결 완료?]

문제점:

• 클라이언트는 서버의 응답을 받았지만, 서버는 클라이언트가 자신의 응답을 받았는지 확인할 수 없음
• 네트워크 지연으로 인한 중복 패킷 문제 해결 불가
• 양방향 통신 준비 상태를 완전히 확인할 수 없음

3-way handshake의 장점:

• 양쪽 모두 상대방의 통신 준비 상태를 확인
• 시퀀스 번호 동기화 완료
• 연결의 유효성 검증

2. 시퀀스 번호가 랜덤 값인 이유는?

보안상의 이유:

• 예측 가능한 시퀀스 번호는 TCP Sequence Number Prediction 공격에 취약
• 공격자가 시퀀스 번호를 예측하여 가짜 패킷을 주입할 수 있음

랜덤 값 사용:

• 초기 시퀀스 번호(ISN)를 랜덤하게 생성
• 공격자가 시퀀스 번호를 예측하기 어려움
• 보안 강화

3. 3-way handshake 중 패킷이 손실되면?

1단계 (SYN) 손실:

클라이언트가 SYN을 보냈지만 서버가 받지 못함
  → 클라이언트는 타임아웃 후 SYN 재전송

2단계 (SYN-ACK) 손실:

서버가 SYN-ACK를 보냈지만 클라이언트가 받지 못함
  → 서버는 타임아웃 후 연결 종료
  → 클라이언트는 타임아웃 후 SYN 재전송

3단계 (ACK) 손실:

클라이언트가 ACK를 보냈지만 서버가 받지 못함
  → 서버는 타임아웃 후 SYN-ACK 재전송
  → 클라이언트는 이미 ESTABLISHED 상태이므로 RST 전송
  → 또는 서버가 타임아웃 후 연결 종료

재전송 메커니즘:

• TCP는 타임아웃과 재전송 메커니즘을 통해 패킷 손실에 대응
• 일정 시간 내 응답이 없으면 패킷을 재전송

4. 3-way handshake와 4-way handshake의 차이는?

구분	3-way Handshake	4-way Handshake
목적	연결 설정	연결 해제
단계 수	3단계	4단계
플래그	SYN, SYN-ACK, ACK	FIN, ACK, FIN, ACK
양방향	양쪽 모두 연결 준비	양쪽 모두 독립적으로 종료

4-way handshake가 4단계인 이유:

• TCP는 전이중 통신이므로 양쪽 모두 독립적으로 종료 가능
• 클라이언트의 송신 종료 (FIN → ACK)
• 서버의 송신 종료 (FIN → ACK)
• 총 4단계 필요

5. UDP는 왜 handshake가 없는가?

UDP의 특성:

• 비연결형 (Connectionless): 연결 설정 없이 데이터 전송
• 빠른 전송: 연결 설정 과정 없이 즉시 전송
• 신뢰성 없음: 순서 보장, 재전송 없음

UDP에 handshake가 없는 이유:

• 연결을 설정할 필요가 없음
• 데이터를 보내면 끝 (Best-effort delivery)
• 신뢰성 보장이 필요 없음

반면 TCP:

• 연결 지향형이므로 연결 설정 필요
• 신뢰성 보장을 위해 시퀀스 번호 동기화 필요
• 3-way handshake로 연결 설정

---