[스크랩] TCP/IP 관련 STATE 내용 (넘넘 중요행!)

 

http://blogs.technet.com/b/escape/archive/2010/01/06/reset.aspx

 

TechNet Blogs » Escape From The Troubles » Reset은 어디서 오는 것일까? (황새가 물어다 주지 않습니다)

Reset은 어디서 오는 것일까? (황새가 물어다 주지 않습니다)

Networking 과 관련된 지원을 하다 보면 network capture에서 TCP Reset frame을 보았다거나 혹은 이로 인해서 network에 어떠한 문제가 있지 않은지 문의하는 경우를 많이 봅니다. 하지만 단지 TCP reset이 있다고 문제가 되는 것은 아닙니다. TCP Reset frame은 다양한 이유에 의해서 나타나게 되는데 이 모든 이유를 문제가 있다고 볼수는 없는 것입니다..

실제로 reset은 좋은점이 있습니다. Reset을 통해서 불필요하게 자주 open되는 connection을 종료할 수 있습니다. 예를 들어 어떤 응용프로그램이 짧은 주기의 TCP connection은 많이 만들고 server 입장에서는 그 connection들을 Time Wait state 동안 유지하지 않기를 원한다면 application은 그 connection을 reset하게 됩니다. 이에 대한 설명은 곧 말씀 드리도록 하겠습니다.

The Three Way Handshake

우선 TCP connection이 무엇인지 먼저 살펴보도록 하겠습니다. 네트워크의 한 노드가 같은 네트워크의 다른 노드와 TCP로 통신을 하기 원한다면, TCP connection을 establish해야 합니다. 이렇게 하기 위해서 노드는 클리이언트로 동작하여 Syn frame(동기화: Synchronization)을 서버 역할을 하는 노드로 보내게 됩니다. 이 packet에는 connection을 establish하고 data를 전송하는데 필요한 많은 정보들이 포함되어 있습니다. 하지만 여기서 가장 흥미로운 점은 port 정보입니다. Connection은 실제로 클라이언트의 source port와 서버의 destination port 사이에 이루어 집니다. 이 Syn frame이 발신자의 Source Port와 대상이 되는 노드와 connection을 establish할 대상 노드의 Destination port 정보를 가지고 있습니다.

다음 frame이 Syn packet의 예제입니다. TCP:Flags= .......S 부분을 보면 Syn frame인지 알 수 있습니다. SrcPort는 Source Port를 의미하며 클라이언트가 connection을 establish할 때 사용할 port입니다. DstPort는 Destination Port를 의미하며 이 경우에는 445이며 Direct SMB port입니다. 서버는 Syn packet을 허용하고 이후 과정을 계속 진행할 수 있도록 해당 port를 listening하고 있어야 합니다.

Connection establishment는 다음 두 frame에서 완료됩니다. 두번째 frame은 Ack, Syn frame입니다. 서버는 첫번째 Syn frame에 대해서 받았다는 Acknowledging(인식)과 함께 자체적인 Syn frame을 보냅니다. 두가지 기능이 같은 frame에서 발생 합니다. Source와 Destination port에 대해서 서버가 source가 되고 클라이언트가 destination이 되는 식으로 상황에 맞게 변경 되는것을 볼 수 있습니다.

마지막 ack는 client에서 서버가 보낸 Syn frame을 받았다는Acknowledging(인식)을 하는 것이고 connection establishment가 완료되었다는 것을 의미합니다.

Connection establish 과정은 일반적으로 Three Way Handshake의 과정을 따릅니다. 이제 두 노드 간에 port set을 통해서 connection이 하나 만들어 지게 되었습니다.

Time Wait state

이미 이전에 Time Wait state에 대해서 언급 하였는데 이것이 어떤 의미이고 왜 중요할까요?

TCP connection이 한쪽에서 gracefully(정상적)으로 종료된다면 Fin frame을 보내게 됩니다. 이는 그 노드에서는 더이상 보낼것이 없다는 것을 의미합니다. 두번재 노드는 이 frame에 대해서 Ack를 하게 되고 그 다음 두번째 노드에서 더이상 보낼것이 없다면 자체에서 Fin을 보내고 이를 첫번째 노드에서는 Ack하게 됩니다.

Fin frame이 양쪽 노드에서 함께 보내진다면 양쪽 노드는 Fin에 대한 Ack를 받게 됩니다. 그 다음에 TCP connection은 Time Wait state로 들어가게 됩니다. 이 connection은 기본값인 4분 동안의 time wait 상태가 지속됩니다. 이는 이 connection을 통과하는 길잃은 packet을 위한 것이며 이를 통해서 정상적으로 두 노드간에 connection을 제거할 수 있게 됩니다.

이제 TCP connection이 어떻게 establish되고 정상적으로 close되는지 알게 되었습니다. 이제 어떻게 그리고 왜 TCP connection을 reset해야 하는지 살펴보도록 하겠습니다.

Resets

Reset은 무엇입니까? TCP reset은 TCP connection을 바로 끊어 버립니다. 이를 통해서 이전 connection에 할당 되었던 자원을 해제하고 시스템을 사용 가능하게 만들어 줍니다.

