TCP 3-way와 4-way 핸드셰이크 (TCP 3-way and 4-way Handshake)

TCP 3-way 핸드셰이크(three-way handshake)는 연결을 시작할 때 클라이언트와 서버가 세 번의 패킷 교환으로 서로의 통신 의사와 초기 순서 번호를 확인하는 절차이다. 4-way 핸드셰이크(four-way handshake)는 연결을 끝낼 때 양쪽이 각자 보낼 데이터가 없음을 알리고 확인하는 네 번의 교환 절차이다. TCP가 신뢰성 있는 양방향 통신을 보장하기 위한 시작과 끝의 약속이라고 할 수 있다.

연결 수립이 필요한 이유

TCP는 바이트 스트림을 순서대로, 빠짐없이 전달하는 것을 약속하는 프로토콜이다. 이를 위해 각 바이트에 순서 번호(sequence number)를 붙이고 수신 확인(ACK, acknowledgment)을 주고받는데, 통신을 시작하려면 양쪽이 서로의 시작 순서 번호(ISN, Initial Sequence Number)를 알고 있어야 한다. 또한 상대가 실제로 수신 준비가 되어 있는지도 확인해야 한다. 3-way 핸드셰이크는 이 두 가지, 즉 양방향 통신 가능 여부 확인과 ISN 교환을 최소 횟수로 달성하는 절차이다. ISN을 0부터 시작하지 않고 예측하기 어렵게 만드는 이유는 이전 연결의 지연 패킷과의 혼동, 그리고 순서 번호를 추측한 세션 탈취 공격을 막기 위해서이다.

3-way 핸드셰이크의 과정

1. SYN: 클라이언트가 SYN(synchronize) 플래그를 세운 패킷에 자신의 ISN을 담아 보내고 SYN_SENT 상태가 된다.
2. SYN+ACK: 서버는 클라이언트의 ISN에 1을 더한 확인 번호와 함께 자신의 ISN을 담은 SYN+ACK 패킷을 보내고 SYN_RECEIVED 상태가 된다.
3. ACK: 클라이언트가 서버 ISN에 1을 더한 확인 번호로 ACK를 보내면 양쪽 모두 ESTABLISHED 상태가 되고 데이터 전송이 시작된다.

두 번의 교환으로 부족한 이유는 서버 입장에서 자신의 SYN이 클라이언트에 잘 도착했는지 알 수 없기 때문이다. 세 번째 ACK가 있어야 양쪽 모두 "내 송신과 수신이 모두 동작한다"는 확신을 갖는다. 한편 서버가 SYN을 받고 ACK를 기다리는 반쯤 열린 상태를 대량으로 만들어 자원을 고갈시키는 SYN 플러딩(SYN flooding) 공격이 있으며, 서버가 상태를 저장하지 않고 검증 정보를 순서 번호에 인코딩해 돌려보내는 SYN 쿠키(SYN cookie)로 방어한다. 최신 환경에서는 이전 연결에서 받은 쿠키로 첫 SYN에 데이터를 실어 왕복을 아끼는 TCP Fast Open도 있고, QUIC은 아예 전송 연결과 TLS 협상을 한 번의 핸드셰이크로 합쳤다.

4-way 핸드셰이크의 과정

TCP는 양방향 채널이 독립적이므로 종료도 방향별로 따로 닫는다. 클라이언트가 먼저 닫는 경우의 흐름은 다음과 같다.

1. FIN: 클라이언트가 보낼 데이터가 끝났음을 알리는 FIN(finish) 패킷을 보내고 FIN_WAIT_1 상태가 된다.
2. ACK: 서버가 FIN을 확인하는 ACK를 보내고 CLOSE_WAIT 상태가 된다. 클라이언트는 FIN_WAIT_2로 넘어가며, 서버는 아직 남은 데이터를 마저 보낼 수 있다.
3. FIN: 서버도 전송을 마치면 자신의 FIN을 보내고 LAST_ACK 상태가 된다.
4. ACK: 클라이언트가 마지막 ACK를 보내고 TIME_WAIT 상태로 들어간다. 서버는 이 ACK를 받으면 즉시 연결을 닫는다.

이렇게 한쪽만 닫힌 반이중 상태(half-close)를 허용하는 덕분에, 클라이언트가 요청 전송을 끝냈다고 알린 뒤에도 서버의 긴 응답을 끝까지 받을 수 있다. 수립은 3번, 종료는 4번인 이유가 여기서 드러난다. 수립 때는 서버가 SYN과 ACK를 한 패킷에 합쳐 보낼 수 있지만, 종료 때는 상대의 FIN을 확인하는 시점과 자신이 보낼 데이터를 다 보내는 시점이 다를 수 있어 ACK와 FIN이 분리되는 것이 일반적이기 때문이다.