Tor가 VPN보다 느리게 느껴지는 이유: 클릭과 다운로드

다운로드가 정상 속도로 진행되는데도 페이지가 끈적하게 느껴진다면 그것은 대역폭이 아니라 왕복 횟수를 말하는 것이다. VPN은 암호화된 홉을 하나 더하고 Tor 회로는 여러 개를 더하며, 홉이 늘어날 때마다 유용한 바이트가 움직이기 전에 핸드셰이크 비용이 든다. 그 비용은 짧은 연결을 많이 여는 페이지에서 드러나고 한 번의 큰 전송에서는 거의 사라진다. 패턴이 보이면 논쟁은 어느 도구가 더 빠른가에서 벗어난다.

증상은 용량이 아니라 설정 비용을 가리킨다

페이지 로드는 이름 조회, 전송 핸드셰이크, TLS 핸드셰이크, 그리고 첫 요청으로 이어지는 의존적인 교환의 연쇄다. 경로의 각 홉은 무언가 그려지기 전에 자기 왕복을 그 연쇄에 삽입한다. 큰 다운로드는 같은 설정 비용을 한 번 치르고 나서 흐르며, 두 작업 부하가 어긋나는 이유가 바로 그것이다.

네트워크 패널에서는 합계가 아니라 첫 바이트까지 기다린 시간을 읽어라. 짧은 콘텐츠 다운로드에 긴 대기가 있으면 왕복 횟수를, 대기가 짧고 콘텐츠 다운로드가 길면 처리량을 가리킨다. 두 번째 목적지에 대해서도 반복하되, 붐비는 릴레이 뒤의 호스트 하나로는 아무것도 증명되지 않는다. 전송은 좋은데 클릭이 느리다면 대역폭보다 훨씬 먼저 설정 비용을 의심하라.

지연과 용량은 서로 다른 방식으로 실패한다

측정을 두 번 하면 혼란의 대부분은 저절로 풀린다. 지연은 교환당 고정 비용이고 용량은 시간에 따른 속도이므로, 한 경로가 전자에 강하고 후자에 약할 수 있다. 멀리 있는 종단점도 프로세서가 유휴하면 작은 요청에 빨리 응답하지만, 지속적인 전송은 업링크가 허용하는 만큼으로 제한된다. 사용자는 이 분리를 빠른 클릭 뒤에 거의 움직이지 않는 진행 표시줄이 따라오는 것으로 경험한다.

지속적인 전송으로 용량을 시험하고 속도가 안정적인지 톱니 모양인지 보라. 여러 번 반복한 작은 요청으로 지연을 시험하고 최선의 표본이 아니라 산포를 읽어라(산포가 넓으면 평균이 시사하는 것보다 나쁘게 느껴진다). 변경 전후로 두 수치를 모두 기록하지 않으면 나중에 잘못된 변수에 공을 돌리게 된다.

둘을 하나의 숫자로 다루면 당신이 신경 쓰는 측정을 결코 움직이지 않는 수정이 나온다. 지연 불만에 대역폭 업그레이드로 답하는 가장 흔한 방식이 이것이다.

양파 라우팅은 당신이 고르지 않은 홉을 더한다

Tor 회로는 보통 가드, 중간 노드, 출구라는 세 개의 릴레이를 쓴다. 클라이언트는 지도가 아니라 합의에서 그것들을 고르므로 경로는 목적지까지의 직선보다 훨씬 길 수 있다. 각 릴레이는 다른 사람의 트래픽도 나르므로 당신의 스트림은 그 릴레이에 남은 용량을 나눠 쓴다.

회로 재사용은 새 스트림이 또 다른 구축 비용을 치르는 대신 기존 회로에 올라탈 수 있어 비용을 누그러뜨린다. 요청마다 새 회로를 짓는 클라이언트는 설정 비용을 거듭 치르고 재사용하는 쪽보다 훨씬 나쁘게 느껴진다. 출구 선택도 중요한데, 부하가 무거운 출구가 있고 어느 출구에 도착했는지 화면은 알려주지 않는다. 이 공유가 설계의 요점이며 지연을 고정값으로 맞출 수 없는 이유이므로, 느린 출구 하나는 이 구조를 버릴 약한 이유일 뿐이다.

연쇄의 순서를 바꾸면 실험이 바뀐다

VPN을 먼저 하고 Tor를 나중에 하는 것은 Tor를 먼저 하고 VPN을 나중에 하는 것과 다른 실험이다. 전자에서는 VPN 종단점이 회로 전체를 나르므로 당신의 접속망은 VPN 주소만 알게 된다. 후자에서는 VPN 연결 자체가 양파 경로 안에서 나르며 출구는 VPN 트래픽을 본다. 둘 다 정당한 설계이고, 어느 하나를 맨 VPN과 비교하면 다른 것을 재는 셈이므로, 둘을 조합하는 문제에 관한 Tor 프로젝트의 페이지는 시간의 질문이 되기 전에 무엇을 숨기려는지의 질문으로 틀 짓는다.

기기, 접속망, 목적지를 고정하고 실행 사이에 요소를 정확히 하나만 바꿔라. 서버, 회로, 시험 호스트를 함께 옮기면 누구도 귀속시킬 수 없는 차이가 생긴다. 최적화하기 전에 각 배치가 누구에게 무엇을 숨기는지 적어 두어야 하며, 숨기고 싶던 것을 드러내는 빠른 연쇄는 개선이 아니다.

두 번째 실행을 견디는 비교

실제로 쓰는 목적지를 두세 개 골라, 작은 자원을 많이 끌어오는 페이지와 큰 전송 하나를 포함해 각각에서 같은 상호작용의 시간을 재라. 하루 중 다른 시각에 전체 측정을 반복하라.

상호작용 작업은 나쁜 순간으로 평가되므로 가장 빠른 표본이 아니라 중앙값과 최악의 경우를 보고하라. 클라이언트, 종단점 또는 출구, 그리고 그 실행에서 회로나 터널을 재사용했는지 적어라. 변경이 중앙값을 개선하면서 꼬리를 악화시킨다면 그것은 승리가 아니라 거래이며, 사용자가 알아차릴지를 결정하는 것이 진짜 결정이다.