TCP 통신 에서 Handshake는 연결 수립/종료를 위해 필요한 과정이다.서버는 FIN 플래그를 받았다. 즉, 서버는 더 이상 수신 받을 데이터가 없다는 뜻이다. 그러나 클라이언트는 아직 FIN 플래그를 받지 못했다. 즉, 대기 상태이다. TCP는 양방향(전이중, Full duplex) 통신이다. 클라이언트는 데이터 전송을 끝냈지만, 서버는 여전히 데이터를 전송하고 있을 수 있다. 그런데 ACK를 보내면서 자신도 FIN 데이터를 보내는 순간에 이미 또다른 데이터를 보내는 상황이라면? 그렇게 되면 원래 클라이언트로 보내져야 할 데이터는 유실된다! 따라서, 서버가 ACK를 보낼 때 FIN 헤더를 같이 보낼 수 없는 것이다.
- 3 way Handshake
- 연결 수립시 진행한다. 간략화한 흐름은 다음과 같다.
- Client 의 SYN 패킷 전송
- Sever의 SYN + ACK 패킷 전송
- Client의 ACK 패킷 전송
- 그러면 여기서 왜 총 3번의 과정을 거치는 것일까? (2번이나 4번이 아니라)
- 최초에 패킷을 보낼 때 헤더에 ISN(Initial Sequence Number)라는 것을 포함해서 보낸다. 알다시피 TCP는 혼잡제어가 중요한 통신 프로토콜 중 하나이다. 따라서 주고 받는 패킷의 순서 보장을 위해 ISN을 포함시킨다.
- 그래서, 두 연결 주체는 각자 서로의 ISN을 기준으로 몇번째 패킷을 받고 있는지를 알 필요가 있다.(TCP는 양방향 통신이니까)
- 이 때, 2번의 SYN + ACK 패킷의 응답 과정은 결국 클라이언트의 ISN을 수신하였음을 알려줌과 동시에 서버도 클라이언트에 ISN을 발신하는 과정을 나타낸다.
- 만약, 2번의 과정을 거치게 되면 ISN 수신을 한쪽만 받게 된다.(클라이언트 → 서버) 따라서, 두 연결 주체가 모두 연결 수립이 완료되어 패킷을 주고 받을 수 있다는 것을 알려주기 위해 3번의 Handshake 과정을 거치는 것으로 이해할 수 있다
- 4 way Handshake
- 연결 종료시 진행한다. 간략화한 흐름은 다음과 같다.
- Client는 Server로 FIN Header를 보낸다.
- Server는 Client로 ACK Header를 보낸다.
- Server는 Client로 FIN Header를 보낸다.
- Client는 Server로 ACK Header를 보낸다.
- 그러면 여기서 왜 총 4번의 과정을 거치는 것일까? (3번이 아니라)
- 먼저, 클라이언트가 서버에 FIN 플래그를 보낸 상황을 생각해보자.
Client ------FIN-----> Server Client <-----ACK------ Server
요약
요약: 3-Way는 양측이 서로 ISN을 보내야 해서, 4-Way는 한쪽이 보내는 데이터가 유실될 수 있어서. 반드시 그렇게 해야만 한다.