업로드 중 VPN이 느리게 느껴지는 이유: 대기열 지연

백업 업로드가 시작되고 전송 카운터는 건강해 보이는데 화상 통화는 엉망이 된다. 그 숫자가 암시하는 의미에서 링크에 대역폭이 부족한 것은 아니며, 패킷은 어딘가의 대기열에서 기다리고 있고 대화형 패킷은 대용량 데이터 뒤에 서 있다. 이것이 대기열 지연이며 흔히 버퍼블로트라고 부른다. VPN이 자체 대기열을 더할 수는 있지만 문제를 혼자 만들어 내는 경우는 드물다.

대역폭과 지연은 다른 측정값

처리량은 초당 얼마나 많은 데이터가 이동하는지 답하고, 지연은 패킷 하나가 경로를 지나는 데 얼마나 걸리는지 답한다. 포화된 링크는 큰 잔량을 품고도 좋은 처리량을 보고할 수 있는데, 버스트가 끝나면 대기열이 회선 속도로 빠지기 때문이다. 대화형 트래픽이 먼저 고통을 받는데, 통화는 몇 밀리초마다 패킷이 필요하고 마지막에 큰 파일이 도착하면 되는 것이 아니기 때문이다. 따라서 속도 테스트 결과만 측정하면 당신을 들여다보게 만든 증상이 가려진다.

부하가 걸린 상태의 방향도 살펴보라. 업로드 버퍼가 가득 차면 다운로드 용량이 놀고 있어도 다른 모든 것이 지연될 수 있다.

부하 상태에서 왕복 시간을 측정하라

조용한 링크에서 기준선을 잡고, 통제된 전송 하나가 도는 동안 같은 측정을 반복하라. 절대 수치가 아니라 두 번의 실행을 비교하라.

ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"

첫 번째 명령은 왕복 시간을 표본 추출하고, 두 번째는 속도 테스트 서비스 없이 지속적인 업로드를 만든다. 평평하게 유지되는 기준선 뒤에 수백 밀리초 올라가는 부하 실행, 그것이 찾아야 할 징후다. 일부 네트워크는 ICMP 우선순위를 낮추므로 ping을 단서로 삼고 애플리케이션 자체의 지연 표시로 확인하라. 종량제 링크에서는 반복 가능한 대비가 긴 포화보다 중요하므로 테스트를 짧게 유지하라.

대기열을 병목이 있는 곳으로 옮겨라

대기열 관리는 잔량을 실제로 보유한 장치에서만 도움이 된다. 규칙을 추가하기 전에 인터페이스가 무엇을 하는지 살펴보라.

tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codel

show 명령은 현재 규율과 잔량 및 폐기 카운터를 보고하며, 이 인터페이스가 병목인지 아니면 트래픽을 통과시키는 것인지 알려 준다. 루트 규율을 공정 대기열 알고리즘으로 바꾸면 짧은 흐름이 대용량 데이터와 공유하는 하나의 FIFO 대신 자기 차례를 얻는다. 라우터가 병목일 때는 습관적으로 터널 장치가 아니라 라우터의 WAN 인터페이스에 적용하라. 이전 구성을 남기고 부하 상태의 응답성과 전송 속도를 다시 시험하되, 대량 속도가 조금 낮아지는 것은 쓸 만한 통화를 위한 좋은 거래다.

터널이 바꾸는 것과 숨기는 것

VPN은 암호화와 홉 하나를 더하고, 터널 밖의 장비로부터 개별 흐름도 숨긴다. 상류 장치가 애플리케이션별 우선순위를 제공할 때, 원래 대화가 아니라 암호화된 패킷을 보는 그 장치에게 이것이 중요하다. 터널 자체를 종료하는 라우터는 보는 방식과 작업 부하가 다르며 그 안에서 분류할 수 있다. 어느 배치도 액세스 링크의 대기열을 없애지 못하며, 지연이 쌓이는 곳이 보통 거기다.

지연이 부하를 따르지 않으면 대기열 조정을 멈추고, Wi-Fi 상태, 패킷 크기 문제, 또는 나쁜 출구 경로 하나 같은 다른 곳을 보라. 측정 없이 적용한 대기열 설정은 미스터리를 옮길 뿐이다.