다운로드는 빠른데 왜 모든 클릭이 느리게 느껴질까

큰 파일을 빠르게 내려받은 뒤 모든 클릭이 느리게 느껴지는 것은 모순이 아니다. 용량은 초당 얼마나 이동할 수 있는지를 말하고, 왕복 시간은 유용한 일이 일어나기까지 교환이 얼마나 걸리는지를 말한다. 전자를 개선해도 후자에는 아무 영향이 없으며, 사람이 입력하거나 클릭하거나 통화할 때 체감하는 것은 후자다. 연결이 아니라 불만을 측정하라.

빠른 파일, 느린 클릭: 두 가지 다른 숫자

대량 전송은 데이터를 끊임없이 움직이므로 개별 요청이 기다리는 동안에도 건강한 속도를 보고할 수 있다. 많은 벤치마크는 여러 연결을 동시에 열어 단일 요청이 느린 채로도 총합 수치를 높인다. 두 결과는 양립하며, 지연을 호소하는 사용자에게 더 높은 수치를 인용하는 것이 신뢰를 잃는 방식이다.

페이지 로딩은 이름 확인, 연결 설정, 요청, 응답, 그리고 종속 요청이 이어지는 작은 교환의 연쇄다. 각 단계가 왕복 시간을 다시 지불하므로 지연이 큰 경로는 용량이 넉넉해도 느리게 느껴진다.

터널은 자체 이동과 처리를 더하며, 지도 위의 라벨보다 경로가 더 중요하다. 같은 나라의 두 출구도 한 목적지까지 가는 길이 크게 다를 수 있다. 이십 밀리초 차이도 페이지 체감을 바꾸기에 충분하지만 처리량 수치는 거의 움직이지 않는다. 그래서 출구 선택은 깃발 아이콘이 아니라 지연 샘플을 따라야 한다.

불만을 측정하라, 연결이 아니라

사용자가 한 문장에 맞는 측정을 고르라. 느린 다운로드에는 올바른 방향의 지속 속도가 필요하고, 끊기는 통화에는 그 앱 자체의 통계가 필요하며, 느리게 시작하는 페이지에는 이름 확인과 설정 시간이 필요하다.

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

첫 번째 명령은 예측 가능하게 응답하는 호스트까지의 왕복 샘플을 주고, 두 번째는 첫 바이트까지의 시간과 한 연결의 지속 속도를 보고하며, 세 번째는 네 개의 병렬 스트림으로 총 처리량을 측정한다. 같은 날 같은 시각에 같은 목적지를 상대로 실행하라, 아침 샘플과 저녁 샘플을 비교하면 측정이 아니라 이야기가 나오기 때문이다.

출구를 비교할 때는 목적지를 고정하라. 서버와 터널을 동시에 바꾸면 변수가 하나에서 둘이 되고, 결과는 어느 쪽이 중요했는지 알려 주지 못한다. 단일 샘플은 경로 변경이나 시끄러운 일 분에 걸리기 쉬우므로 각 출구를 최소 세 번 실행하라. 최선의 값보다 중앙값이 더 유용하다.

ICMP는 답이 아니라 단서로 다루라. 응답하는 호스트가 에코 요청을 당신의 앱이 쓰는 경로와 다른 경로로 처리할 수 있고, 응답 하나가 사라졌다고 모든 앱이 패킷을 잃고 있다는 증거는 아니다.

부하 시 지연은 대기열 문제다

사람들을 가장 혼란스럽게 하는 패턴은 유휴일 때는 괜찮아 보이지만 백업 중에는 쓸 수 없게 되는 연결이다. 그것은 용량이 아니라 대기열이다. 포화된 업링크는 다른 모든 패킷 앞에 버퍼를 쌓으므로 키 입력 하나가 업로드의 일부 뒤에서 기다린다.

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

첫 번째 명령은 백그라운드에서 지연을 샘플링하고, 두 번째는 반대 방향을 포화시킨다. 전송 중에 ping 시간이 치솟았다가 나중에 회복되면 경로 결함을 발견한 것이 아니라 bufferbloat를 재현한 것이다. 해결은 보통 대기열 관리 설정, 더 낮은 백그라운드 속도, 또는 대량 전송을 대화형 경로에서 떼어내는 것이다.

선택적 백그라운드 트래픽을 줄이는 것이 출구 국가를 바꾸는 것보다 자주 더 도움이 된다. 더 저렴하고 되돌릴 수 있으며 일 분 안에 시험할 수 있다. 대기열을 관리할 수 없다면 큰 업로드를 근무 시간 밖으로 예약하고, 낮에 돌아야 한다면 속도를 제한하라. 라우터가 지원한다면 대기열 관리 설정이 더 나은 해결이다.

한 가지만 바꾸고 같은 것끼리 비교하라

유휴 지연이 크면 목적지를 고정한 채 출구를 비교하고, 다음으로 최적 후보의 경로를 비교하라. 정상 처리량이 낮으면 그것들은 다른 한계이므로 대신 용량, 서버 부하, 클라이언트 처리를 보라.

무엇을, 어느 목적지를 상대로, 몇 시에, 어떤 설정으로 측정했는지 적어 두라. 이 네 가지 사실이 없으면 비교를 재현할 수 없고, 다음 사람은 처음부터 시작한다.

그다음 티켓의 주장에 도구를 맞추라. "인터넷이 느리다"는 측정이 아니라, "이 호스트까지 첫 바이트에 900 ms가 걸렸지만 처리량은 좋았다"는 측정이며, 용량이 아니라 지연을 직접 가리킨다.