핑 및 패킷 손실 테스트

작동 방식

1. 다른 다운로드와 스트리밍 종료하기. 테스트 중 다른 기기나 앱이 대역폭을 사용하면 부하 상태 지연 수치가 실제 연결의 동작과 무관한 이유로 부풀려집니다.
2. 이더넷을 우선 사용하거나 공유기 가까이 앉기. Wi-Fi는 인터넷 회선이 어떻든 그 위에 자체 지연 시간과 지터를 추가합니다 — 유선 연결은 측정을 회선 자체로만 제한합니다.
3. 시작을 누르고 탭을 전면에 유지하기. 브라우저는 백그라운드 탭을 느리게 만들어 이 테스트가 의존하는 타이밍 측정을 조용히 왜곡시킵니다.
4. 먼저 무부하 지연 시간, 그다음 부하 상태 지연 시간 확인하기. 첫 번째 단계는 대기 상태의 연결을 측정하고, 두 번째 단계는 같은 지연 프로브와 함께 다운로드를 시작해 바쁠 때 얼마나 느려지는지 확인합니다.
5. 손실률이 아니라 안정성 카운터를 확인하기. 손실률은 없습니다 — 이유는 아래에서 설명합니다 — 하지만 응답이 없었던 프로브 수와 평소보다 비정상적으로 느리게 돌아온 프로브 수가 거의 같은 정보를 알려줍니다.
6. 혼잡 시간대에 다시 실행하기. 지연 시간과 버퍼블로트는 원시 속도보다 시간대에 더 민감합니다 — 저녁 결과는 오후 결과와 의미 있게 다를 수 있습니다.

이 테스트가 실제로 측정하는 것 (그리고 여기서 "핑"이라는 표현이 다소 부정확한 이유)

`ping` 명령어는 원시 ICMP 패킷을 보내고 응답 시간을 측정합니다. 웹 페이지는 그렇게 할 수 없습니다 — 브라우저는 ICMP나 어떤 종류의 원시 소켓에도 접근할 수 없으며, 이는 웹 페이지가 허락 없이 파일을 읽을 수 없는 것과 같은 샌드박싱 이유 때문입니다. 그래서 이 테스트는 가능한 가장 정직한 방법을 사용합니다. Cloudflare 네트워크로 보내는 일반적인 HTTPS 요청의 시간을 측정하고, 서버 자체가 보고한 처리 시간을 뺀 뒤, 순수한 네트워크 왕복 시간만 남깁니다.

• 이것은 시뮬레이션이나 추정이 아니라 실제로 측정된 왕복 시간입니다 — 단지 ICMP 대신 HTTPS를 사용할 뿐입니다.
• 같은 목적지로의 터미널 핑보다 보통 몇 밀리초 더 높게 측정됩니다. TLS로 보호된 HTTP 교환은 서버 처리 시간을 뺀 후에도 단순한 ICMP 에코보다 비용이 조금 더 들기 때문입니다.
• 특정 게임 서버, 통화 서비스, 웹사이트가 아니라 Cloudflare 엣지 위치까지의 경로를 측정합니다 — 특정 목적지까지의 정확한 수치가 아니라 "내 연결이 전반적으로 얼마나 좋은가"의 지표로 여기세요.

이 페이지에 패킷 손실률이 없는 이유

단순히 수치를 생략하는 대신 명확히 설명할 가치가 있습니다. 이 수치의 부재는 빠진 기능이 아니라 의도적인 선택이기 때문입니다.

• 모든 일반적인 웹 요청의 기반인 TCP는 손실된 데이터를 자동으로, 눈에 보이지 않게 재전송합니다. 손실된 패킷은 실패하지 않고, 한 번의 재시도 후 늦게 도착할 뿐입니다.
• 즉, HTTP 요청 시간을 측정하는 웹 페이지는 손실된 패킷을 손실로 인식할 수 없습니다 — 느린 응답만 보이며, 이는 일반적인 혼잡과 언뜻 구분되지 않습니다.
• 그 데이터로 "패킷 손실 0%"를 계산하는 도구는 낮은 손실률을 보고하는 것이 아니라, 손실을 전혀 감지하지 못했다는 사실을 보고하는 것입니다. 이는 불안정한 연결을 진단하는 사람에게 완전히 다른 의미입니다.
• 실제 패킷 손실 측정에는 손실을 숨기지 않는 프로토콜 — 원시 ICMP나 UDP — 이 필요하지만, 이는 정확히 브라우저가 보낼 수 없는 것입니다.

