Linux Packet Loss(패킷 손실) 문제의 원인과 해결 방법

Linux 서버를 운영하다 보면 Ping 응답 시간이 갑자기 증가하거나, SSH 접속이 끊기고, 파일 전송 속도가 급격히 느려지는 경우가 있습니다. 이러한 증상의 대표적인 원인 중 하나가 Packet Loss(패킷 손실) 입니다.

패킷 손실은 네트워크를 통해 전송되는 데이터가 목적지에 도착하지 못하고 중간에서 사라지는 현상을 의미합니다. 손실률이 조금만 높아져도 TCP는 재전송을 반복하므로 전체 네트워크 성능이 크게 저하될 수 있습니다.

이번 글에서는 Linux에서 Packet Loss가 발생하는 원인과 확인 방법, 해결 방법을 실무 중심으로 알아보겠습니다.

Packet Loss란?

Packet Loss는 송신한 패킷이 목적지까지 전달되지 못하는 현상입니다.

구조는 다음과 같습니다.

Client
   │
   ▼
Router
   │
   ▼
Switch
   │
   ▼
Linux Server

        X Packet Drop

패킷이 중간에서 삭제되면 송신 측은 재전송을 수행하며, 이 과정이 반복되면 응답 지연과 속도 저하가 발생합니다.

Packet Loss 문제가 발생하는 주요 원인

대표적인 원인은 다음과 같습니다.

  • 네트워크 혼잡(Congestion)
  • 불량 케이블
  • 스위치 포트 오류
  • NIC 장애
  • Duplex 설정 불일치
  • MTU 문제
  • Firewall 과부하
  • CPU 사용률 증가
  • 메모리 부족
  • Router 장애

실무에서는 물리적인 네트워크 장애스위치 포트 문제가 가장 흔한 원인입니다.

1. Ping으로 손실률 확인하기

가장 기본적인 테스트입니다.

ping 8.8.8.8

또는

ping -c 100 8.8.8.8

결과 예시

100 packets transmitted

95 received

5% packet loss

일반적으로 Packet Loss는 **0%**가 가장 이상적이며, 지속적으로 1% 이상 발생한다면 원인 분석이 필요합니다.

2. mtr로 구간별 분석하기

mtr은 Ping과 Traceroute를 결합한 도구입니다.

mtr 8.8.8.8

또는

mtr -rw 8.8.8.8

어느 구간에서 Packet Loss가 발생하는지 쉽게 확인할 수 있습니다.

3. traceroute 확인하기

경로를 확인합니다.

traceroute 8.8.8.8

중간 라우터에서 응답이 끊기는지 확인합니다.

4. 인터페이스 오류 확인하기

NIC 상태를 확인합니다.

ip -s link

또는

ifconfig

다음 항목을 확인합니다.

  • RX errors
  • TX errors
  • Dropped
  • Overruns

오류가 지속적으로 증가하면 NIC 또는 케이블 문제일 가능성이 높습니다.

5. ethtool 확인하기

NIC 정보를 확인합니다.

ethtool eth0

또는

ethtool -S eth0

다음 항목을 확인합니다.

  • CRC Error
  • Alignment Error
  • Frame Error
  • Carrier Error

이 값이 증가하면 물리적인 네트워크 문제를 의심해야 합니다.

6. tcpdump 분석하기

패킷 흐름을 확인합니다.

tcpdump -i eth0

특정 프로토콜만 확인하려면

tcpdump -i eth0 icmp

또는

tcpdump -i eth0 tcp

을 사용할 수 있습니다.

7. 시스템 부하 확인하기

CPU와 메모리 사용률을 확인합니다.

top

또는

vmstat 1

부하가 높으면 패킷 처리가 지연될 수 있습니다.

8. 로그 확인하기

커널 로그를 확인합니다.

journalctl -k

또는

dmesg

NIC Reset, Link Down 등의 메시지가 있는지 확인합니다.

9. 스위치 및 케이블 확인하기

운영체제에서는 정상으로 보이더라도 다음 항목을 함께 확인해야 합니다.

  • 랜 케이블 교체
  • 스위치 포트 변경
  • SFP 모듈 확인
  • Router 로그 확인

실무에서는 케이블 교체만으로 해결되는 경우도 적지 않습니다.

10. 서비스 테스트하기

설정을 변경한 후 다음 서비스를 테스트합니다.

  • Ping
  • SSH
  • HTTP
  • FTP
  • Database
  • 파일 복사

Packet Loss가 사라졌는지 확인합니다.

Packet Loss 문제 점검 순서

실무에서는 다음 순서대로 확인하는 것이 좋습니다.

  1. Ping 테스트
  2. mtr 실행
  3. traceroute 확인
  4. NIC 오류 확인
  5. ethtool 확인
  6. tcpdump 분석
  7. CPU/메모리 확인
  8. 로그 확인
  9. 케이블 및 스위치 점검
  10. 서비스 테스트

Packet Loss 사용 시 주의사항

다음 사항을 확인해야 합니다.

  • Ping 손실만으로 모든 장애를 판단하지 않는다.
  • mtr을 함께 사용하면 구간별 문제를 쉽게 찾을 수 있다.
  • NIC 오류 카운터를 지속적으로 확인한다.
  • Duplex와 Speed 설정도 함께 점검한다.
  • 물리적인 케이블 문제를 간과하지 않는다.
  • 실제 서비스 성능도 함께 확인한다.

Packet Loss는 네트워크뿐 아니라 서버 성능과 하드웨어 문제까지 함께 고려해야 정확한 원인을 찾을 수 있습니다.

Packet Loss와 Latency의 차이

항목Packet LossLatency
의미패킷이 사라짐패킷 전달이 느림
증상연결 끊김응답 지연
원인네트워크 장애혼잡, 거리
영향재전송 발생처리 속도 저하

Packet Loss는 패킷 자체가 사라지는 문제이고, Latency는 패킷이 늦게 도착하는 문제입니다.

자주 묻는 질문

Packet Loss가 1%만 발생해도 문제가 되나요?

웹 브라우징에서는 큰 문제가 없을 수 있지만, 실시간 게임, VoIP, 화상회의, 데이터베이스 복제와 같은 서비스에서는 1%의 손실도 성능 저하를 유발할 수 있습니다.

mtr과 traceroute 중 무엇이 더 좋나요?

장애 분석에는 mtr이 더 유용합니다. 경로와 손실률을 동시에 확인할 수 있기 때문입니다.

Packet Loss는 서버 문제인가요?

반드시 그렇지는 않습니다. 서버, 스위치, 라우터, ISP 회선, 케이블 등 다양한 구간에서 발생할 수 있으므로 전체 네트워크를 함께 점검해야 합니다.

마무리

Packet Loss는 네트워크 성능을 크게 저하시키는 대표적인 장애 원인입니다. ping, mtr, traceroute, ethtool, tcpdump 등을 함께 활용하면 대부분의 패킷 손실 문제를 빠르게 분석할 수 있으며, 서버뿐 아니라 스위치와 케이블까지 포함해 전체 경로를 점검하는 것이 안정적인 서비스 운영의 핵심입니다.

댓글 남기기