Пропускная способность Tor ноды
Я пользуюсь Tor больше 5 лет, держу несколько middle нод, как держал и много лет назад, но в последнее время замечаю несколько странностей в работе сети Tor, которым не вижу очевидного объяснения.
Первая странность – использование полосы. Раньше Tor использовал столько полосы сколько дадут, вплоть до гигабита, сейчас же началась какая-то странная фигня, некоторые ноды пропускают дикие объемы трафика, другие не нагружены вообще.
Одна из моих нод, аптайм которой 2 недели, пропускает 0.7мбит трафика из 80 разрешенных, почему?
Другой пример вот эта нода, пропускает 33мбит из 40 разрешенных.
Что влияет на использование пропускной способности? Как правильно настраивать ноду чтобы она выжирала сколько сказано, не больше и не меньше? Зависит ли это от соотношения BandwidthRate/BandwidthBurst, от ORPort и DirPort, или от каких-нибудь других параметров?
Вторая странность – за последние коды соединения начали работать быстрее, я использую rdp через тор, тогда как раньше не мог к нему подключиться из-за черепашьей скорости. Но tor browser очень часто выдает "The connection was reset", причем не у меня одного, помогает смена ексита. Может в последних версиях Tor что-то сломалось?
Всегда количество нод около 3000. 3000-3200 в среднем. Сейчас под 3500.
Что бы это могло означать?)
Почему бы не написать в рассылку tor-or-talk, спросить?
1 б/с (байт/с)
Много они нагенерят трафа. Суммарная пропускная способность 0,1 Кб/с... WTF?
А ведь уже 4 дня шумят.
Кто-то запустил кучу экситов на ботнете*, но он дурак и не смог отобрать для этого подходящие машины. Там 95% на NAT-ах и, соответственно, совсем не работают.
Ничего хорошего такой вброс не несет. Качество таких нод очень низкое, сеть может начать глючить и тормозить. Имхо, стоило бы ввести регистрацию нод на сайте вручную, через капчу, хотя автоматическая установка ноды тоже бывает нужна. Предыдущий вброс прожил два дня. Интересно, сколько этот проживёт.
*Конфа везде одна, версия Tor одна, везде винда, IP разные из разных стран ⇒ ботнет 100%.
Версии и конфы идентичны, да, но везде не винда, а линух, IP разные, страна одна – США. Все на Амазоне хостятся.
Уже более 4 суток
тормозитживет.комментариев: 9796 документов: 488 редакций: 5664
Вероятность выбора узла зависит от его пропускной способности.
Чей-то очередной исследовательский проект?
Всё не так уж и без облачно. Пока непонятен целиком весь замысел, но картину уже портят.
комментариев: 9796 документов: 488 редакций: 5664
А, так у них быстрые вычисляются в зависимости от процентов узлов всей сети? Тогда после такого вброса (если нет допустимой нижней границы) каждый заурядный узел может получить статус быстрого и сторожевого? Может замысел в этом?
Да.
Получит каждый узел флаги всех статусов, и? Какая может быть разумная цель в этом?
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Нельзя доверять информации из дескриптора. Может узлы и запущены 4 суток, но в сети они могут быть известны только с момента появления в консенсус-документе. И там они появлись только 3 февраля в час ночи по гринвичу.
Флаг со статусом Fast на самом деле мало что решает. Все определяется скоростью, которую замеряют корневые директории. Fast это такой рудимент из прошлого, в современности клиент просто не использует узел без этого статуса. Если рассмотреть амазоновские узлы, то их клиент всё равно использовать не сможет, потому как в килобайтах получается 0.
комментариев: 11558 документов: 1036 редакций: 4118
Но легко может быть, что я ошибаюсь.