대신 이 테스트가 보고하는 것: 넉넉한 타임아웃 내에 전혀 응답이 없었던 지연 프로브 수와, 해당 연결의 일반적인 프로브보다 훨씬 느리게 돌아온 프로브 수입니다 — 직접 셀 수는 없지만 재전송이 발생했을 가능성을 나타내는 신호입니다. 두 수치 모두 손실 자체는 아닙니다. 둘 다 브라우저가 실제로 수집할 수 있는 가장 가까운 증거입니다.

지연 시간, 지터, 최악의 경우: 각 수치의 의미

이 테스트는 무부하 지연 시간 단계에서 서로 관련되어 있지만 다른 세 가지 수치를 보고합니다.

• 지연 시간(ms): 일반적인 왕복 시간 — 기술적으로는 모든 프로브의 중앙값으로, 평균과 달리 한 번의 느린 이상치에 왜곡되지 않습니다.
• 지터(ms): 그 왕복 시간이 프로브마다 얼마나 변동하는지 — 평균적으로 얼마나 높은지가 아닙니다. 평균 지연 시간이 괜찮아도 지터가 높으면 통화가 끊기는 것처럼 느껴질 수 있습니다.
• 최악의 경우(ms): 95번째 백분위 왕복 시간 — 통화나 게임에서 실제로 체감하게 되는 수치에 가깝습니다. 매우 느린 한 순간이 일반적인 순간보다 훨씬 눈에 띄기 때문입니다.

버퍼블로트: 다운로드가 시작되는 순간 연결이 느려지는 이유

이것은 대부분의 속도 테스트가 완전히 건너뛰는 수치이며, "다른 사람이 뭔가 다운로드하기 전까지는 내 연결이 괜찮다"의 실제 원인인 경우가 많습니다.

• 대부분의 공유기와 모뎀은 전송 전에 나가는 데이터를 버퍼에 대기시킵니다 — 합리적인 아이디어이지만 그 버퍼가 연결에 비해 지나치게 크면 문제가 됩니다.
• 큰 다운로드나 업로드가 그 버퍼를 채우면, 이 테스트의 지연 프로브와 통화나 게임의 모든 패킷을 포함한 다른 모든 패킷이 그 뒤에서 줄을 서서 기다려야 합니다.
• 결과적으로 연결이 유휴 상태일 때는 괜찮았던 지연 시간이 무언가 회선을 포화시키는 순간 20ms에서 300ms 이상으로 치솟았다가, 끝나면 다시 내려갑니다.
• 이 테스트는 정확히 그것을 측정합니다. 지연 프로브를 계속 보내면서 백그라운드에서 포화시키는 다운로드를 실행한 뒤, 이전과 진행 중의 지연 시간을 비교합니다.

등급은 부하 상태에서 지연 시간이 얼마나 증가하는지에 따라 A+부터 F까지 매겨집니다 — A+는 거의 눈치채지 못할 몇 밀리초, F는 수백 밀리초로, 같은 연결에서 휴대폰이 클라우드 백업을 시작하는 순간 통화가 끊기는 종류의 급증입니다.

활동별로 본 좋은 수치의 기준

단 하나의 "좋은" 수치란 없습니다 — 무엇이 중요한지는 연결에서 무엇을 하고 있는지에 전적으로 달려 있습니다.

