VPN 업로드가 다운로드보다 느린가요? 어떤 한계에 부딪히는지 판단하세요

대부분의 액세스 회선은 비대칭이므로 터널은 보통 다운로드보다 업로드가 느리고, 그것은 결함이 아니라 예상되는 답입니다. 흥미로운 질문은 업로드가 회선 때문에, 이미 그것을 사용하는 다른 무언가 때문에, 아니면 꾸준히 흐르지 않고 멈추는 흐름 때문에 제한되는지입니다. 이 세 가지는 같은 불평을 만들지만 필요한 작업은 다릅니다.

진행 표시줄에서는 똑같아 보이는 세 가지 한계

용량이 첫 번째이며, 이는 터널이 아니라 액세스 제품의 속성입니다. 몇 메가비트의 업링크는 가정용 광섬유와 많은 모바일 요금제에서 정상이며, 암호화 오버헤드는 그 차이에 비하면 작습니다. 캡슐화도 패킷마다 바이트를 더하는데, 이는 유효 처리량을 한 방향만이 아니라 양방향 모두 줄이므로 큰 비대칭을 그것만으로 설명할 수 없습니다.

경합이 두 번째입니다. 클라우드 동기화, 사진 보관함, 업데이트 에이전트는 컴퓨터가 유휴 상태로 보일 때 업로드하며, 같은 회선의 두 번째 기기도 똑같이 합니다. 대기열이 세 번째입니다: 포화된 업링크는 대화형 트래픽을 대용량 데이터 뒤로 밀어내므로 전송 자체는 건강한 진행을 보고하는데도 통화가 끊깁니다.

한 번에 한 방향을 측정하세요

같은 기기, 같은 프로필, 같은 목적지를 사용하고, 경합을 관찰하려는 것이 아니라면 두 방향을 동시에 실행하지 마세요. 첫 실행 전에 자신의 선택적 전송을 일시 중지하세요. 그 사이에 플래그 하나를 둔 두 번의 실행으로 대부분이 정리됩니다.

iperf3 기본적으로 클라이언트에서 보내므로 일반 실행은 업로드 경로를 측정하고, -R 방향을 반전시켜 다운로드를 측정합니다. 몇 분 간격으로 실행하고 평균을 내지 말고 두 숫자를 모두 기록하세요:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

업로드 수치가 다운로드 수치의 작은 일부이고 실행 간에 안정적으로 유지된다면, 형태는 비대칭 액세스 회선과 일치하며 터널은 이야기가 아닙니다. 업로드가 실행 간에 흔들리거나 십 초 후에 무너진다면 계속 읽으세요.

업로드가 어디서 바뀌는지로 판단하세요

한 번에 변수 하나를 바꾸고 어느 방향이 움직이는지 보세요. 더 잘 업로드하는 두 번째 VPN 엔드포인트는 그 지점이나 그곳으로 가는 경로를 가리킵니다. 같은 회선의 두 번째 기기에서 나온 같은 느린 업로드는 회선을 가리킵니다. 다른 회선의 다른 기기도 느리다면 목적지의 인그레스 정책을 가리키며, 이는 로컬에서 고칠 수 없습니다.

같은 작업 부하에 대해 초당 바이트와 경과 시간을 기록하세요, 단일 속도 점수가 아니라. 백업 클라이언트와 속도 테스트는 서로 다른 목적지와 다른 동시성을 사용하므로 그 숫자를 비교해도 아무 답이 되지 않습니다. 작은 요청은 괜찮고 큰 전송만 기어간다면, 한계는 아마 대역폭이 아닐 것입니다.

일상적인 사용에서는 백그라운드 업로드를 제한하거나 회의 시간 밖으로 예약하는 것이 어떤 터널 설정보다 더 도움이 될 때가 많습니다. 그 변화는 결합된 작업 부하로 판단하세요: 더 늦게 끝나지만 더 이상 통화를 망치지 않는 백업이 보통 더 나은 거래입니다.

멈춤이 느림을 이길 때

반복 가능한 지점에서 얼어붙었다가 다시 시작하는 전송은 속도 제한이 아니라 경로 MTU 문제처럼 행동합니다. 터널은 패킷당 유효 페이로드를 줄이고, 그 결과 생기는 ICMP 메시지를 버리는 기기는 송신자를 추측하게 둡니다. 그 패턴은 수리가 속도 조정과 다르기 때문에 자체 테스트가 필요합니다. 꾸준히 낮은 숫자는 용량을 가리키고, 침묵이 뒤따르는 폭발은 경로가 운반할 수 없는 페이로드를 가리킵니다.

분할되면 안 되는 페이로드로 경로를 테스트한 다음, 터널 인터페이스의 MTU를 통과하는 값과 비교하세요:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

큰 프로브가 사라지고 작은 것이 성공한다면, 모든 프로토콜에 대해 인터페이스 MTU를 낮추는 대신 터널에서 TCP MSS를 조이세요. 그 지점 이후의 지속적인 멈춤은 수신 애플리케이션의 저장소나 페이스에 속하며, 네트워크 경로에 속하지 않습니다.

무엇을 바꾸고 무엇을 그대로 둘지

통제할 수 있는 것을 바꾸세요: 백그라운드 전송 일정, 엔드포인트 선택, 멈추는 경로의 MSS입니다. 각 변경을 되돌릴 수 있게 하고 하나의 작업 부하로 제한하세요. 측정이 괜찮다고 말하는 것은 그대로 두세요, 회선에 이미 맞는 다운로드 속도도 포함해서요.

프로필, 엔드포인트, 시간대와 함께 변경 전후 숫자를 적고, 엔드포인트를 따라 움직이는 업로드 문제는 라우팅 문제이며, 기기를 따라 움직이는 문제는 로컬 문제이기 때문입니다. 그 기록이 모호한 불평을 결정으로 바꾸며, 같은 명령의 두 번 실행이면 충분합니다.