SMB Reset

SMB Reset은 TCP Reset에서 다루게 될 첫번째 내용입니다. 이 내용은 network traffic을 많이 확인해보지 못했던 고객 그리고 TCP Reset은 항상 나쁜 것이라고 생각하는 고객들로부터 받는 많은 질문중에 하나입니다. 하지만 이러한 동작은 의도된 것입니다.

Windows 2000부터 운영체제는 139 port를 사용하기 보다는 SMB를 위한 445 port를 사용하기를 선호했습니다. 이 과정에서 클라이언트는 두개의 TCP Sync packet, 하나는 destination port가 445인 그리고 나머지 하나는 destination port가 139인 Syn packet을 보내게 됩니다. 더 자세한 내용은 이 blog의 범위를 넘어서게 되지만 기본 개념은 하위 호환성을 보장하기 위한 이유입니다. 서버 노드가 139와 445 port를 모두 listening하고 있다면 서버 노드는 Ack, Syn packet을 139와 445 port 모두에 대해서 응답하게 됩니다. 클라이언트는 그 다음 Ack packet을 선호하는 port로 보내게 되고 다른 port는 reset하게 됩니다. 아래는 그에 대한 예제입니다.

Ack, Reset

두번째는 Syn에 대한 Ack Reset입니다. Ack Reset은 Syn frame에 대한 응답으로, frame을 받았다는 인식(acknowledge)으로 보내집니다. 하지만 서버는 클라이언트에게 해당 port로 connection을 허용할 수 없다는 것을 알려주는 것입니다. Ack, Reset의 이유로는:

1. 클라이언트 노드가 연결하려고 하는 port가 listening 하지 않고 있는 경우

2. 어떠한 이유로 서버 노드가 해당 port로 연결을 완료하지 못한 경우. 예를 들어, 서버의 리소스 부족으로 connection을 허용하는데 필요한 리소스를 할당하지 못하는 경우.

주의: 방화벽 같은 장치는 port에 대해서 실제로 listening하지 않고 있더라도 Ack Reset을 반환하지 않도록 디자인 되어 있습니다. 따라서 Syn frame은 아무 응답없이 버려집니다. 이는 보안을 위한 동작입니다.

TCP Reset due to no response

다음 Reset은 응답 없이 network frame이 6번 보내지고 난후의 TCP Reset입니다.(원본 frame이 보내지고 난 후 추가 5번의 frame retransmit을 의미합니다) 이러한 결과로 보내는쪽 노드에서 connection을 reset합니다. 이는 우리가 three way handshake 이후에 establish된 connection을 가지고 있다는 것을 가정합니다. Reset하기까지 retransmit 갯수는 변경할 수 있으며 기본값은 5입니다.

주의: connection이 establish되었을 때 Syn frame에 대한 retransmit 최대 숫자의 기본값은 2입니다. 하지만 TCPMaxConnectRetransmission 레지스트리 키로 조정할 수 있습니다.

여기에는 중요한 요소들이 있는데 이는 초보자에게는 간과하기 쉬운 내용입니다. 주의깊게 보아야 할 한가지는 retransmit 의 갯수입니다. 이러한 환경에서 sender는 frame을 보내고 그 frame에 대해서 Ack를 받지 못하였습니다. 그리고 TCP는 일반적인 retransmit 동작으로 들어가고 각 시도마다 frame에 대한 Ack를 받지 못하게 됩니다. Packet이 다섯번 retransmit되고난 후 sender는 Ack frame을 위해서 설정된 시간만큼 대기합니다. 여전히 Ack를 받지 못하면 connect에 대해서 reset을 보내게 됩니다. 이러한 가정은 노드간 네트워크에 혹은 Ack가 보내진 노드에 문제가 있다는 것이고 이는 connection이 더이상 유효하지 않음을 의미합니다. 몇가지 주의깊게 볼 내용은:

1. 5개의 packet은 동일한 packet을 의미합니다. 단지 5개의 retransmit packet을 의미하는 것은 아닙니다. 동일한 packet이 5번 retransmit되는 것입니다.

2. Retransmit 이외의 sending node로부터 보내지는 다른 frame이나 Ack는 중요하지 않습니다.

3. Late Acknowledgement는 이 문제를 일으키지 않습니다. Late acknowledgement는 Acknowledgement가 보내지기전에 Retransmit Time Out(RTO)가 만료되어 frame이 retransmit되고 그런 다음 Acknowledgement가 도달한 경우 발생 합니다.

Application Reset