• 음성 통화: 지터가 낮으면 왕복 약 200ms 미만이 쾌적합니다. 대부분의 VoIP 코덱은 영상보다 더 많이 매끄럽게 처리할 만큼 충분한 버퍼링을 갖추고 있습니다.
• 화상 통화: 지연 시간 150ms 미만, 지터 30ms 미만이면 안정적으로 느껴집니다. 버퍼블로트 등급이 C 이하라면 다른 누군가가 온라인 상태가 될 때마다 통화가 끊기는 실제 원인인 경우가 많습니다.
• 온라인 게임: 지터가 낮은 상태로 50ms 미만이면 경쟁적인 게임에 탁월합니다. 캐주얼한 플레이 대부분에는 50~100ms면 충분합니다.
• 클라우드 게이밍: 가장 엄격한 경우 — 입력뿐 아니라 전체 영상 프레임이 왕복하기 때문에 지터가 매우 낮은 40ms 미만이 필요합니다.
• 웹 브라우징, 스트리밍, 다운로드: 여기서는 지연 시간이 거의 중요하지 않습니다 — 실제로 이를 좌우하는 수치는 인터넷 속도 테스트를 참고하세요.

그래서 이 테스트는 세 가지 원시 수치를 스스로 해석하게 하는 대신, 이러한 각 활동에 대한 판정을 직접 보여줍니다.

Wi-Fi, VPN 등 결과를 부풀리는 요소들

나쁜 결과가 곧 나쁜 인터넷 회선을 의미한다고 단정하기 전에, 자체적으로 지연 시간을 더할 가능성이 가장 높은 요소들을 배제하세요.

• Wi-Fi: 자체 지연 시간을 추가하며, 특히 혼잡한 2.4GHz 대역이나 수십 개의 겹치는 네트워크가 있는 아파트에서는 자체 지터도 추가됩니다 — 인터넷 회선 자체보다 더 큰 영향을 주는 경우가 많습니다.
• VPN: 모든 패킷을 추가 서버(종종 먼 곳에 있는)를 통해 라우팅해, 암호화 오버헤드 위에 실제 왕복 거리를 더합니다.
• 과부하된 공유기: 오래되었거나 성능이 낮은 공유기는 실제 인터넷 연결과 무관하게 부하 상태에서 처리 지연을 추가할 수 있습니다 — 외부에서 보면 버퍼블로트와 똑같아 보입니다.
• 백그라운드 앱: 클라우드 동기화, 자동 업데이트, 같은 네트워크의 다른 기기들이 무부하 테스트라고 생각했던 상황에서 조용히 연결을 포화시키고 있을 수 있습니다.

원인을 가장 빠르게 분리하는 방법: 다른 모든 것을 일시 중지한 상태로 유선으로 테스트를 실행한 다음, 평소의 백그라운드 부하 상태로 Wi-Fi로 다시 실행하세요 — 둘 사이의 차이가 실제 문제가 어디에 있는지 알려줍니다.

결과가 정말로 문제를 나타내는 경우

대부분의 좋지 않은 결과는 위의 설명 중 하나에 해당합니다. ISP에 문의할 가치가 정말로 있는 패턴은 더 적습니다.

• 유선 연결에서 버퍼블로트 등급이 D 또는 F이며, 여러 번의 테스트에서 확인된 경우 — ISP가 지원한다면 현대적인 큐 관리(SQM 또는 fq_codel로 판매됨)로 ISP 측에서 해결 가능한 경우가 많습니다.
• 유선 연결에서 가까운 Cloudflare 위치까지의 무부하 지연 시간이 100ms를 훨씬 넘고, 시간대와 무관하게 지속적으로 그러한 경우 — 이는 가정 내 문제가 아니라 상류의 라우팅이나 혼잡 문제를 가리킵니다.
• VPN을 사용하지 않는 유선 연결에서 응답 없는 프로브가 많은 경우 — 스크린샷과 함께 재현하고 보고할 가치가 있습니다. 공급자 네트워크의 실제 문제를 나타낼 수 있기 때문입니다.
• 새벽 3시에는 괜찮지만 매일 저녁 꾸준히 나쁜 경우 — 지역 네트워크 혼잡이며, 그 구체적인 패턴을 ISP에 직접 알릴 가치가 있습니다.

자주 묻는 질문