지연 테스트 3가지 수치 비교: ping, 실제 연결 지연, 다운로드 속도 측정의 차이

세 수치는 각각 무엇을 재는가

ping은 내 PC에서 대상 서버까지의 ICMP 왕복 시간을, Tcping은 같은 경로에서의 TCP 왕복 시간을 측정합니다. 둘 다 '내 PC에서 서버까지' 구간만 다루며, 프록시 프로토콜 안으로 들어가지 않고 서버가 트래픽을 제대로 전달하는지도 판단하지 않습니다.

실제 연결 지연은 전체 경로를 측정합니다. TCP 연결 수립, TLS 핸드셰이크, VMess 또는 VLESS 프로토콜 핸드셰이크를 거쳐 첫 번째 유효한 응답 바이트를 받을 때까지입니다. 서버 처리 시간이 포함되므로 ping보다 큰 것이 정상이며, 노드에 문제가 생긴 것이 아닙니다.

다운로드 속도 측정은 처리량을 재는 지표로, 단위는 MB/s 또는 Mbps이며 단위 시간에 얼마나 많은 데이터를 옮길 수 있는지를 나타냅니다. 지연과는 차원이 다릅니다. 40 ms 노드가 3 MB/s에 그칠 수도 있고, 180 ms 노드가 20 MB/s를 낼 수도 있으며 둘 다 흔한 일입니다.

ping과 Tcping의 측정 범위

Tcping은 ICMP ping보다 실제 사용 환경에 가깝습니다. 프록시 연결 자체가 TCP 위에 세워지기 때문입니다. ICMP는 많은 회선에서 속도가 제한되거나 우선순위가 낮아지고, 아예 차단되기도 하므로 'ping은 안 되는데 노드는 정상'인 상황이 모순이 아닙니다.

반대도 성립합니다. ping 값이 낮다고 노드를 쓸 수 있는 것은 아닙니다. 서버가 443 포트만 열어 두고 ICMP와 나머지 포트에 모두 응답하지 않을 수 있으며, 이때 Tcping 443은 결과가 나오고 ping은 나오지 않는 것이 정상 설정이지 장애가 아닙니다.

• 알 수 있는 것: 내 PC에서 이 서버까지의 링크 왕복 시간, 패킷 손실 여부, 지속적인 지터 여부.
• 알 수 있는 것: 서버의 해당 포트가 열려 있는지, TCP 핸드셰이크가 중간에 차단되는지.
• 알 수 없는 것: 서버 프로세스가 트래픽을 정상 전달하는지, 프로토콜 핸드셰이크가 성공하는지.
• 알 수 없는 것: 노드의 실제 처리량, 서버 측 속도 제한 여부.

실제 연결 지연은 왜 ping보다 훨씬 높은가

실제 연결 지연에는 최소 세 번의 왕복이 들어갑니다. TCP 3-way 핸드셰이크 1회, TLS 핸드셰이크 1~2회(TLS 1.3 사용 시 보통 1회), 프로토콜 핸드셰이크와 첫 바이트 1회입니다. 왕복마다 링크 RTT가 더해지므로, 링크 자체가 100 ms라면 실제 연결 지연이 250~400 ms에 들어가는 것은 흔한 범위입니다.

판단 기준은 절댓값이 아니라 같은 묶음 안에서의 상대 순위, 그리고 같은 노드를 여러 번 측정했을 때의 변동 폭입니다. 지역이 다른 노드끼리 절댓값을 비교하는 것은 의미가 크지 않고, 같은 도시에 있는 두 서버라야 직접 비교할 만합니다.

다운로드 속도 측정의 세 가지 전제

다운로드 속도 측정은 편차가 가장 크게 나옵니다. 기본 속도 측정 파일은 대부분 해외에 있어서, 로컬 회선이 100 Mbps라면 측정 상한이 12.5 MB/s이므로 아무리 빠른 노드라도 그 이상은 나오지 않습니다. 측정 전에 로컬 직결로 기준선을 한 번 재 두어야 병목이 노드에 있는지 로컬에 있는지 알 수 있습니다.

v2rayN의 속도 측정 파일 주소는 '설정' → '매개변수 설정'에서 더 가까운 주소로 바꿀 수 있으며, 그러면 측정 결과가 실제 가용 대역폭에 더 가까워집니다. 속도 측정에 쓰는 노드는 실제로 데이터를 전달한다는 점이 지연 테스트와 완전히 다릅니다.

1. 로컬 직결로 기준 대역폭을 한 번 측정해 값을 기록해 두고 비교 기준으로 삼습니다.
2. 후보 노드마다 다운로드 속도 측정을 실행하고, 단일 스레드 결과가 기준에 못 미치면 다중 스레드로 다시 시도합니다.
3. 속도 측정 파일을 가까운 곳에서 접근 가능한 주소로 바꿔 국경을 넘는 구간의 간섭을 줄입니다.
4. 결과가 직결 기준선의 70% 이상이면 이 회선의 처리량은 합격으로 봅니다.

판단 순서: 패킷 손실에서 대역폭까지

세 수치는 정해진 순서로 봐야 하며, 순서를 바꾸면 정반대 결론이 나옵니다. 예를 들어 다운로드 속도 측정을 먼저 보면 대역폭은 크지만 지연이 높은 노드가 앞에 오게 되어, 일상적인 웹 브라우징은 오히려 느려지고 결국 노드를 다시 갈아타게 됩니다.

1. 먼저 Tcping 패킷 손실률을 봅니다. 손실이 5%를 넘는 노드는 바로 제외하고 지연 수치는 더 보지 않습니다.
2. 다음으로 실제 연결 지연의 변동을 봅니다. 같은 노드를 세 번 새로 고쳐 중앙값을 잡고, 변동이 50%를 넘으면 후순위로 내립니다.
3. 실제 연결 지연 중앙값 순으로 정렬해 상위 세 개를 다음 단계로 넘깁니다.
4. 상위 세 개에 다운로드 속도 측정을 적용하고 용도에 따라 고릅니다. 웹페이지와 API는 지연이 낮은 노드, 대용량 파일과 영상은 처리량이 높은 노드를 선택합니다.
5. 연결 후에도 웹페이지가 느리다면 노드를 계속 바꾸지 말고 DNS와 라우팅 규칙을 먼저 점검합니다.

흔한 오해 네 가지

이 네 가지 오해의 공통점은 차원이 다른 수치를 한 줄에 세워 정렬한다는 것입니다. '링크, 핸드셰이크, 처리량' 세 층이 각각 어떤 수치에 대응하는지만 기억하면, 노드를 고를 때 숫자 하나에 휘둘리지 않습니다.

속도 측정 자주 묻는 질문