이 현상에 대해서도 많은 문의가 있었고 불행하게도 전형적으로 제거process에 의한 것으로 확인됩니다. 다른 말로는, application에 의해서 일으켜 지는 것이지 reset에 다른 이유는 없는 것입니다. 이렇게 대답하는 것이 꺼려지지만 더 설명할 답이 없습니다. 만약 여러분이 network traffic을 살펴 봤을 때 앞에서 살펴본 예제와 같은 이유가 아닌 아무런 이유 없이 TCP에 대해서 자체적으로 reset을 보낸다면 이는 application에 의해서 보내지는 것입니다. 첫번째 구문에서 언급했듯이 이는 정상적이며 바람직한 동작일 것입니다. 이것은 짧은 주기의 TCP connection을 많이 생성하는 응용프로그램의 일반적인 용법입니다. 이러한 응용프로그램은 많은 Time Wait state 상태의 port를 생성하여 포트 고갈 현상을 초래할 수 있습니다. 하지만 응용프로그램 개발자는 모든 connection을 reset하기에 앞서서 왜 Time Wait state가 존재하는지 이해할 필요가 있습니다.

Note: 응용프로그램의 code를 보고 Winsock function close(socket)가 실행중인지 확인해 보세요. 만약 data가 설정된 connection에 이러한 동작이 수행된다면 Reset이 발생하게 됩니다. 또한 Winsock logging을 확인할 수 있습니다. 만약 이 function 이 단지 Three Way Handshake가 완료되고 data가 전송되지 않은 connection에 서 호출되었다면 Fin frame을 통한 정상적은 connection close가 일어나게 됩니다.

다른 가능성으로는(가능성이 낮긴 하지만) destination 노드의 다른 process가 그 port를 점유하고 있는 경우 발생할 수 있습니다. 이러한 문제는 system이 부팅할 때 두 응용프로그램이 동일한 port에 대해서 listening하려고 할 경우 발생할 수 있습니다.

For advanced users and network Admins

“Reset은 네트워크로 부터”는 B 영화의 제목 같네요. 하지만 실제로 발생할 수 있고, 만약 여러분이 왜 reset이 발생하는지 잘 알지 못한다면 확인하기가 무척이나 어렵습니다.

무슨 일이 일어날 수 있는가 하면 라우터나 방화벽 같은 장비가 네트워크에 존재하고 이러한 장비들이 실제로 connection을 reset할 수 있습니다. 이는 혼란스러울 수 있는데 왜냐하면 sending 노드와 receiving 노드의 source 그리고 destination IP address가 중간에 있는 장비의 것이 아니기 때문입니다. 이러한 특별한 reset 문제를 확인하는 방법은 source와 destination 노드에서 모두 trace를 수집하는 것입니다. Network capture에서는 한 노드에서 받은 reset이 이 packet을 보냈으리라고 예상되는 노드의 capture에서는 확인되지 않기 때문입니다. 이러한 문제가 일어나는 여러가지 이유가 있고 또 이에 대한 주제로 다른 blog 문서를 쓸 수 있지만 여기서 이해해야 하는 중요한 점은 이러한 문제가 가능하다는 것입니다. 또한 제가 쓴 blog들에서 source와 destination network capture를 수집하는 것이 중요하다고 강조한 부분을 보실 수 있는데 이 이유도 한가지 입니다.

또다른 흥미로운 사실은 중간의 장비에서 reset은 클라이언트와 서버 노드 모두의 connection 을 reset할 수 있다는 것입니다. 우리가 두 노드간에 TCP connection을 setup 하였다고 가정해 보겠습니다. Source IP 10.10.10.20, Destination IP 10.10.10.30 그리고 TCP port 2301과 445 사이에 connection이 있습니다. 여기서 볼 수 있는 것은 reset packet이 10.10.10.20 destination port 2301과 다른 reset packet이 10.10.10.30 destination port 445로 모두 보내지는 것을 볼 수 있습니다.

Port re-use

만약 응용프로그램이 Time Wait 상태의 port를 재사용하려고 한다면 Reset이 발생할 수 있습니다. 이러한 현상은 클라이언트와 서버가 connection을 가지고 graceful close 과정을 거치고 Time Wait으로 되었을 때 발생할 수 있습니다. 동일한 클라이언트가 동일한 port 쌍을 재사용 하기 위해서 Syn frame을 동일한 source와 destination port로 보낼 수 있습니다. RFC 1122에 따라 이러한 동작은 허용되며 정상적으로 동작하게 됩니다. 이는 주의깊게 수행되어야 하고 Time Wait로 port가 남겨지는 이유가 있음을 기억해야 합니다. 주의해야 할 점은 Syn frame의 Sequence 넘버인데 기존 connection을 사용하여 새로운 connection을 establish하는 frame은 기존 connection의 마지막 frame의 sequence 넘버보다 반드시 커야 합니다. 만약 그렇지 않으면 reset이 발생할 수 있습니다.

In Summary

TCP Reset은 나쁜것이 아닙니다. 유용한 도구이며 TCP reset이 없이는 네트워크에서 TCP가 connectivity 문제를 맞닥드렸을 때 모든 문제로 남겨질 수 있습니다. Reset은 network stack이나 application 모두에서 발생할 수있음을 기억하세요. 단지 retransmit packet이 있다고 connection 이 reset이 되는것을 의미하는것이 아닙니다. Frame을 조사하고 왜 retransmit이 발생하는지 이해하는 것이 중요합니다.

- Clark Satter