3-Way Handshake란?

TCP(Transmission Control Protocol) 3-Way Handshake

- TCP 연결이 성립되는 과정

- 양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장함

- ACK = SYN + 1 이므로 SYN을 보낸 client가 ACK를 받을 경우 보낸 SYN + 1을 통해 ACK가 맞는지 검증 가능

- 순차적인 number가 SYN으로 오면 이전의 connection으로부터 오는 packet으로 인식될 수 있으므로 난수로 전달

1. SYN(Synchronize Sequence Number) : Client(Host P)에서 SYN(임의의 숫자)을 보내며 접속을 요청함

-> 연결하자! 암호는 이거야!

2. SYN + ACK(Acknowledgement Number) : Server(Host Q)에서 Client에게 ACK(= SYN + 1)와 SYN을 응답

-> 알았다, 연결하자! 이거 맞지?

3. ACK : ACK(SYN + 1) 응답

-> 맞다!

TCP(Transmission Control Protocol) 4-Way Handshake

- TCP 연결이 해제되는 과정

- 양쪽 모두 연결 해제가 준비되었다는 FIN을 서로 교환해야 함 -> 양쪽 모두 FIN에 대한 ACK를 보내 확인 과정을 거쳐야 하므로 4 way가 최소 과정

1. FIN(Finish) : Client에서 연결 종료를 위한 FIN bit를 Server에 보내고 스스로는 FIN_WAIT_1 상태로 변경, FIN_WAIT_1 상태에서는 Client는 Server의 ACK 응답을 기다림

-> 종료하자!

2. ACK : Server는 ACK를 Client에게 보내고 스스로는 CLOSE_WAIT 상태로 변경

-> 일단 알았다, 보내던 거 마저 보내고!

3. FIN : Client는 Server한테 ACK를 받으면 FIN_WAIT_2 상태로 변경, 이 때 Client는 Server의 FIN 응답을 기다림, Server가 연결을 종료할 준비가 되면 Client에게 FIN을 보내고 스스로 LAST_ACK 상태로 변경

-> 종료하자!

4. ACK : Client가 ACK를 Server에게 보내고 스스로 TIME_WAIT 상태로 변경 후 일정 시간 후에 연결 종료, Server는 ACK를 받으면 연결 종료

-> 알았다!

* Server의 CLOSE_WAIT 상태에서 ACK, FIN을 함께 보내면 되지 않을까? 3-way로 줄일 수 있지 않나?

- Server가 데이터를 다 보내지 않은 상태에서 FIN을 받는 경우, ACK는 바로 보내야 하므로 ACK와 FIN을 같이 보낼 수 없는 상황이 발생함

* TIME_WAIT 시간이 필요한 이유

- TIME_WAIT 상태 중에는 해당 Socket의 주소를 다른 Socket에게 할당하는 것을 막을 수 있음 (응답이 가능)

- ACK가 중간에 유실되어 Server가 전달 받지 못한 경우, Client가 ACK를 다시 보낼 수 있도록 대기 시간이 필요함

- Server가 ACK를 받지 못했다는 걸 Client는 어떻게 알 수 있을까? -> ACK가 오지 않는다면 Server는 다시 FIN을 보낼 것임

출처

IWAN2BFREE