Python FastAPI로 간단한 RestAPI 서버를 테스트 중입니다. (클라우드 서버에서)
그런데, 해당하는 개발 서버에 지속적으로 패킷을 발송(Send)하는 대상이 있습니다.
지속적으로, "GET /healthz"를 보내고 있습니다. 처음에는 그냥 그런가보다 했는데, 자꾸 발송하니 테스트에 방해가 되었습니다.
1) Log를 확인해 봅니다.
2) 대상 출발지를 확인해 봅니다.
3) 대상 IP를 확인하니, 어처구니 없게도 본인의 공인 아이피 입니다. 헐~
테스트중인 POSTMan, Proxy 등은 /healthz 라는 URI를 호출하지 않습니다.
그렇다면, 내 개발장비의 어느 프로세스 인가가 계속 루프를 돌면서 호출하고 있는게 분명합니다.
누구냐..? 넌..? 나를 귀찮게 하는 것은 누구인가?
4) 로컬PC (mac)에서, 네트워크가 연결되어 있는 정보를 살펴 봅니다.
$ netstat -ant | grep 8080
다음과 같이 목적지 서버에 8080포트로 연결하여 ESTABLISHED 되어 있는 연결이 있습니다. 신기한것은 TIME_WAIT 되었지만 몇놈 더 있었다는 것입니다.
다시 netstat 를 서버 IP로 잡아보고, 어떤 프로토콜을 사용하는지 살펴보았습니다. 연결하여 사용하고 있는 ssh는 문제가 없어 보입니다. "http-al"이 수상해 보입니다. http protocol을 사용하고 있는 녀석입니다. http 프로토콜은 기본적으로 한번 접속하고 connection을 끊어 주는데, 지속 연결하고 있습니다.
5) lsof 명령으로 정확한 프로세스/파일명을 찾는다.
http를 사용하는 어떤 프로세스인지, 정확히 실행파일 단위로 알고 싶습니다. 이럴 때, `lsof` 명령어는 매우 요긴하게 사용할 수 있습니다. `lsof`명령어는 List of File의 약자로 Linux/Unix계열에서 오픈되어 있는 파일을 나열하는 명령어 입니다. 아시다시피, Linux/Unix계열의 모든것은 파일형태로 관리하기 때문에 네트워크 소켓 또한 파일로 관리됩니다. 따라서, lsof를 사용하면 열려있는 소켓과 이를 사용하는 프로세스를 확인 할 수 있습니다.
다음은 포트 8080을 열고있는 파일을 나열합니다.
$ lsof -i:8080
흐음... Google 입니다. Google + HTTP ==> Chrome ? PID == 569
6) 정확한 Application 확인
확인을 위해서 `ps -ef`를 사용하여 정확한 실행 파일명을 찾아 보았습니다. "/Applications/Google Chrome.app"를 확인하였습니다. Chrome 브라우저가 맞습니다.
필자는 Chrome의 탭을 30~40개 띄워놓고 작업을 하는데, 이중에서 무엇인가 있나 봅니다. 탭을 하나 하나 확인 결과, Chrome Browser에 띄워 놓은 Streamlit 이었습니다. Streamlit은 Frontend/Backend 모두 포함하고 있는데, FrontEnd의 Javascript로 변환된 코드 중에서 지속적으로 Health Check 를 확인하는 코드가 포함되어 있는 것을 확인했습니다. Streamlit을 사용하시는 분은 참조하시기 바랍니다.
에효~~ 결국 브라우저에서 원하지 않는 health Check를 하는 녀석이네요. 집 앞에 있는 파랑새를 잡은 느낌입니다만, 개발하는 과정은 언제나 이렇습니다.
댓글 영역