ping google.com이 안 됩니다. 그런데 curl https://google.com은 됩니다. AWS에서는 ping이 아무 응답도 없습니다. 네트워크가 문제인지, 보안 그룹이 문제인지, 프로토콜이 막힌 건지 알 수 없습니다. ICMP가 어떤 프로토콜이고 TCP/UDP와 어떻게 다른지 알아야 이런 상황에서 "ping 실패 = 네트워크 단절"이 아니라는 판단을 할 수 있습니다.

확대

**ICMP(Internet Control Message Protocol)**는 IP 네트워크에서 오류 보고와 진단 정보를 전달하기 위한 프로토콜입니다. TCP나 UDP처럼 애플리케이션 데이터를 운반하는 것이 아니라, 네트워크 계층의 상태를 알리는 제어 메시지를 전달합니다.

OSI 모델에서 ICMP의 위치

확대

ICMP는 IP와 동일한 3계층에서 동작하며, IP 패킷 안에 캡슐화되어 전송됩니다. IP 헤더의 프로토콜 번호는 1입니다.

ICMP 주요 메시지 타입

Echo Request / Echo Reply 흐름

확대

ping을 실행하면 내 컴퓨터는 **Echo Request(Type 8)**를 보내고, 상대방은 **Echo Reply(Type 0)**로 응답합니다. 이 한 쌍의 교환에서 RTT(Round-Trip Time)를 측정합니다.

ping 8.8.8.8 한 줄. Enter를 누르면 잠시 뒤 64 bytes from 8.8.8.8: ... time=31.4 ms가 뜹니다. 이 짧은 순간에 내 커널은 ICMP Echo Request 패킷을 만들어 목적지까지 라우팅하고, 목적지 커널이 Echo Reply로 돌려주며, ping은 보낸 시각과 받은 시각의 차이로 RTT를 계산합니다. 이 흐름을 단계로 알면 "왜 100% 손실이지", "왜 간헐적으로만 빠지지"를 단계별로 좁혀 진단할 수 있습니다.

[내 PC]  ping 8.8.8.8
   │
   ① ICMP Echo Request 생성            (Type 8, seq 번호·타임스탬프를 실음)
   │
   ② 라우팅 테이블 조회 → next-hop 결정  (같은 LAN이면 목적지, 아니면 게이트웨이)
   │    → next-hop MAC을 ARP로 해석(캐시 없으면 ARP 요청)
   │
   ③ 목적지까지 홉을 거쳐 전달           (라우터마다 TTL 1씩 감소)
   │
   ④ 목적지 커널이 Echo Reply 회신       (Type 0, 같은 seq·데이터 그대로)
   │    → 되돌아오는 경로도 홉을 거침
   │
   ⑤ 내 PC가 Reply 수신 → RTT 계산       (받은 시각 − 보낸 시각)
   ▼
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=31.4 ms

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 ping 결과는 이 5단계 중 어디까지 갔는지를 읽는 것입니다. 전량 손실(100%)이면 대개 ④에서 막힌 것 — 요청은 나갔지만 경로나 목적지 방화벽이 ICMP를 버린 경우가 서버 다운보다 흔하므로, 같은 대상에 curl·telnet으로 L4를 함께 찔러 서비스 생사와 구분합니다. 간헐 손실이면 ⑤에서 일부 seq만 빠진 것이라 경로 혼잡을 의심해 mtr로 어느 홉인지 좁히고, Time to live exceeded가 뜨면 ③의 라우팅 루프입니다. 경로 자체를 눈으로 보려면 ping -R(Record Route, 경유 홉을 패킷에 기록 — 다만 많은 라우터가 무시)이나 traceroute로 넘어갑니다.

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

각 항목의 의미:

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, 게임) 품질에 문제를 일으킬 수 있습니다.

mtr에서 경로 중간 홉에 빨간 손실이 뜨면 '저기가 범인'이라 결론짓기 쉽지만, 그 손실은 진짜 장애가 아니라 라우터가 ICMP를 홀대한 흔적일 때가 더 많습니다. ping·traceroute·mtr이 의존하는 ICMP가 라우터에서 어떻게 처리되는지 알아야 오진과 잘못된 ISP 신고를 피합니다.

• 라우터는 통과 트래픽과 자기에게 온 트래픽을 다르게 처리한다: 데이터 포워딩은 하드웨어(빠른 경로)로 처리하지만, 자신을 목적지로 하는 ICMP(에코, TTL 만료 응답)는 CPU(제어 평면, 느린 경로)로 올려 처리하고 rate-limit을 겁니다.
• 그래서 중간 홉 손실·지연은 과장된다: mtr 중간 홉의 손실률·RTT는 '그 라우터가 ICMP 응답을 얼마나 후순위로 미뤘나'를 반영할 뿐, 실제 데이터 포워딩 성능이 아닙니다.
• 진짜 손실을 구별하는 규칙: 중간 홉에서 손실이 보여도 그 다음 홉·최종 목적지의 손실이 0이면 무시해도 됩니다(ICMP 홀대). 반대로 손실이 어떤 홉부터 끝까지 계속 이어지면 그 지점이 진짜 문제입니다.
• 목적지(끝 홉)의 손실만이 서비스 품질을 말한다: 최종 홉의 손실률·지터가 실제 사용자 경험과 직결됩니다. 중간 홉 숫자에 휘둘리지 마세요.

즉 mtr을 읽을 때는 '어느 홉이 빨간가'가 아니라 '손실이 목적지까지 전파되는가'를 봐야 합니다.