Time-wait은 왜 발생하는가?

주로 두가지 이유가 존재한다.

    1) client가 보낸 요청이 유실되었을 때를 대비하기 위해서이다.

- client 입장에서는 마지막으로 ack를 보내면 클라이언트가 할 일은 모두 종료된다.

 

- 그렇지만, 이때 중간에 마지막 ack K+1 이 없어지면 상황은 복잡해진다.

       => TCP는 신뢰성 보장을 위해서 데이터를 보내면 응답을 받아야 되기 때문에 일정 시간 지나도 응답이 오지 않으              면 신뢰성 보장을 위해 다시 재전송한다.

 

- 마지막 ACK가 유실되었다는 것은 server가 보낸 FIN에 대한 ACK이므로 서버는 FIN을 다시 보내게 된다

=> 사실 서버 입장에서는 서버 자신이 보낸 FIN이 없어진건지, 상대방이 보낸 ACK이 없어진 것인지 구별이 불가하다.

 

# 이 상황에서 client가 기다리지 않고 연결을 끊어버렸다면, 다시 보낸 FIN을 처리해줄 Client가 존재하지 않는다. (이미 close 상태로 접어들어 버퍼, 소켓이 모두 제거된 상태이기 때문이다.)

        => 이를 방지하기 위해 client는 2MSL정도 기다린 다음에 연결을 종료한다.

 

 

 

2) client가 서버와 데이터를 교환 후 종료하고, 새로운 connection을 바로 만들게 될 때, 만약 기존 connection과 같은 포트 번호 사용시 서버 입장에서는 이전 connection의 데이터와 이번 connection의 데이터가 혼재할 시 구별할 방법이 없다.

=> Time wait를 하게 될 시 새로운 connection이 진행되어도 이전 포트는 사용 중이므로 client가 새로운 port number를 할당해 구별할 수 있게 된다.

 

 

 

=>만약 Time wait이 없다고 가정해보자. 그렇다면 1번째 connection이 종료되면 연결이 바로 끊어진다. 이때, client가 갑자기 할 일이 남아서 다시 연결 요청을 했을 때, 1번째 connection에서 보냈던 패킷이 잘못된 라우팅으로 인해 헤매다가 이제 도착을 했다고 쳐보자.

 

: 서버는 상대방을 port, ip주소로 구별하게 되는데, 우연히 connection 2도 connection 1과 같은 포트를 배정받았다고 생각해보자. 이때 만약 또 우연히 connection 1 패킷의 sequence number와 connection 2 패킷의 seq num이 차이가 별로 나지 않는다고 하면, 서버는 아예 이 패킷이  connection 1에서 출발한 패킷인지, connection 2에서 출발한 패킷 인지 구별이 불가해진다.

 

=> 이 때 해결 방법은, 2nd connection에서는 1st connection에서 사용했던 포트 번호를 아예 사용하지 못하게 하는 것이다. 이를 위해 만약 1st connection을 바로 끊어버리는 대신 2MSL 정도 살려둔다면 2nd connection은 이미 사용중인 포트 번호는 사용할 수 없으니 완전히 다른 포트 번호를 할당받게 될 것이다. 따라서 서버는 1st connection에서 잃어버렸던 패킷이 2nd Connection에서 뒤늦게 들어와도 완벽하게 구별이 가능하다.