같은 터널인데 두 VPN 속도 테스트가 서로 다른 이유

두 번의 실행, 하나의 터널, 그리고 숫자는 세 배 차이 난다. 그 사이 터널은 바뀌지 않았다. 바뀐 것은 측정이다. 보이는 위치를 기준으로 서버를 고르는 테스트 사이트, 느린 시작 하나가 파이프를 채우는지 여섯 개가 채우는지를 결정하는 스트림 수, 그리고 경로가 제대로 쓰이기도 전에 끝나는 짧은 측정 시간. 속도 테스트가 틀린 것은 아니지만, 그것들은 사람들이 던지는 질문보다 좁은 질문에 답한다.

새 출구 주소가 테스트 목적지를 바꾼다

대부분의 테스트 사이트는 측정 서버를 자동으로 고르고, 그 선택은 당신의 연결이 어디서 오는 것처럼 보이는지에도 일부 좌우된다. 터널을 켜면 보이는 국가가 바뀌고, 그래서 선택된 서버가 바뀌며, 비교는 이제 서로 다른 두 호스트로 가는 서로 다른 두 경로를 아우른다.

그 결과는 VPN 측정이 전혀 아니다. 당신이 고르지 않은 서버로 가는 경로의 측정이며, 두 실행 사이의 차이는 터널이 한 어떤 것보다 그 서버의 피어링이 지배할 수 있다.

다른 무엇을 바꾸기 전에 목적지를 고정하라. 신뢰할 수 있는 도구는 모두 서버를 명시적으로 고를 수 있게 하고, 그렇지 않을 때는 결과 페이지가 보통 사용한 서버를 밝히므로, 두 실행이 비교 가능하지 않다는 것을 알아차리기에 충분하다. 사이트가 무엇을 보았는지, 그 선택을 믿기 전에 확인하라:

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

실행 사이에 국가가 바뀌었다면 테스트가 그 뒤에 고른 모든 것도 바뀌었다. 관측된 출구를 각 결과 옆에 적으면 혼란은 대부분 사라진다.

느린 시작은 짧은 테스트 대부분이 끝난 뒤에 끝난다

TCP 연결은 링크 속도로 시작하지 않는다. 작은 혼잡 윈도로 시작해 왕복마다 대략 두 배로 늘어나고, 경로의 용량에 도달하는 것은 여러 번의 왕복 뒤다. 지연이 큰 경로에서 십 초 테스트는 수명의 상당 부분을 그 상승 구간에서 보낼 수 있다.

그래서 지연이 큰 터널은 짧은 테스트에서 마땅한 것보다 낮은 점수를 받고, 그래서 더 긴 실행이 설정을 하나도 바꾸지 않고도 더 높은 숫자를 보고한다. RFC 6349 처리량 프레임워크는 이것을 명시적으로 다루며, 진지한 측정이 정상 상태에 도달할 만큼 길게 도는 이유가 여기 있다. 위성 경로에서 오 초 실행은 도로가 아니라 가속 장치를 재는 것이다.

숫자 하나를 믿는 대신 연결 단계를 보라. Curl은 각 단계를 따로 보고하므로, 시간이 핸드셰이크로 가는지, 상승 구간으로 가는지, 전송으로 가는지 알 수 있다:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

같은 목적지로 연달아 두 번 실행하라. 두 번째 실행이 훨씬 빠르다면 당신은 경로가 아니라 상승 구간을 재고 있었고, 첫 번째만 쓴 비교는 의심스럽다.

스트림 하나와 여섯 개는 다른 것을 잰다

단일 TCP 스트림은 계속 띄워 둘 수 있는 윈도로 제한되며, 그것은 대략 왕복 시간에 속도를 곱한 값이다. 긴 경로에서는 그 곱이 스트림 하나가 쓸 양을 넘으므로, 다운로드 하나는 존재하는 용량을 낮게 보고한다. 여섯 개의 병렬 스트림이 그 틈을 메우고 더 큰 숫자를 만든다.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

두 숫자 모두 사실이다. 단일 스트림 숫자는 다운로드 하나가 어떻게 되는지를 말하고, 그것은 보통 브라우저 탭이 얻는 것이다. 병렬 숫자는 경로가 전체로 얼마나 실어 나를 수 있는지를 말하고, 그것은 토렌트나 분할 다운로드가 쓸 수 있는 것이다. 하나를 다른 것인 양 인용하는 것이 건강한 터널을 이유 없이 바꾸는 길이다.

병렬 결과를 단일 스트림 결과와 비교하는 것은 VPN이 속도를 절반으로 줄였다고 사람들이 결론짓는 가장 흔한 길이다. 방법을 맞춘 뒤 비교하라. 세 번째 명령의 추적은 빠진 맥락을 더한다. 지터가 큰 경로는 두 모드 모두에서 일관성 없는 결과를 내고, 어떤 스트림 수로도 그것은 고쳐지지 않는다.

암호화는 프로세서 시간을, 캡슐화는 바이트를 쓴다

링크가 아무리 빨라도 모든 패킷에서 두 가지 방식이 돈다. 암호화는 바이트마다 CPU를 쓰고, 캡슐화는 링크가 여전히 실어야 하는 헤더 바이트를 더한다. 둘 다 천장으로 나타나며 증상은 다르다.

CPU 천장은 고원으로 나타난다. 스트림을 얼마나 더해도 처리량이 오르지 않고, 링크가 노는 동안 기계의 프로세서는 바쁘다. 작은 라우터나 휴대폰에서는 이것이 실제 한계인 경우가 많고, 그래서 빠른 회선에서도 소박한 터널이 나올 수 있다.

바이트 비용은 더 작지만 일정하다. 헤더가 더 붙으면 패킷당 페이로드가 줄고, 최대 전송 단위가 고정된 경로에서는 큰 전송에서 평균이 느린 것이 아니라 멈춤으로 나타나는 단편화나 블랙홀을 일으킬 수도 있다.

이 셋은 자주 혼동된다. 사용자들이 모두 ‘VPN이 느리다’고 표현하기 때문이다. 더 큰 기계에 반응하는 것은 첫째뿐이고, 더 작은 MTU에 반응하는 것은 둘째뿐이며, 큐 관리에 반응하는 것은 셋째뿐이다.

방법을 기록에 남겨라

남길 가치가 있는 결과는 기기, 접속망, 출구, 측정 서버, 방향, 스트림 수, 시간을 명시한다. 그것이 없으면 두 숫자는 비교할 수 없고, 숫자 하나만 담은 티켓은 사실상 기분이다.

나쁜 실행도 남겨라. 한 출구가 매번 멈춤을 만드는 계열은 평균보다 훨씬 많은 정보를 주며, 멈춤은 바로 평균이 감추는 것이다.

그다음 실제로 신경 쓰는 것을 시험하라. 목표가 큰 다운로드라면 파일을 내려받아라. 목표가 통화라면 유휴 처리량이 아니라 부하 상태의 지연을 재라. 터널은 속도 테스트에서 좋은 점수를 받고도 모든 회의를 알아들을 수 없게 만들 수 있다.