• TCP 연결 상태 의미 . . . . 16 matches
       #keywords Network,TCP,TIME_WAIT
       3/4-way Terminate를 거쳐 종료된다. 3-way Terminate는 3-way Handshake와 비슷하게 FIN+ACK를 주고 받는다. 아직 호스트 B(passive close) 측에서 처리할 게 남았다면 ACK를 먼저 보내고 처리가 끝난 다음 FIN 전송. 이런 경우 4-way Terminate이라고 한다. 호스트 B가 바로 종료하지 않고 종료를 받았다는 ACK를 보내주기 위해 CLOSE_WAIT 상태가 필요하다. (TIME_WAIT는 뒤에 더 자세히 설명)
       '''TIME_WAIT''': 연결이 완전히 종료된 후에 원격의 수신 보장을 위해 일정 시간 기다리는 상태. 아래에 더 자세히 설명. FIN 패킷을 수신한 후, ACK 패킷을 보내고 CLOSED 하지 않고 일반적으로 2MSL(Maximum segment lifetime) 동안 이 상태를 유지한다. (Apache에서 KeepAlive를 OFF로 해둔 경우, Tomcat 서버를 쓰는 경우 등에서 이 상태를 자주 볼 수 있다.)
        * 종료 요청을 한 호스트(active close)에서는 FIN_WAIT1, FIN_WAIT2, TIME_WAIT 상태가,
       === TIME_WAIT 상태를 유지하는 이유 ===
       TIME_WAIT가 필요한 이유는 2가지가 있다. 《Unix Network Programming》에서는 TIME_WAIT 상태가 있는 이유에 대해 다음과 같이 설명한다.
       첫 번째 이유는 원격의 종료까지 확인하여 신뢰성 있는 연결 종료를 위한 것이고, 두 번째 이유는 만료된 연결의 패킷 제거를 위해서인데, 종료한 소켓이 TIME_WAIT 상태에서 금방 사라지지 않는 이유가 두 번째 이유 때문이다. 이런 상황을 가정할 수 있다. 둘이 패킷을 주고 받다가 정상적으로 연결을 끊었다. 그리고 둘이 곧바로 연결을 해서 방금 전과 같은 포트로 연결되었다. 여기서 문제가 발생하는데 이전에 연결이 되었을 때 보낸 패킷이 라우터의 일시적인 오류로 네트워크를 뱅뱅 돌다가 다시 새로운 연결이 되었을 때 도착할 수 있다. 즉, 모든 패킷 순서를 엄격히 보장하는 TCP에서 원하지 않는 데이터가 수신되었으니 네트워크 오류가 발생할 수 있다. 이 때 TIME_WAIT 상태를 유지하면 같은 포트를 다른 프로세스가 다시 이용하는 것을 막는다. 같은 연결이 발생하지 못하도록 방지한다. 그리고 TIME_WAIT 상태는 2 MLS 시간 동안 유지한다. 즉, 네트워크에 패킷이 존재하는 시간보다 두 배 길게 설정된다. 따라서 TIME_WAIT 상태가 끝나면 네트워크 상에는 이전 연결에 보내졌던 패킷이 모두 소멸되었다고 확신할 수 있으므로 새로운 연결을 만들어도 문제가 발생하지 않을 것이다.
        * TIME_WAIT로 인해 부하가 걸리지는 않는다. 실제로 웹 서버를 운영하면 TIME_WAIT 상태가 수십, 수백 개 생기기도 한다. 수십 개 정도는 일반적인 수준이다.
       {{{+1 TIME_WAIT를 없애는 방법 }}}
       기술적으로 없애는 방법만 간단히 소개한다. 소켓 옵션 중 linger option을 off 시키면 연결 종료 시 TIME_WAIT 상태를 거치지 않고 CLOSED 상태로 바뀌게 된다. TIME_WAIT가 너무 많아 문제가 생기는 경우는 별로 없다. 이를 적용하면 오히려 통신이 불안정해질 수 있고 그 이유는 위에서 설명했다.
• LocalKeywords . . . . 1 match
       Network TCP TIME_WAIT

You can also click here to search title.