인기 도구

테마

패킷 손실 테스트

게임과 통화가 보내는 것과 같은 실제 UDP 패킷으로 패킷 손실을 테스트하고, 패킷을 올라가는 길에 잃는지 내려오는 길에 잃는지 확인하세요. 한 번 실행하면 지연 시간 테스트, 지터 테스트, 버퍼블로트 테스트까지 함께 끝납니다.

모든 패킷을 가장 가까운 Cloudflare 데이터 센터를 거쳐 측정 · 손실을 업로드와 다운로드로 구분 · 저장하는 정보 없음
프로필

UDP 패킷 3,000개가 가장 가까운 Cloudflare 데이터 센터를 거쳐 왕복 · 1분 · 저장하는 정보 없음

도착한 그대로의 모든 패킷예시: 광랜에서 1분

  • 정시 2,995
  • 지연 도착 0
  • 손실 4
  • 순서 뒤바뀜 1
  • 중복 0
패킷버스트업로드업다운로드다운지연 ms4개 손실없음–
각 열은 1초이며, 그 초의 패킷이 위에서 아래로 쌓입니다. 원하는 초를 가리키거나, 띠에 포커스를 두고 화살표 키를 사용하세요.

이 패킷 손실 테스트는 어떻게 작동하나요?

브라우저가 작은 UDP 패킷을 일정하게 가장 가까운 Cloudflare 데이터 센터로 올려 보내고 곧바로 자기 자신에게 돌려받으며, 돌아오지 않은 패킷을 하나하나 셉니다.

패킷은 손실된 메시지를 절대 재전송하지 않도록 설정한 WebRTC 데이터 채널로 이동하므로, 사라진 패킷은 사라진 채로 남습니다. 재시도에 가려진 지연이 아니라 실제 패킷 손실입니다. 패킷은 애니캐스트 방식인 Cloudflare TURN 서비스가 중계합니다. 브라우저는 가장 가까운 Cloudflare 거점에 도달하고, 릴레이는 그곳에 자리 잡습니다. 스트림의 양 끝이 모두 브라우저 안에 있고 하나의 시계를 쓰므로, 모든 패킷의 지연을 0.1밀리초 단위까지 정확하게 잽니다.

이 루프의 패킷은 내 연결을 올라갈 때와 내려올 때 두 번 지나므로, 그것만으로는 패킷을 어디서 잃었는지 알 수 없습니다. 그래서 짧은 음성 통화를 함께 실행합니다. 브라우저가 무음 오디오 스트림을 Cloudflare 통화 서버(Realtime SFU)로 보내고 다시 받습니다. Cloudflare가 받지 못한 패킷을 보고하며 이것이 업로드 손실이고, 그 뒤에 사라진 것이 다운로드 손실입니다.

부하 상태에서는 패킷이 계속 오가는 동안 Cloudflare 속도 테스트 서버에서 다운로드, 이어서 업로드로 회선을 가득 채우므로, 회선이 바쁠 때 손실, 지터, 지연 시간이 어떻게 변하는지 볼 수 있습니다.

내 브라우저릴레이(TURN)가장 가까운 Cloudflare통화 서버(SFU)가장 가까운 Cloudflare루프: 패킷이 갔다가 돌아옴올라가다 잃었을까, 내려오다 잃었을까?루프로는 알 수 없음. 모든 패킷을 하나의 시계로 측정테스트 통화: Opus, 초당 50패킷↑ 업로드↓ 다운로드Cloudflare가 받은 패킷을 셈 ↑브라우저가 돌아온 패킷을 셈 ↓
  • 루프: 모든 패킷의 지연과 결과
  • 통화: 어느 방향에서 손실되었는지
  • 손실된 패킷
둘 다 테스트 내내 동시에 실행됩니다.
패킷 손실 테스트 결과: 모든 패킷을 나타낸 띠, 다운로드 중 손실 버스트, 업로드·다운로드 손실, 지터와 버퍼블로트 등급패킷 손실 테스트 결과: 모든 패킷을 나타낸 띠, 다운로드 중 손실 버스트, 업로드·다운로드 손실, 지터와 버퍼블로트 등급판정손실, 버스트, 부하 시 지연 증가를 Microsoft Teams 목표나 Cloudflare 게임 점수에 비추어 판정합니다.모든 패킷열 하나가 1초, 표시 하나가 패킷 하나입니다. 정시, 지연 도착, 손실, 순서 뒤바뀜을 나타내고 버스트는 괄호로 묶습니다.업로드인가, 다운로드인가테스트 통화가 손실을 나눕니다. Cloudflare가 내게서 받지 못한 패킷과, 내게 돌아오는 길에 잃은 패킷입니다.점수와 등급스트리밍, 게임, 화상 통화에 대한 Cloudflare 점수와 A+부터 F까지의 Waveform 버퍼블로트 등급입니다.
버퍼블로트가 있는 회선에서 1분 동안 실행한 테스트입니다. 유휴 상태에서는 손실이 없지만, 다운로드 중에는 짧은 손실 버스트와 늘어나는 지연이 나타납니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

