서버가 죽었다는 신고가 들어왔지만 HTTP만 실패하는지 네트워크 자체가 끊긴 건지 아직 모릅니다. 가장 먼저 ICMP로 왕복 가능성과 지연, 손실을 확인해야 합니다.
ping은 만능 진단 도구는 아니지만 첫 번째 분기점입니다. 성공과 실패가 의미하는 범위를 정확히 알아야 합니다.
ping과 ICMP — 네트워크 생사 확인
네트워크 문제가 발생했을 때 가장 먼저 실행하는 명령어는 ping입니다. 단 한 줄로 "저쪽 서버가 살아 있나?" 를 확인할 수 있기 때문입니다. 하지만 ping이 실패했다고 해서 서버가 죽은 것이 아닐 수 있고, ping이 성공했다고 해서 서비스가 정상인 것도 아닙니다. 이 챕터에서는 ICMP 프로토콜의 원리를 이해하고, ping 결과를 정확하게 해석하는 방법을 배웁니다.
ICMP 프로토콜 원리
- 1ICMP 프로토콜의 역할과 OSI 3계층(네트워크 계층) 위치
- 2Echo Request(Type 8)와 Echo Reply(Type 0)의 ping 동작 원리
- 3RTT(왕복 지연 시간) 수치 해석 및 기준치
- 4Packet Loss와 mdev(지터) 분석 방법
- 5ping 한계 — ICMP 차단 케이스와 L4/L7 확인 도구
- 6클라우드 환경에서 ICMP 방화벽 정책 처리
ping -c 4 8.8.8.8ping -c 4 google.comping -c 4 -s 1400 8.8.8.8클라우드 환경(AWS 등)은 보안 그룹에서 ICMP를 명시적으로 허용해야 ping 응답이 가능
ICMP란 무엇인가 — L3 진단 메시지 프로토콜
ping google.com이 안 됩니다. 그런데 curl https://google.com은 됩니다. AWS에서는 ping이 아무 응답도 없습니다. 네트워크가 문제인지, 보안 그룹이 문제인지, 프로토콜이 막힌 건지 알 수 없습니다. ICMP가 어떤 프로토콜이고 TCP/UDP와 어떻게 다른지 알아야 이런 상황에서 "ping 실패 = 네트워크 단절"이 아니라는 판단을 할 수 있습니다.
**ICMP(Internet Control Message Protocol)**는 IP 네트워크에서 오류 보고와 진단 정보를 전달하기 위한 프로토콜입니다. TCP나 UDP처럼 애플리케이션 데이터를 운반하는 것이 아니라, 네트워크 계층의 상태를 알리는 제어 메시지를 전달합니다.
OSI 모델에서 ICMP의 위치
┌─────────────────────────────────────┐
│ 7계층 (응용) HTTP, FTP, DNS │
│ 6계층 (표현) TLS, MIME │
│ 5계층 (세션) 세션 관리 │
│ 4계층 (전송) TCP, UDP │
├─────────────────────────────────────┤
│ 3계층 (네트워크) IP, ICMP ◀ 여기 │
│ 2계층 (데이터링크) Ethernet, ARP │
│ 1계층 (물리) 전기 신호 │
└─────────────────────────────────────┘
ICMP는 IP와 동일한 3계층에서 동작하며, IP 패킷 안에 캡슐화되어 전송됩니다. IP 헤더의 프로토콜 번호는 1입니다.
ICMP 주요 메시지 타입
| 타입 번호 | 이름 | 용도 |
|---|---|---|
| 0 | Echo Reply | ping 응답 |
| 3 | Destination Unreachable | 목적지 도달 불가 |
| 8 | Echo Request | ping 요청 |
| 11 | Time Exceeded | TTL 초과 (traceroute에서 활용) |
Echo Request / Echo Reply 흐름
내 컴퓨터 (192.168.1.10) 구글 DNS (8.8.8.8)
│ │
│── ICMP Type 8 (Echo Request) ──▶ │
│ Sequence: 1, TTL: 64 │
│ │
│ ◀── ICMP Type 0 (Echo Reply) ─── │
│ Sequence: 1, TTL: 118 │
│ │
│── ICMP Type 8 (Echo Request) ──▶ │
│ Sequence: 2 │
│ ◀── ICMP Type 0 (Echo Reply) ─── │
│ Sequence: 2 │
ping을 실행하면 내 컴퓨터는 **Echo Request(Type 8)**를 보내고, 상대방은 **Echo Reply(Type 0)**로 응답합니다. 이 한 쌍의 교환에서 RTT(Round-Trip Time)를 측정합니다.
RTT와 Packet Loss — ping 결과 수치 해석
ping google.com을 쳤더니 응답이 오긴 하는데 가끔 느립니다. 평균 RTT가 200ms인데 이게 정상인지 이상한지 모르겠습니다. Packet Loss 5%가 나왔는데 심각한 건지 일시적인 건지도 판단이 안 됩니다. ping 수치를 해석할 줄 알아야 "네트워크 느리다"는 막연한 증상을 구체적인 문제로 좁힐 수 있습니다.
RTT (Round-Trip Time)
RTT는 패킷이 출발지에서 목적지까지 갔다가 돌아오는 데 걸린 시간입니다. 단위는 **밀리초(ms)**입니다.
ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=31.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=30.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=32.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=31.0 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 30.8/31.3/32.1/0.5 ms
각 항목의 의미:
| 항목 | 값 | 의미 |
|---|---|---|
icmp_seq | 1, 2, 3, 4 | 순서 번호 (빠지면 유실) |
ttl | 118 | 남은 홉 수 (64 또는 128로 시작) |
time | 31.4 ms | 이 패킷의 RTT |
rtt min/avg/max/mdev | 30.8/31.3/32.1/0.5 | 최소/평균/최대/표준편차 |
RTT 기준치 해석
< 1ms : 같은 L2 네트워크 (스위치 내부)
1~5ms : 같은 데이터센터 내
10~30ms : 국내 인터넷 (서울 ↔ 부산)
100ms~ : 해외 인터넷 (한국 ↔ 미국)
500ms~ : 심각한 지연, 사용자 체감 불편
Packet Loss
패킷 손실률은 전체 전송 패킷 대비 응답이 없는 패킷의 비율입니다.
4 packets transmitted, 3 received, 25% packet loss
- 0%: 정상
- 1~5%: 경미한 네트워크 불안정 (무선 환경에서 간헐적으로 발생)
- 5% 이상: 의미 있는 네트워크 품질 문제
- 100%: ICMP 차단 또는 목적지 완전 단절
mdev (평균 편차)가 중요한 이유
mdev가 크면 RTT가 불규칙하게 변동한다는 의미입니다. 평균 RTT가 낮아도 mdev가 크면 **네트워크 지터(jitter)**가 심한 것으로, 실시간 통신(VoIP, 게임) 품질에 문제를 일으킬 수 있습니다.
실습 — ping 분석
가장 기본적인 ping 명령어로 외부 DNS 서버에 연결을 테스트합니다.
# 실습 디렉토리 준비
mkdir -p /tmp/networking/part3/exam_11 && cd /tmp/networking/part3/exam_11
# -c 4: 4개 패킷만 보내고 종료 (무한 루프 방지)
ping -c 4 8.8.8.8
- packet loss—손실률이 0%인지, 간헐 손실이 있는지 확인합니다
- rtt—min/avg/max 값으로 지연과 변동 폭을 봅니다
- DNS 분리—IP ping과 도메인 ping 결과를 비교해 DNS 문제를 구분합니다
예상 출력: 정상 응답 시 이런 형태로 출력됩니다.
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=31.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=30.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=31.5 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=31.1 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 30.9/31.1/31.5/0.2 ms
결과 체크리스트:
-
0% packet loss확인 -
time값이 예상 범위인지 확인 -
icmp_seq번호에 빈 칸이 없는지 확인 (순서 유실)
추가 옵션 실습: -c, -i, -s 옵션으로 ping 동작을 제어합니다.
# -i 0.2: 0.2초 간격으로 전송 (기본 1초)
ping -c 10 -i 0.2 8.8.8.8
# -s 1400: 패킷 크기 1400바이트 (MTU 테스트용)
ping -c 4 -s 1400 8.8.8.8
# -W 1: 응답 대기 시간 1초로 제한
ping -c 4 -W 1 192.168.1.1
IP 주소 대신 도메인 이름으로 ping을 실행하면 DNS 해석이 선행됩니다.
ping -c 4 google.com
예상 출력:
PING google.com (142.250.196.110) 56(84) bytes of data.
64 bytes from kix07s05-in-f14.1e100.net (142.250.196.110): icmp_seq=1 ttl=118 time=32.1 ms
...
중요 관찰 포인트: TTL과 응답 시간(ms)으로 네트워크 상태를 판단합니다.
ping google.com → 성공 (DNS + ICMP 모두 정상)
ping 8.8.8.8 → 성공 / ping google.com 실패 → DNS 문제
ping 8.8.8.8 → 실패 → L3 네트워크 문제
진단 흐름 정리: ping 결과 유형별로 다음 조치가 달라집니다.
IP ping 실패?
YES → 라우팅/물리 연결 문제 (L1~L3 확인)
NO → 도메인 ping 실패?
YES → DNS 설정 문제 (/etc/resolv.conf 확인)
NO → 서비스 포트 문제 가능성 (telnet/curl로 L4 확인)
ping이 성공해도 서비스가 동작하지 않을 수 있습니다. 각 계층별 확인 도구를 사용해야 합니다.
# ping: L3 도달 가능성 확인
ping -c 2 192.168.1.100
# → 성공해도 HTTP 서비스가 죽어있을 수 있음
# telnet: TCP 포트 열려있는지 확인 (L4)
telnet 192.168.1.100 80
# → "Connected" 나오면 80 포트 열려있음
# → "Connection refused" 나오면 포트 닫힘
# curl: HTTP 응답 확인 (L7)
curl -v http://192.168.1.100/
# → HTTP 상태 코드 확인 (200, 404, 500 등)
# nc (netcat): 포트 스캔
nc -zv 192.168.1.100 80 443
계층별 진단 도구 정리: 문제 계층에 맞는 도구를 선택하면 진단 속도가 빨라집니다.
L3 (네트워크): ping, traceroute, mtr
L4 (전송): telnet, nc, nmap
L7 (응용): curl, wget, httpie
트러블슈팅
증상
웹 브라우저로 서버에 접속되고 SSH도 되는데, ping만 응답이 없습니다.
ping -c 4 my-server.example.com
# PING my-server.example.com (203.0.113.10): 56 data bytes
# Request timeout for icmp_seq 0
# Request timeout for icmp_seq 1
# Request timeout for icmp_seq 2
# Request timeout for icmp_seq 3
# --- my-server.example.com ping statistics ---
# 4 packets transmitted, 0 packets received, 100.0% packet loss
하지만 서비스는 살아있습니다:
curl -I http://my-server.example.com
# HTTP/1.1 200 OK
# ...
원인
ICMP 패킷이 방화벽이나 보안 정책에 의해 차단되고 있습니다.
클라우드 환경 (AWS 예시): AWS Security Group에서 ICMP를 명시적으로 허용해야 합니다.
AWS 보안 그룹 인바운드 규칙 확인:
- HTTP (80): 0.0.0.0/0 허용 ← 웹은 됨
- SSH (22): 내 IP 허용 ← SSH는 됨
- ICMP: (규칙 없음) ← ping 안 됨!
리눅스 OS 방화벽 (iptables/firewalld): 호스트 자체 방화벽이 ICMP를 차단하는 경우입니다.
# 현재 iptables 규칙 확인
sudo iptables -L -n | grep icmp
# firewalld 확인
sudo firewall-cmd --list-all | grep icmp
해결책
AWS 보안 그룹에서 ICMP 허용: 보안 그룹 인바운드 규칙에 다음을 추가합니다:
- 유형:
All ICMP - IPv4 - 소스:
0.0.0.0/0(또는 특정 IP)
리눅스 iptables에서 ICMP 허용: 인바운드 ICMP echo-request를 허용하는 규칙입니다.
이 명령은 방화벽 정책을 변경해 현재 접속 중인 세션이나 운영 트래픽에 즉시 영향을 줄 수 있습니다. 적용 전 허용 대상 IP·포트와 롤백 명령을 확인하세요.
# ICMP Echo Request 허용
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
sudo iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT
firewalld에서 ICMP 허용: firewalld를 사용하는 RHEL 계열 설정 방법입니다.
이 명령은 방화벽 정책을 변경해 현재 접속 중인 세션이나 운영 트래픽에 즉시 영향을 줄 수 있습니다. 적용 전 허용 대상 IP·포트와 롤백 명령을 확인하세요.
sudo firewall-cmd --add-icmp-block-inversion --permanent
sudo firewall-cmd --reload
# 또는 특정 존에만 허용
sudo firewall-cmd --zone=public --remove-icmp-block=echo-request --permanent
중요 원칙
ping 실패 ≠ 서버 다운
ping 성공 ≠ 서비스 정상
ping은 ICMP(L3) 도달 가능성만 확인합니다.
서비스 가용성은 해당 프로토콜(L4~L7)로 직접 확인해야 합니다.
증상
대부분의 ping은 성공하지만 간헐적으로 유실됩니다.
ping -c 20 192.168.1.1
# ...
# 20 packets transmitted, 17 received, 15% packet loss
# rtt min/avg/max/mdev = 0.5/2.3/45.2/9.8 ms
mdev가 9.8ms로 크고 최대 RTT가 45.2ms로 튀었습니다.
원인 분석
# 더 긴 시간 동안 모니터링
ping -c 100 -i 0.5 192.168.1.1
# mtr로 각 홉별 패킷 손실 위치 특정
mtr --report --report-cycles 20 8.8.8.8
mtr 출력 예시: 각 홉의 패킷 손실률과 지연 시간을 한 번에 볼 수 있습니다.
HOST: myserver Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 20 0.6 0.7 0.5 1.1 0.2
2. 10.0.0.1 0.0% 20 5.2 5.1 4.8 5.9 0.3
3. 203.0.113.1 15.0% 20 8.3 12.4 7.1 45.2 9.8 ← 여기서 손실!
4. 8.8.8.8 0.0% 20 31.2 31.1 30.8 31.6 0.2
3번 홉에서 15% 손실이 발생하고 있습니다. 이 구간의 라우터나 링크에 문제가 있습니다.
해결 방향
- ISP 구간 문제: 인터넷 서비스 제공업체에 장애 신고
- 스위치/라우터 문제: 해당 장비의 인터페이스 에러 카운터 확인
- 무선 환경: 채널 간섭, 신호 약화 확인 (
iwconfig,iwlist)
실무 맥락
장애 대응 시 첫 번째 확인
서버 모니터링 알람이 울렸을 때 인프라 엔지니어의 첫 번째 행동은 ping입니다.
# 1단계: 네트워크 도달 가능성 확인
ping -c 4 prod-web-01.internal
# → 실패하면 네트워크/전원 문제
# → 성공하면 서비스 레이어 문제
# 2단계: 서비스 포트 확인
curl -s -o /dev/null -w "%{http_code}" http://prod-web-01.internal/health
# → 200이면 서비스 정상
# → 타임아웃이면 애플리케이션 문제
# 3단계: 여러 서버 동시 확인 (배시 루프)
for host in web-01 web-02 web-03; do
ping -c 1 -W 1 ${host}.internal > /dev/null 2>&1 \
&& echo "${host}: UP" \
|| echo "${host}: DOWN"
done
SLA 모니터링에서의 RTT
클라우드 서비스에서는 리전 간 레이턴시가 SLA에 영향을 줍니다.
# 서울 → 도쿄 리전 레이턴시
ping -c 10 ap-northeast-1.aws.example.com
# 약 30~35ms가 정상
# 서울 → 버지니아 리전 레이턴시
ping -c 10 us-east-1.aws.example.com
# 약 180~200ms가 정상
모니터링 시스템에서의 ICMP 활용
Prometheus + Blackbox Exporter를 사용하면 ping을 지속적으로 모니터링하고 알람을 설정할 수 있습니다.
# blackbox.yml 예시
modules:
icmp_check:
prober: icmp
timeout: 5s
icmp:
preferred_ip_protocol: ip4
현업에서 알아두면 좋은 것들
- 클라우드 환경에서 ICMP는 기본 차단: AWS, GCP, Azure 모두 보안 그룹에서 명시적으로 허용해야 ping이 됩니다.
- ping 성공 = 서비스 가용성이 아님: 장애 원인 파악은 L4~L7까지 계층별로 내려가야 합니다.
- 대용량 트래픽 경고: 프로덕션 서버에
ping -f(flood ping)는 절대 사용하지 마세요. 네트워크 부하를 유발합니다. - 방화벽 정책 문서화: ICMP 허용/차단 정책을 팀 Wiki에 명확히 기록해두면 장애 시 빠른 판단이 가능합니다.
정리
이 챕터에서 배운 핵심 내용입니다.
ICMP (L3 프로토콜)
├── Echo Request (Type 8): ping 보내기
├── Echo Reply (Type 0): ping 응답
└── 기타: Destination Unreachable, Time Exceeded
ping 결과 해석
├── RTT: 왕복 지연 시간 (낮을수록 좋음)
├── Packet Loss: 유실률 (0%가 정상)
└── mdev: 지터 (낮을수록 안정적)
ping 한계
├── ICMP 차단 = ping 실패 ≠ 서버 다운
└── ping 성공 ≠ L4/L7 서비스 정상
계층별 진단 도구
├── L3: ping, traceroute, mtr
├── L4: telnet, nc, nmap
└── L7: curl, wget
다음 챕터에서는 traceroute를 사용하여 패킷이 목적지까지 어떤 경로를 거치는지 추적하는 방법을 배웁니다.