VPN 다운로드가 서버 업로드로 제한되는 이유

클라이언트는 빠른 하향 링크를 보여 주고, 서버는 광 회선에 붙어 있는데도 전송은 기어갑니다. 사람들이 비교하는 숫자는 보통 클라이언트 요금제에 인쇄된 숫자이지만, 패킷은 실제로 먼저 서버의 외부 접속 링크를 지납니다. 그 링크가 전송이 맞춰 들어가야 할 예산입니다. 작은 가정용 회선에서는 경로에서 가장 작은 숫자입니다.

당신이 읽은 숫자는 반대 방향이었습니다

원격 클라이언트로 향하는 다운로드는 터널의 서버 쪽에서 업로드 용량을 소비합니다. 서버의 광고된 다운로드 속도는 반대 방향을 설명하며 이 방향에 대해서는 아무것도 말해 주지 않습니다. 같은 비대칭은 클라이언트가 업로드할 때 뒤집히므로, 한 방향은 괜찮게 느껴지는데 다른 방향은 쓸 수 없을 수 있습니다.

캡슐화 오버헤드와 경쟁 트래픽은 같은 예산의 일부를 소비합니다. 클라이언트만 측정하는 속도 테스트에서는 둘 다 보이지 않습니다.

경로를 예산으로 적으십시오

패킷이 넘어야 할 모든 경계를 나열하고 각각에 같은 단위의 숫자를 부여하십시오. 소스에서의 전달, 서버에서의 처리, 서버의 상향 링크, 중간 경로, 클라이언트의 하향 링크, 클라이언트에서의 처리가 모두 해당합니다. 사용 가능한 속도는 그중 가장 작은 값에서 오버헤드를 뺀 것이며, 그 상한을 넘는 어떤 조정도 결과를 바꾸지 않습니다. 측정 전에 목록을 적어 두십시오, 어떤 숫자를 믿지 말아야 하는지 알려 주기 때문입니다.

서버의 상향 링크가 20 Mbit/s이고 클라이언트의 하향 링크가 100 Mbit/s이면, 서버는 클라이언트가 알아차리기 훨씬 전에 전송을 제한합니다. 오버헤드와 동시 전송이 있으면 몫이 더 줄고, 포화된 상향 링크는 확인 응답도 지연시켜 TCP 전송을 원시 상한 아래로 떨어뜨립니다. 두 효과 모두 요금제 비교에는 나타나지 않습니다.

메가비트와 메가바이트를 구분하고, 각 숫자가 암호화된 링크 트래픽을 재는지 응용 프로그램 페이로드를 재는지 밝히십시오. 이 둘을 섞는 것이 예산이 맞지 않는 것처럼 보이는 가장 흔한 이유입니다. 모든 숫자에 단위와 측정 지점을 붙이십시오.

보드가 실제로 비용을 발생시키는 곳

접속 링크가 충분히 커지면 엔드포인트 하드웨어가 보이기 시작하고, 그때서야 프로세서가 문제가 됩니다. 모델, 인터페이스 배치, 사용 중인 구현을 확인하십시오. 초기 보드의 공유 버스에 대한 관찰은 이후의 모든 리비전을 설명하지 않습니다.

단일 CPU 평균 대신 개별 처리 경로를 비교하십시오. 적당한 전체 부하는 패킷마다 모든 작업을 하는 포화된 코어 하나를 가릴 수 있고, 클럭 주파수는 성능 점수로서 프로세서 설계 사이를 옮겨 가지 않습니다. 작은 패킷은 큰 패킷보다 바이트당 비용이 더 들기 때문에 패킷 속도는 처리량만큼 중요합니다. 실제 워크로드가 쓰는 패킷 크기로 측정하십시오.

열과 전력 한계도 지속 동작을 결정합니다. 짧은 버스트는 훌륭해 보일 수 있지만 십 분짜리 전송에서는 스로틀링되므로, 몇 초짜리 벤치마크는 야간 백업에 나쁜 지침입니다.

공급업체의 성능 지침은 접속 대역폭, CPU, 패킷 처리, 전송, 패킷 크기를 서로 다른 제약으로 나눕니다. 암호를 바꾸기 전에 읽을 가치가 있습니다, 암호 변경은 애초에 제약이 아니었던 경계를 거의 움직이지 않기 때문입니다.

암호를 바꾸기 전에 측정하십시오

터널을 통해 실제로 달성한 속도를 보고하는 방향별 테스트를 실행한 다음, 비교를 위해 같은 테스트를 원시 인터페이스에서 실행하십시오. 이 두 숫자의 차이가 터널의 비용이며, 두 상한 중 작은 쪽이 어느 경계를 공격해야 하는지 알려 줍니다.

비교하는 동안 보안 정책은 그대로 두십시오. 약한 암호나 오버클럭한 보드로 얻은 예전 결과는 현재 배포의 계획이 아닙니다.

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

같은 실행의 엔드포인트 관찰 옆에 방향별 결과를 보관하십시오. 다음 변경은 사양표에서 가장 작아 보이는 부품이 아니라 측정된 상한을 겨냥해야 합니다.