패킷 손실이란?

패킷 손실은 기기를 떠난 데이터 패킷 중 반대편에 도착하지 못했거나, 너무 늦게 도착해 쓸 수 없는 패킷의 비율입니다.

게임, 음성 통화, 화상 통화는 UDP로 작은 패킷을 1초에 여러 번 보내며, 손실된 패킷의 재전송을 기다리지 않습니다. 패킷 하나를 잃으면 화면이 멈추거나, 통화에서 단어가 끊기거나, 캐릭터가 뒤로 튑니다. 다운로드와 웹 페이지는 손실된 것을 다시 보내는 TCP를 쓰므로 손실이 페이지가 느려지는 것으로만 나타납니다. 일반 속도 테스트로 패킷 손실을 볼 수 없는 것도 그 때문입니다.

이 테스트는 네 가지를 셉니다. 손실: 3초가 지나도 도착하지 않은 패킷으로, IETF의 손실 지표가 보고하도록 정한 대기 시간입니다. 지연 도착: 도착은 했지만 다른 패킷보다 한참 늦은 패킷. 순서 뒤바뀜: 나중에 보낸 패킷보다 늦게 도착한 패킷(RFC 4737). 중복: 두 번 도착했지만 한 번만 집계한 패킷.

20 ms마다 하나씩, 패킷 16개손실 1 · 지연 도착 1 · 순서 뒤바뀜 1 · 중복 1
보냄도착 지연 도착: 다른 패킷보다 100 ms 늦음11223344566778899101011111212131314141415151616
  • 정시다른 패킷과 함께 도착
  • 지연 도착도착했지만 다른 패킷보다 한참 늦음: 통화에 쓰기엔 너무 늦음
  • 손실3초 안에 돌아오지 않음
  • 순서 뒤바뀜나중에 보낸 패킷보다 늦게 도착
  • 중복두 번 도착, 한 번만 집계
결과의 띠도 같은 색을 쓰며, 패킷 하나가 칸 하나입니다.

패킷 손실은 어느 정도까지 괜찮나요?

화상 통화라면 1% 미만입니다. Microsoft의 Teams 목표는 15초 구간마다 손실 1% 미만, 200밀리초 구간마다 10% 미만이며, Zoom은 2% 이하를 권장합니다.

이 페이지의 각 판정은 공개된 규칙 하나를 그대로 따릅니다. 화상 통화: 기기에서 네트워크 엣지까지의 경로에 대한 Microsoft Teams 목표인 왕복 100 ms 미만, 15초 구간마다 손실 1% 미만, 200 ms 구간마다 버스트 손실 10% 미만, 지터 30 ms 미만, 순서 뒤바뀜 0.05% 미만, 그리고 Zoom의 권장 사항인 지연 시간 150 ms, 지터 40 ms, 손실 2%입니다.

게임과 스트리밍: speed.cloudflare.com이 쓰는 것과 같은 Cloudflare 네트워크 품질 점수입니다. 손실 1% 미만이면 만점, 1~5%는 절반, 5~25%는 0점이고, 그보다 많으면 점수가 깎입니다. 게임에 대해서는 게임 제작사가 공개한 손실 한도가 없습니다. 초당 64번이나 128번 업데이트하는 게임에서는 버스트로 1%만 잃어도 눈에 보이는 끊김이 됩니다.

Microsoft Teams 15초 구간마다 1% 미만 Zoom 2% 이하 0%0.5%1%2%3%4%5% Cloudflare AIM +10점 +5 5~25%: 0 · 50% 미만: −10 · 그 이상: −20
  • 1% 미만: 만점, Teams 목표 이내
  • 1~2%: Zoom 기준 이내
  • 2% 초과: 둘 다 벗어남
각 기관의 규칙을 결과의 검사 항목이 적용하는 그대로 표시했습니다. Teams 기준은 15초 구간마다 적용되므로, 평균이 낮아도 잠깐 나쁜 구간이 있으면 통과하지 못합니다.

