VPN 다운로드가 직접 연결을 앞지를 수 있는 이유

터널을 연결하고 큰 다운로드를 시작하면, 같은 파일을 터널 없이 받을 때의 대략 두 배 속도로 진행된다. 광고처럼 들리지만 가정용 회선에서 실제 측정일 수 있다. 흔한 원인은 한 포트에 붙은 속도 제한이다. 터널은 전송을 셰이퍼가 보지 않는 곳으로 옮기고, 회선의 실제 용량이 처음으로 드러난다.

즉 중요한 숫자는 VPN이 얼마나 빨랐는지가 아니다. 회선에서 늘 받지 못하던 몫이 얼마였고 왜 그랬는지다.

경로가 아니라 포트를 따라가는 제한

접속 사업자는 가입자별 처리량을 프로토콜이나 목적지 포트로 제한할 수 있고, 포트 80은 흔한 브라우징이 많이 쓰기 때문에 즐겨 쓰는 표적이다. 제한은 첫 패킷부터 적용되지 않는 경우가 많다. 전송은 회선 속도에 가깝게 시작해 버스트 허용량을 태운 뒤 제한된 값에 내려앉는다. 처음 몇 초는 건강해 보이지만 나머지 전송은 그렇지 않다.

같은 바이트를 다른 포트로 보내면 80의 셰이퍼는 그것을 한 번도 보지 못한다. 터널은 홉 하나와 암호화, 자체 부하를 더했는데도 직접 연결을 이긴 것처럼 보인다. 개선된 것은 경로가 아니라 규칙의 부재다.

파일과 목적지를 바꿔도 효과가 이렇게 일관된 것도 같은 이유다. 제한이 포트에 있다면 그 포트로 지나가는 모든 것은 같은 방식으로 행동한다. 파일 크기가 어떻든 상대가 누구든 마찬가지다. 다른 규칙을 끌어들이는 목적지는 다른 곡선을 보여 주고, 그 차이 자체가 진단이다.

정점이 아니라 평탄부를 재라

정점은 전송에서 가장 정보가 적은 부분이다. 버퍼가 차오르는 동안에는 모든 연결이 좋아 보인다. 속도가 어디에서 안정되고 얼마나 머무는지 적어 두라.

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

같은 기기에서, 같은 시각에, 비슷한 네트워크의 호스트를 상대로 두 방법을 연달아 실행하라. 표본 하나로는 아무것도 증명되지 않는다. 각각 두 번씩의 곡선 모양이야말로 버스트 허용량과 안정적 한도를 가른다. 첫 초가 보여 준 값이 아니라 속도가 평평해지는 지점을 적어라. 버스트는 셰이퍼가 제한을 시작하기 전에 주는 바로 그 몫이기 때문이다. 전송이 끝날 때까지 유지되는 조용한 평탄부가 비교해야 할 숫자다.

파일을 이미 압축된 상태로 두어 전송 압축을 설명으로 내세울 수 없게 하라. PDF나 압축 파일이면 그 변수가 사라지고, 터널이 내용을 압축했다는 주장도 할 수 없다. 두 전송이 같은 파일을 쓴다면 남는 차이는 경로와 포트뿐이다. 각 수치 옆에 도구와 포트를 적어라. 그러지 않으면 두 번째 실행은 첫 번째와 비교할 수 없다.

원인을 분리하는 세 가지 비교

순서대로 해 보고 패턴이 드러나면 곧바로 멈춰라. 각각이 다른 설명을 배제하기 때문이다.

1. 같은 다운로드를 평범한 웹 경로와 다른 포트의 전송 도구로, 비슷한 용량의 호스트에서 반복하라.
2. 둘 다 압축되지 않는 파일로 반복해 압축 가능성을 없애라.
3. 터널 서버를 직접 운영한다면 포트 80에 다시 묶고, 양쪽이 합의하도록 클라이언트 프로필을 조정한 뒤 다시 전송하라. 이제 터널이 제한된 웹 속도에 머문다면, 제한은 VPN이 아니라 포트를 따라간다.

세 번째 단계가 결정적이며, 설정 변경이 필요해서 사람들이 가장 많이 건너뛰는 단계이기도 하다. 이것이 없으면 두 가지가 다르다는 것만 보여 줄 뿐, 포트가 원인이라는 것은 보여 주지 못한다.

이 측정이 뒷받침하지 못하는 것

터널이 일반적으로 더 빠르다거나, 무엇을 압축한다거나, 회선의 다른 포트가 제한 없이 열려 있다는 것을 보여 주지 않는다. 이 전송에 대해, 이 회선에서, 이 시각의 이야기를 기술할 뿐이다. 제한은 세션별, 가입자별, 시간대별로 적용될 수 있고 예고 없이 바뀔 수 있다.

직접 경로가 고장 났다는 것도 증명하지 않는다. 제한된 경로도 여전히 동작한다. 일부러 제한한 것이고, 의도된 정책은 수리를 기다리는 결함이 아니다.

그리고 모든 것을 터널로 보내는 일을 정당화하지도 않는다. 포트 80의 모든 응용 프로그램은 제한된 채로 남고, 우회시킨 것은 이제 추가 홉과 추가 고장 방식에 의존한다.

발견을 실행 가능한 것으로 바꿔라

관찰을 판정이 아니라 측정으로 적어라. 포트 80의 대용량 전송은 같은 파일이 다른 포트에서 내는 속도의 절반쯤에 머문다. 이 시간대에, 이 회선에서, 이 표본을 첨부해서라고 쓰면 된다. 그렇게 해야 누군가 조사할 수 있는 지원 요청이 된다.

«VPN이 더 빠르다»는 그런 것이 아니다. 암호화 부하에 대한 답변을 부를 뿐이고, 그 답변은 기술적으로 옳으면서도 아무에게도 쓸모 있는 말을 하지 않는다. 표본 수와 시각, 포트를 첨부해 읽는 사람이 같은 패턴을 재현할 수 있게 하라.

대용량 전송에 다른 포트를 계속 쓰기로 했다면, 자신의 기록에 단서를 남겨라. 대기 소켓을 포트 80으로 옮기면 이미 그곳에 묶여 있는 웹 서버와 충돌하고, 그 결과 생기는 장애는 포트 충돌이 아니라 고장 난 터널처럼 보인다.