미들웨어 장애 진단 : 네트워크 패킷 드랍에 대해

- 작성일 : 2024.09.12

 

미들웨어 (웹서버, 와스서버)는 장애가 발생하면 언제나 점검해야되는 대상 중에 첫번째로 늘 거론되는 제품이다.

사용자 서비스가 지연이 되거나 무한루프를 도는 경우 미들웨어를 먼저 점검한 후 데이터베이스, 서버, 네트워크, 보안 장비 등을 점검하는 순으로 장애를 처리하는게 일반적인 것같다.

 

그래서 미들웨어 엔지니어는 미들웨어 자체 기술력 뿐만 아니라, DBMS, OS, Network, Security Appliance 등에 대한 다양한 기술력을 어느정도 가지고 있는 것이 중요한 것같다. 그리고 자기 제품에 대한 문제가 없는 것을 입증하기 위해 다양한 방법론과 접근방식을 가지고 있어서 잘하고 오래 견딜 수 있는 실력자가 되는 것같다.

 

최근 보안장비에서 패킷을 드랍(Drop)시키면서 장애가 발생하는 케이스가 있어서,

미들웨어 단에서 이를 증명하기 위한 방법들을 확인하던 중에 TCP Packet상태를 중심으로 설명해보겠다.

 

네트워크 보안장비에서 사용자 요청 패킷을 2중화된 장비 간에 Health Check가 문제로, 정상적인 패킷인데도 Client 단에 RESET 패킷을 날리는 경우가 있었다. 이런 경우 해당 보안장비는 하단에 웹서버로 보낸 요청을 처리하지 못하고 Timeout 될 때 까지 pending되는 경우가 있었다. 불행히고 Client단에 RESET 패킷이 정상적으로 도달했으면 Client는 바로 에러를 수신하고, Refresh 동작을하면 되는데, 하필이면 RESET패킷을 보내는 장비가 2중화된 장비 중에 Health Check 실패로 다른 장비에서 보내다 보니 해당 Client는 RESET패킷을 받지도 못하고, 브라우져에 하얀 화면이 계속 떠있으면서 Pending되는 경우가 발생하게 되었다.

 

이런 경우 웹서버에서는 무슨 일이 있어나냐면, 해당 패킷에 대한 요청이 보안장비로 부터 내려오기는 하므로,

해당 요청에 대한 처리를 완료한 후 Client 패킷에 Response를 Write할려는데 해당 패킷이 정상적으로 Client와 연결되어있지 않기 때문에 에러를 출력하고 해당 요청을 종료하게 된다.

그러면서 고개들은 사용자 화면이 멍때리는 걸로 보여지면서 미들웨어에서 처리가 펜딩되거나, 비정상적으로 패킷이 드랍된것은 아닌지 의문을 가지게 된다.

 

이런 기회를 살려, 해당 클라이언트 IP를 확인해서 netstat 명령을 통해 정상적으로 client 가 disconnect되는 타이밍에 TCP 패킷 상태를 확인해보기로 하였다.

 

역시나 netstat 확인시 웹서버 단에서는 RESET 패킷을 보내지 않고 있었으며,

FIN 패킷조차도 보이질 않았다.

 

자세한 내용은 TCP Dump 를 통해 확인해봐야했지만 말이다.

 

이렇게 웹서버 단에서는 연결을 끊지 않고 있다고 밝혀주면서 자연스럽게 네트워크 보안장비로 눈을 둘리게 되었고,

특정 장비에서 패킷이 드랍되는 상황이 발생하고 있는 것을 확인하여 해당 장비 문제를 집중적으로 들어다볼 수 있게 되었다.

 

---

 

참고로 TCP Handshake 동작 중에 Client와 연결을 끊는 동작은 2가지로 종류로 이루어진다.

첫번째는 정상적으로 Connection이 종료되는 경우이고, 두번째는 비정상적으로 Connection이 종료되는 경우이다.

 

먼저 TCP 연결이 정상적으로 종료되는 과정을 확인해보자.

 

TCP 연결을 끊는 과정은 4-way handshake를 통해 이루어진다. 이 과정은 클라이언트와 서버가 순차적으로 연결을 종료하는 방식으로, 양쪽 모두가 데이터를 더 이상 주고받지 않을 준비가 되었을 때 연결을 끊게 된다.