패킷 손실은 무작위인가요, 버스트인가요?

비율만큼 패턴도 중요합니다. 흩어진 2% 손실은 통화에서 거의 티가 나지 않지만, 몇 번의 버스트로 잃은 2%는 연이은 끊김이 됩니다.

이 테스트는 연달아 손실된 패킷의 묶음인 손실 구간(RFC 6534)을 세고, 가장 긴 구간을 보여 주며, ITU-T G.107의 버스트 비율을 계산합니다. 손실이 무작위로 일어나면 1, 몰려 있으면 1보다 큽니다. 버스트는 보통 공유기나 모뎀의 대기열이 가득 차 같은 스트림의 패킷 여러 개를 한꺼번에 버리거나, Wi-Fi가 잠깐 끊길 때 생깁니다.

짧은 테스트로는 손실이 없다는 것을 증명할 수 없습니다. 패킷 750개 중 하나도 잃지 않았어도 손실률은 여전히 0.4% 미만 어딘가일 수 있으므로, 이 페이지는 0%라고만 하지 않고 범위를 보여 줍니다. 생겼다 사라지는 손실을 잡으려면 3분 테스트를 실행하세요.

같은 2% 패킷 손실, 두 가지 모습1분 · 패킷 3,000개 · 각각 60개 손실

무작위흩어진 단발성 손실

손실 구간
60
가장 긴 버스트
1 · 20 ms
버스트 비율
0.98

통화에서: 가끔 들리는 희미한 딸깍 소리

버스트12개씩 연속 5번

손실 구간
5
가장 긴 버스트
12 · 240 ms
버스트 비율
11.76

통화에서: 1분에 5번, 240 ms씩 끊김

버스트 비율(ITU-T G.107): 평균 버스트 길이를 같은 손실률의 무작위 손실에서 예상되는 길이로 나눈 값입니다. 1이면 무작위이고, 높을수록 더 몰려 있습니다.

지터란 무엇이며 어떻게 측정하나요?

지터는 패킷마다 지연이 얼마나 달라지는지를 나타냅니다. 통화와 게임은 이를 고르게 하려고 패킷을 버퍼에 담는데, 그 버퍼가 지연을 더합니다.

이 페이지는 WebRTC 통화 앱이 보고하는 RFC 3550의 공식으로 지터를 측정합니다. 패킷이 도착할 때 패킷 사이 지연의 변화를 최근 패킷에 걸쳐 평활화한 값입니다. 다른 도구는 다른 공식을 씁니다. Cloudflare 속도 테스트는 연속된 핑 사이의 차이를 평균하고, Waveform과 Ookla는 평균으로부터의 편차를 쓰므로 지터 값을 직접 비교할 수 없습니다. 이 페이지의 Cloudflare 점수는 당연히 Cloudflare 자체 공식을 씁니다.

RFC 3550 도착 간격 지터J = J + (|D| − J) / 16
보냄도착변화 D지터 J 0 ms1820 ms21+340 ms19−260 ms26+780 ms18−8100 ms30+12120 ms19−11140 ms20+1160 ms22+22.31

전송 시간(ms)입니다. 변화가 생길 때마다 J가 그 차이의 16분의 1만큼 움직이므로, 스파이크 하나는 J를 조금만 올리고 안정된 패킷이 이어지면 다시 내려갑니다.

Cloudflare 속도 테스트는 연속된 핑 사이의 변화를 평균하고, Waveform과 Ookla는 평균을 중심으로 한 편차를 씁니다. 같은 회선에서도 세 가지 지터 값이 나옵니다.

버퍼블로트란? 부하 시 지연 시간

버퍼블로트는 연결이 바쁠 때 더해지는 추가 지연입니다. 공유기나 모뎀이 데이터를 너무 많이 대기열에 쌓아, 모든 패킷이 다운로드나 업로드 뒤에서 줄을 서서 기다립니다.

부하 테스트는 유휴 상태, 다운로드 중, 업로드 중의 지연 시간을 차례로 재고, 증가 폭을 Waveform 기준으로 등급을 매깁니다. 추가 지연이 5 ms 미만이면 A+, 30 미만 A, 60 미만 B, 200 미만 C, 400 미만 D, 400 ms 이상이면 F이며, 평균 지연 시간과 두 방향 중 더 나쁜 쪽을 기준으로 합니다.

