핑은 위험할 수 있습니다.

최근에 추적 파일의 일부 분석을 수행 하도록 요청 했다, 그것은 단지 161 시간 및 보다 조금 더 포함 된 2.6 백만 프레임. 나는 그 프레임의 약 75 %가 핑 요청이나 ping 회신하는 것을 발견하는 것에 놀랐습니다. 소스 IP 주소를 인식하지 못했다면 대상이 서비스 거부 공격을 받고 있다는 결론에 이르렀을 것입니다. 대신 STCP의 ping 명령에 대한 "run_forever" 인수를 사용하여 대상의 도달 가능성을 모니터링하고 있다는 것을 알게 되었습니다.

대부분의 UNIX 또는 Linux 시스템의 ping 명령과 달리 STCP의 ping 명령은 ping 응답과 다음 ping 요청 수신 간에 일시 중지되지 않습니다. 기본 ping 수는 4에 불과하므로 중요한 문제가 되지 않습니다. 그러나 카운트 인수를 사용하여 요청 수가 증가하거나 run_forever 인수를 사용하면 시스템, 이더넷 어댑터 및 네트워크에 상당한 부하가 발생할 수 있습니다. 이렇게 하면 STCP의 ping 명령의 기본 동작이 대상 호스트의 장기 모니터링에 완전히 적합하지 않습니다.

그러나 기본 동작이 적합하지 않다고 해서 장기 모니터링을 위해 ping 명령을 사용할 수 없다는 의미는 아닙니다. 비결은 명령을 한 번 실행하고 ping 요청의 연속 스트림을 보내는 대신 한 번에 하나의 ping 요청을 보내는 명령을 반복적으로 실행하는 것입니다. 다음 매크로는 그렇게 할 것입니다.

처음 두 인수를 볼 수 있듯이 ping 명령으로 직접 전달되고 ping의 호스트 및 시간 아웃 인수에 해당합니다. Ping의 기본 시간 시간은 15초이지만 너무 길고 매크로에서 1초로 변경했습니다. 물론 매크로에서 또는 인수를 통해 값을 제공함으로써 조정할 수 있습니다. 세 번째 인수는 핑 간에 일시 중지하는 초 수이며 기본값은 1초입니다. 매크로를 실행하고 ping 명령을 실행하고 ping 명령을 실행하는 데 시간이 걸리기 때문에 핑 사이의 실제 시간이 조금 더 길어집니다. Packet_monitor 1.05초에서 1.1초 사이의 시간을 보여 줬다. 최종 인수는 UNIX 또는 Linux ping이 제공하지 않는 것입니다 - 각 핑에 대한 타임스탬프를 통해 대상이 응답을 중지할 시기와 다시 시작할 때를 알 수 있습니다. 타임스탬프를 원하지 않는 경우 -no_timestamp 인수로 그들을 끌 수 있습니다.