중계서버마다 부하에 차이가 있는 이유

Tor는 네트워크 전반의 대역폭을 관리합니다. 대다수 중계서버가 적절히 운영되도록 조처합니다. Tor의 목표는 BitTorrent와 같은 프로토콜과 차이가 있습니다. 저지연 웹페이지 환경은 Tor의 희망사항입니다. 그러려면 빠른 연결을 여유있게 제공하는 환경이 요구됩니다. BitTorrent는 대량 다운로드를 희망하는 사용자들이 많이 이용하므로, 대역폭 전체 사용이 요구됩니다.

현재 Tor 프로젝트에선 신규 대역폭 스캐너을 한창 개발하고 있습니다. 기존대비 훨씬 쓰기 쉽고 유지보수하기도 쉽습니다. 새로운 대역폭 스캐너로 측정되지 못했거나, 낮은 측정치를 보인 중계서버에 대해 진단(diagnostics)할 겁니다.

Tor에 대역폭 스캐너가 필요한 이유가 있나요?

대다수 제공자에서 로컬 네트워크의 최대 속도를 안내하고 있습니다. 하지만, Tor를 사용하는 사용자는 전 세계에 두루 있고, 이들은 한 개 혹은 두 개의 중계서버에 임의로 배정돼 연결됩니다. 따라서 Tor는 해당 중계서버가 전 세계의 네트워크에 잘 연결할 수 있는지 확인해야만 합니다

So even if all relay operators set their advertised bandwidth to their local connection speed, we would still need bandwidth authorities to balance the load between different parts of the Internet.

'표준 중계서버 부하량'은 무엇인가요?

대부분의 중계서버에선 실제 처리량 대비 30%~80%의 부하 수준(loaded)을 보이는 게 일반적입니다. 클라이언트 입장에선 위와 같이 설정돼있는 게 낫습니다. 과도하게 부하가 걸린 증계서버에의 지연시간(latency)가 길어질 수 있기 때문입니다. (Tor는 각 중계서버의 부하가 10% 수준에 머물 수 있도록, 많은 중계서버가 있었으면 합니다. 부하량이 그 수준에 이르면 일반적인 인터넷 만큼 Tor의 속도가 빨라질 거에요.)

중계서버가 느린 원인으로 종종 프로세서가 느려진 점, 연결이 제한량이 이른 점이 꼽히기도 합니다. 그 외엔 보통 네트워크가 느린 게 중계서버가 느린 원인입니다: 다른 Tor 중계서버와의 연결이 불량이거나, 두 연결 사이의 거리가 멀기 때문에 느려지는 것입니다.

중계서버를 제한하는 요소를 알아내는 방법

중계서버를 느리게 하는 요소는 다양합니다. 해당 요소를 찾아내는 방법을 지금부터 알아보겠습니다.

시스템 제한

  • RAM, CPU, 중계서버의 소켓/파일 기술자(socket/file descriptor) 사용량을 살펴보세요.

Tor는 시작 시 이러한 요소를 로그로 기록해둡니다. 다른 요소를 'top'과 같은 도구(tool)로 조회할 수 있습니다.

서비스 제공자(provider)에 의한 대역폭 제한

  • 귀하의 중계서버 제공자와 다른 중계서버간 인터넷 대등접속(대역폭, 지연 속도)를 확인하세요. 미국의 인터넷 서비스 제공자인 Comcast를 통해 전송되는 중계서버는 속도가 종종 느립니다. 북미와 서유럽 이외 지역에서의 중계서버도 일반적으로 해당 지역대비 느립니다.

Tor Network 제한

중계서버 대역폭이 중계서버 자체 측정치로 제한되거나, 디렉터리 기관에서의 측정치로 제한될 수 있습니다. 어떤 기준으로 중계서버의 대역폭이 제한되고 있는지 다음 문답을 통해 알아낼 수 있습니다:

  • 귀하의 중계서버에 제시된 각 투표를 합의 건전성(큰 페이지)에서 확인하세요. 그리고 중앙값도 확인하세요. 귀하의 중계서버에 '디렉터리 기관에서 운영 중(Running by some directory authorities)'이라 표시돼있지 않다면:
    • 잘못된 IPv4 주소나 IPv6 주소로 설정돼있지 않던가요?
    • 다른 네트워크에서 중계서버의 IPv4나 IPv6 주소에 접근할 수 있던가요?
    • 귀하가 운영하는 중계서버의 IPv4 주소에 여러 중계서버가 있진 않던가요?

위 문답에 모두 해당하지 않는다면, 귀하가 운영하는 중계서버의 자체 대역폭 측정치(observed bandwidth)와 자체 대역폭 제한 측정치(bandwidth rate 혹은 limit)를 확인해보세요. Look up your relay on Metrics. '대역폭' 항목에 마우스를 갖다 대면, '관측된 대역폭'과 '중계서버의 대역폭 비율'이 표시됩니다.

좀 더 구체적인 예시를 확인하세요: 합의의 가중치 하락 and 출구 중계서버의 속도 향상.

해결 방법

두 수치 중 가장 작은 게 중계서버에 할당된 대역폭 제한량입니다.

  • 두 수치 중 작은 게 '대역폭 비율(bandwidth rate)'이라면, torrc에 있는 옵션인 BandwidthRate/Burst나 RelayBandwidthRate/Burst를 높게 조정하세요.
  • 두 수치 중 작은 게 '관측된 대역폭(observed bandwidth)'이라면, 자체 측정값이 늘어나지 않는 한, 현재 대역폭에서 더 증가하지 않습니다. 중계서버가 느린 원인을 찾아내야 합니다.
  • 대역폭 측정치의 중앙값(median)에 해당할 경우, 귀하의 중계서버를 대다수 대역폭 기관에서 느리다고 간주한 것입니다. 이 경우엔 왜 대역폭 기관에서 귀하의 중계서버를 느리다고 봤는지 알아봐야 합니다

중계서버 측정을 직접 해보기

귀하의 중계서버가 자체적으로 느리다고 진단한 경우거나 대역폭 기관에서 느리다고 본 경우라면, 귀하가 직접 대역폭을 테스트해볼 수 있습니다:

  • Run a test using tor to see how fast tor can get on your network

    For this, you need to configure a tor client to use use your relay as entry. If your relay has only Guard flag, set EntryNodes with your relay fingerprint in torrc. If your relay doesn't have Guard flag or it has Guard and Exit flags, you can't set your relay as an entry node (see https://gitlab.torproject.org/tpo/core/tor/-/issues/22204), but you can set it as your bridge, even if it is not a bridge. To set your relay as a bridge, add to your torrc:

    Bridge <ip>:<port>
UseBridge 1

    Then download a large file using your SocksPort as a socks proxy. For this, you can use curl, eg:

    curl https://target/path --proxy socks5h://<user>:<password>@127.0.0.1:<socks-port>

    Using different user/password guarantees different circuits. You can use $RANDOM.

    That will give you some idea of how much traffic your relay can sustain.

    Alternatively, you can run relay_bw to test your relay using 2 hops circuits, in a similar way as sbws does.

  • Run a test using tor and chutney to find out how fast tor can get on your CPU. Keep increasing the data volume until the bandwidth stops increasing.