해결책은 공유기의 스마트 큐 관리(SQM)입니다. CAKE나 FQ-CoDel을 쓰고, 속도는 회선이 실제로 내는 속도보다 조금 낮게, OpenWrt 가이드에 따르면 측정 속도의 약 90%로 설정하세요. 그런 다음 다시 테스트하면 등급이 A나 A+로 올라가야 합니다.

업로드 뒤에 줄 선 통화 패킷예시 회선
공유기의 업로드 대기열 내 통화 175 ms 대기그러다 대기열이 가득 차면다음 패킷부터 버림 백업이나 동영상 업로드, 끝없이 이어지는 패킷
유휴21 ms
다운로드 중63 ms
업로드 중196 ms
C부하 시 +175 ms: Waveform 기준 C 등급Waveform
  1. A+<5
  2. A<30
  3. B<60
  4. C<200
  5. D<400
  6. F400+
추가 지연은 부하 중 평균 지연 시간에서 유휴 평균을 뺀 값이며, Waveform 방식대로 다운로드와 업로드 중 더 나쁜 쪽으로 등급을 매깁니다.

패킷 손실의 원인과 해결 방법은?

패킷 손실은 대부분 Wi-Fi, 바쁜 회선(버퍼블로트), 불량 케이블이나 포트, 또는 통신사 네트워크에서 생기며, 테스트의 패턴으로 어느 쪽인지 알 수 있습니다.

다운로드나 업로드 중에만 손실이 생기면 버퍼블로트입니다. SQM을 켜세요. Wi-Fi에서 유휴 상태에 무작위로 손실이 생기면 간섭이나 거리 문제이니 유선으로 다시 테스트하세요. 유선에서도 손실이 생기면 손상된 케이블, 불량 포트, 오래된 공유기 펌웨어일 수 있습니다. 유선 연결에 SQM을 켠 상태에서도 통화 테스트가 손실을 다운로드 쪽으로 보여 준다면, 문제는 대개 공유기 바깥에 있습니다. 테스트의 공유 링크와 CSV를 통신사에 보내세요.

보이는 패턴 선택

다운로드나 업로드 중에만 손실

가능성 높은 원인

버퍼블로트: 공유기나 모뎀의 대기열이 넘침

해결 방법

회선 속도의 약 90%로 SQM(CAKE 또는 FQ-CoDel) 켜기

Wi-Fi에서만 무작위 단발성 손실

가능성 높은 원인

간섭, 거리 또는 약한 신호

해결 방법

더 가까이 가거나, 5 GHz로 바꾸거나, 유선 사용

유선에서도, 유휴 상태에서도 손실

가능성 높은 원인

불량 케이블이나 포트, 오래된 펌웨어

해결 방법

케이블과 포트를 바꾸고 공유기 업데이트

유선에 SQM을 켰는데도 다운로드 쪽 손실

가능성 높은 원인

통신사 네트워크

해결 방법

공유 링크와 CSV를 통신사에 보내기

패킷 손실 테스트, 핑 테스트, 속도 테스트 비교

속도 테스트는 회선이 옮기는 데이터의 양을, 핑 테스트는 왕복 한 번에 걸리는 시간을, 패킷 손실 테스트는 작은 패킷이 얼마나 안정적으로 도착하는지를 잽니다. 서로 다른 세 가지 질문입니다.

세계 각지까지의 지연 시간은 핑 테스트로, 통화가 끊기거나 게임이 버벅일 때는 이 패킷 손실 테스트로, 다운로드가 느릴 때는 속도 테스트로 확인하세요.

비교패킷 손실 테스트핑 테스트속도 테스트
측정 대상손실, 지연 도착, 순서 뒤바뀐 패킷, 지터, 부하 시 지연 시간서버나 리전까지의 왕복 시간다운로드와 업로드 처리량
프로토콜UDP(재전송 없음)ICMP, TCP 또는 HTTPSTCP(재전송이 손실을 가림)
알 수 있는 것통화가 끊기고 게임이 버벅이는 이유서버가 얼마나 멀게 느껴지는지다운로드가 느린 이유

패킷 손실 테스트 자주 묻는 질문

게임에 좋은 패킷 손실률은 얼마인가요?

0%에 가까울수록 좋습니다. Cloudflare 게임 점수는 손실 1% 미만에 만점, 1~5%에 절반을 줍니다. 게임 제작사가 공개한 손실 한도는 없지만, 초당 64번이나 128번 업데이트하는 게임에서는 짧은 버스트도 빗나간 샷이나 뒤로 튀는 캐릭터로 이어지므로 비율뿐 아니라 띠의 버스트도 함께 보세요.

