실시간 VPN에 대한 불만에는 실패를 판정할 마감 시간이 필요하며, «낮은 지연»은 그런 마감 시간이 아닙니다. 대화나 원격 세션이 무엇을 전달해야 하는지 정한 다음, 명시된 조건에서 그 요구에 대해 경로를 측정하세요. 늦은 패킷 임계값이 없으면 모든 결과는 논쟁의 여지가 있습니다. 아래 배분은 설계 결정이며, 측정이 답할 대상이 있도록 존재합니다.

프로브를 만지기 전에 마감 시간을 적으세요

마감 시간은 앱과 사용자에게서 나오며, 공급업체의 마케팅 페이지에서 나오지 않습니다. 실시간 음성 통화, 원격 데스크톱 세션, 야간 백업은 전혀 다른 대기 시간을 견디며, 중요한 실패는 보통 중앙값이 아니라 꼬리입니다. 그 숫자를 속한 워크로드와 함께 적으세요.

그다음 배분하세요. 캡처와 패킷화가 예산의 일부를 쓰고, 액세스 링크와 터널이 다른 일부를 쓰며, 수신 측 디지터 버퍼는 의도적으로 패킷을 붙잡고, 앱 처리가 나머지를 가져갑니다. 이 단계들의 이름을 붙이면 터널 암호화가 모든 느린 패킷의 기본 용의자가 되는 대신 비례를 유지합니다.

마지막으로 측정 계약을 네 줄로 정의하세요. 끝점과 방향, 트래픽 형태, 실행 중 조건, 그리고 보고할 결과입니다. 조용한 일요일 표본과 부하가 걸린 화요일 표본은 다른 질문에 답하므로 어느 것을 수집했는지 밝히세요. 네 줄을 모두 채울 수 없다면 실행은 시작할 준비가 되지 않았습니다. 그 체크리스트는 아무도 기억하지 못하는 몇 달 뒤에 두 보고서를 비교 가능하게 만드는 것이기도 합니다.

모든 단계에 예산을 배분하세요

표는 계획 보조물이며 수집된 데이터가 아닙니다. 첫 프로브 전에 각 행의 소유자를 채우세요. 그 단계가 자기 몫을 넘을 때 전화할 사람이 소유자이기 때문입니다.

StageWhat it contributesWho owns it
Capture and packetizationEncoder frame size, aggregationApplication owner
Tunnel and transitEncryption, queueing, path lengthNetwork owner
Receiver bufferDeliberate waiting to absorb variationApplication owner
Application processingDecode and render timeApplication owner

보통 두 행이 사람들을 놀라게 합니다. 수신 버퍼가 지연을 더하는 것은 결함이 아닙니다. 설정된 대로 일을 하고 있기 때문입니다. 그리고 터널의 몫은 앞에 있는 큐보다 작은 경우가 많으며, 특히 업로드 중에 포화되는 업링크에서 그렇습니다.

단계에 소유자가 없으면 예산은 허구입니다. 측정 전에 한 명을 지정하세요. 그렇지 않으면 다음 회의는 누구 숫자가 틀렸는지 싸우는 데 쓰일 것입니다.

정직한 시계로 단방향 지연을 측정하세요

단방향 지연은 마감 시간이 신경 쓰는 숫자이며, 양쪽 끝에 동기화된 시계가 필요합니다. 단방향 지연 메트릭은 결과와 함께 동기화 방법, 해상도, 추정 편차를 보고하도록 요구합니다. 동기화되지 않은 두 호스트는 잘못된 양에 대해 매우 정밀한 숫자를 낼 수 있습니다.

한 줌이 아니라 수백 개의 패킷을 포착하고, 같은 시점에 시계 상태를 기록하세요:

$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3

왕복 시간은 별도의 측정이며, 두 단방향 값을 더한 것이 아닙니다. RTT를 반으로 나누는 것은 대칭 경로와 대칭 큐를 가정하는데, 모바일 업링크 위의 터널은 두 가정을 일상적으로 깨뜨립니다. RTT는 RTT로 보고하고 단방향 예산 밖에 두세요.

꼬리와 늦은 패킷을 보고하세요

분포를 요약하세요: 중앙값, 95번째와 99번째 백분위수, 최악의 경우, 손실, 그리고 마감 시간이 허용하는 것보다 늦게 도착한 패킷 수입니다. 실시간 워크로드에는 평균이 그 숫자들 중 가장 쓸모가 없습니다. 매끄러운 평균은 세 번 중 한 번의 통화를 망치는 꼬리를 숨길 수 있기 때문입니다.

지연 변동은 수신 버퍼에 직접 영향을 줍니다. 버퍼를 늘리면 변동이 숨고 대기가 더해지므로, 스트림은 마감 시간을 넘으면서도 안정해 보일 수 있습니다. 변동에 대한 공식을 고르고, 측정한 구간을 밝히고, 실행 간에 일관되게 유지하세요.

대표적인 교차 트래픽으로 실행을 반복하세요. 유휴일 때 예산을 충족하고 백업 창 동안 놓치는 경로는 스케줄링에 관해 유용한 것을 알려 주었으며, 어떤 단일 조용한 측정도 밝혀내지 못했을 것입니다. 결과 옆에 조건을 기록하세요. 그렇지 않으면 다음 엔지니어는 결코 비교 가능하지 않았던 두 표본을 비교할 것입니다.

실제로 실행하는 워크로드 아래에서 측정된 꼬리가 예산에 맞을 때 설계를 받아들이고, 보고서에 초과한 단계를 명시하여 거부하세요.

관련 글