TCP 연결을 끊는 과정은 다음과 같습니다:

 

1. FIN 패킷 전송:  
   - 클라이언트 또는 서버 중 한쪽에서 연결을 종료하고자 할 때, FIN (Finish) 패킷을 상대방에게 전송한다. 이 패킷은 더 이상 데이터를 전송하지 않겠다는 의사를 알리는 역할을 한다.

2. ACK 패킷 응답:  
   - FIN 패킷을 받은 상대방은 이를 확인하고, ACK (Acknowledgment) 패킷을 전송한다. 이는 상대방이 FIN 패킷을 받았음을 알리는 신호다. 하지만 아직 데이터를 전송할 수 있는 상태이므로 연결이 완전히 종료된 것은 아니다.

3. 상대방의 FIN 패킷 전송:  
   - FIN 패킷을 받은 쪽에서도 연결을 종료할 준비가 되면, FIN 패킷을 반대쪽으로 전송한다. 이는 더 이상 전송할 데이터가 없다는 의미다.

4. 최종 ACK 패킷 응답:  
   - 마지막으로 FIN 패킷을 받은 쪽에서 ACK 패킷을 전송하면, TCP 연결이 완전히 종료된다.

이 과정을 통해 양쪽 모두 안전하게 연결을 종료하고, 데이터 손실 없이 통신이 마무리된다.

 

참고로 아래 그림은 클라이언트단과 서버 단에서 TCP 연결이 해제되는 과정을 각각 표시한 그림이다.

 

 

 

 

그러면 TCP 연결이 비정상 종료되는 몇가지 경우를 확인해보자

 

TCP RESET 패킷(RST)은 비정상적인 상황에서 연결을 강제로 종료할 때 사용된다.

정상적인 연결 종료와 달리, RESET 패킷은 TCP 연결을 즉시 종료하고, 추가적인 통신이 없도록 하는 역할을 한다.

TCP RESET 패킷이 발송되는 상황은 다음과 같다:

1. 예상치 못한 패킷 수신
   - 클라이언트나 서버가 존재하지 않는 혹은 유효하지 않은 연결에 대한 패킷을 수신했을 때, 이를 처리하지 않고 강제로 연결을 종료하기 위해 RESET 패킷을 보내게 된다. 예를 들어, 특정 포트에 대한 연결이 없는데 해당 포트로 패킷이 수신되면, RESET 패킷을 발송해 상대방에게 이 연결이 유효하지 않음을 알리게 된다.

2. 프로그램 충돌 및 오류
   - 응용 프로그램이나 시스템 오류로 인해 TCP 연결을 정상적으로 종료할 수 없는 상황이 발생하면, RESET 패킷을 보내서 비정상적인 연결을 즉시 끊을 수 있도록 한다.

3. 자원 부족
   - 서버가 과도한 부하로 인해 새로운 연결을 처리할 수 없을 때, RESET 패킷을 발송해 클라이언트의 연결 시도를 차단할 수 있다. 이를 통해 서버는 새로운 연결을 처리할 여력이 없음을 클라이언트에 알리게 된다.

4. 보안 및 방화벽 설정
   - 방화벽이나 네트워크 보안 장치에서 특정 연결을 차단하기 위해 RESET 패킷을 발송하는 경우가 있다. 예를 들어, 허가되지 않은 IP 주소나 포트로 연결이 시도될 때, 방화벽은 해당 연결을 강제로 종료시키기 위해 RESET 패킷을 발송할 수 있다.

5. TCP 세션의 비정상적인 종료
   - 한쪽에서 TCP 연결을 정상적으로 종료(FIN 패킷 사용)하지 않고, 강제로 연결을 끊을 필요가 있을 때 RESET 패킷을 보내게 된다. 이는 응용 프로그램이 강제로 종료되거나 네트워크 오류로 인해 연결 상태를 유지할 수 없는 경우에 발생할 수 있다.

RESET 패킷은 정상적인 TCP 연결 종료(FIN 패킷 사용)와 달리, 즉시 연결을 끊는 비정상적인 종료 방법이며, 이는 TCP 세션을 더 이상 유지할 수 없거나 유효하지 않다고 판단될 때 사용된다.