패킷 손실 1%면 나쁜가요?

화상 통화라면 Microsoft의 한도에 딱 걸립니다. Teams의 목표는 15초 구간마다 손실 1% 미만입니다. Zoom은 2% 이하를 권장합니다. 게임에서는 1%도 체감되며, 버스트로 오면 더 그렇습니다. 다운로드와 웹 페이지에는 TCP가 손실된 패킷을 재전송하므로 거의 영향이 없습니다.

속도 테스트는 정상인데 이 테스트에서 패킷 손실이 나오는 이유는?

속도 테스트는 손실된 패킷을 모두 재전송하는 TCP로 실행되므로, 손실은 다운로드를 조금 느리게 할 뿐입니다. 이 테스트는 게임이나 통화처럼 재전송되지 않는 패킷을 보내므로 손실된 패킷이 모두 집계됩니다. 회선이 최고 속도를 내면서도, 특히 바쁠 때 패킷을 버스트로 잃을 수 있습니다.

다운로드 중에만 패킷 손실이 생기는 이유는?

버퍼블로트의 전형적인 징후입니다. 공유기나 모뎀이 대기열에 데이터를 너무 많이 쌓다가 대기열이 넘치면 패킷을 버스트로 버립니다. 부하 테스트에서는 다운로드나 업로드 구간의 손실과 지연 증가로 나타납니다. 공유기의 스마트 큐 관리(CAKE 또는 FQ-CoDel)로 대개 둘 다 해결됩니다.

패킷 손실은 내 쪽 문제인가요, 통신사 문제인가요?

세 단계로 나눠 보세요. 통화 테스트는 패킷을 올라가는 길에 잃는지 내려오는 길에 잃는지 알려 줍니다. Wi-Fi 대신 유선으로 테스트하면 Wi-Fi가 원인인지 알 수 있습니다. 부하를 켜고 끄며 테스트하면 버퍼블로트인지 알 수 있습니다. 유선, 유휴 상태에서도 다운로드 쪽 손실이 계속되면 대개 통신사 문제입니다.

브라우저 테스트로 어떻게 업로드 손실과 다운로드 손실을 구분하나요?

올라갔다 내려오는 패킷만으로는 어디서 잃었는지 알 수 없으므로, 테스트는 Cloudflare 통화 서버로 짧은 무음 음성 통화도 겁니다. Cloudflare가 내 패킷을 몇 개 받았는지 브라우저에 알려 주며 이것이 업로드 손실이고, 돌아오는 길에 빠진 것이 다운로드 손실입니다.

패킷 손실 테스트는 얼마나 오래 해야 하나요?

빠르게 확인하려면 15초 테스트를, 문제가 생겼다 사라졌다 하면 3분 테스트를 실행하세요. 짧은 측정에서 손실이 0이어도 손실이 없다는 증거는 아닙니다. 패킷 750개 중 하나도 잃지 않았어도 손실률은 0.4% 미만 어딘가일 수 있으므로, 이 페이지는 0% 대신 그 범위를 보여 줍니다.

VPN이 패킷 손실 테스트에 영향을 주나요?

네. VPN을 켜면 패킷이 먼저 VPN 서버를 거치므로, 결과는 내 회선만이 아니라 VPN을 거치는 경로를 보여 줍니다. 연결 자체를 테스트하려면 VPN을 끄고, VPN이 무엇을 더하는지 보려면 켜고 테스트하세요.

테스트에 데이터가 얼마나 드나요?

패킷 스트림 자체는 작습니다. 초당 128패킷으로 보내도 1분 테스트에서 많아야 몇 MB입니다. 부하 구간은 각각 테스트 시간의 최대 3분의 1 동안 회선이 허용하는 최대 속도로 다운로드와 업로드를 하며, 다운로드 250 MB, 업로드 100 MB가 상한이므로 종량제나 모바일 연결에서는 부하 옵션을 끄세요.

저장되는 정보가 있나요?

없습니다. 테스트는 브라우저와 가장 가까운 Cloudflare 데이터 센터 사이에서 실행되며, Cloudflare는 암호화된 패킷을 읽지 않고 중계만 합니다. 지난 측정 기록은 이 브라우저에만 남습니다. 공유 링크에는 결과만 담기고 IP 주소는 절대 담기지 않으며, 서명되어 있어 만든 뒤에 링크가 바뀌면 수정된 링크로 표시됩니다.

관련 도구