>>35621
Если хочешь разбираться, то разбирайся, читай и посоветованное, и не посоветованное, и всё, что нароешь по теме.

Сначала идёт общее количество TCP- и UDP-соединений с остальными клиентами. (Конечно, в UDP соединений нет, но провайдерский NAT всё же хранит как минимум номер порта и адрес в частной сети, а торрент-клиент — данные о пире на другом конце и состоянии обмена.) Как это ограничение влияет? Допустим, у тебя 100 торрентов, для каждого находится (через трекер, DHT, из ранее замеченных — не важно) в среднем по 10 пиров. С каждым адресом пира надо попытаться соединиться, и либо подождать какое-то время, потому что ответа нет, либо соединиться, обменяться информацией и понять, что оба клиента скачали то, что им нужно было, и друг другу не интересны, либо соединиться, обменяться информацией и начать передавать данные в одну или обе стороны. При стандартных настройках этот процесс будет происходить для 500 соединений одновременно, оставшиеся адреса из общей тысячи будут ожидать и по очереди выбираться взамен тех, с которыми уже связались. Это стандартная циркуляция состояний пиров, которые могут освобождаться от активности и на больший срок (например, если один сидер узнаёт о существовании другого, им вовсе не требуется через 30 секунд снова соединяться и это подтверждать, поскольку маловероятно, что так быстро что-то изменится, можно просто запомнить этот факт на какое-то время). Конечно, если ты компания, которая давит на пиратов, то тебе требуется быстро-быстро-быстро проверить огромное число пиров на огромном количестве торрентов (но для этого эффективнее специальную программу написать), а при обычной работе не мгновенное соединение — норма.

Может случиться так, что в одном или нескольких торрентах тысячи пиров, а в остальных от силы по паре. Следовательно, выбираться для соединения они будут в той же пропорции, и для малопопулярных торрентов работа с пирами будет идти редко. Второй параметр не даёт одному торренту занять собой большую часть пула соединений с пирами, ограничивая их количество.

Для чего это всё нужно? Перенесёмся на 15-20 лет назад. Дохлые офисные и костыльно-провайдерские сети. Файрволы и маршрутизаторы в виде программ под Windows. Железо, которое еле осиливало передать 100 Мб/с между одной парой портов, и то только на удобном трафике с большими пакетами. Да даже серьёзные провайдеры когда-то жаловались, что торрент-клиенты своей массой повышают число пакетов при той же пропускной способности канала вдобавок к тому, что забивают его под крышечку. Кроме того, локально тоже могли быть проблемы. В Windows когда-то приняли гениальное решение обрезать число устанавливаемых TCP-соединений, на которые адресат пока не ответил, чтобы уменьшить скорость распространения червей по офисным сетям (поскольку для использования известных дыр достаточно было попытаться соединиться со всеми адресами из локальных диапазонов и ответившим прислать готовый эксплоит, а нормальные программы так адреса не сканировали). Прошло какое-то время, и торрент-клиенты начали активно работать со многими адресами, появились патчи для tcpip.sys. В некоторых клиентах есть отдельное ограничение как раз для открываемых TCP-соединений, которое на системах с патчем можно было вручную увеличить.

В общем, если клиент использовался в какой-то не слишком работоспособной сети, настройки можно было прикрутить, чтобы жалоб не было. Кроме того, ограничение сверху, даже если до него не доходит у обычного пользователя — это предупредительная мера на случай какой-то хрени. Была история, как uTorrent 2.0 забил сети провайдеров, не имевших запаса по pps, мелкими пакетами, так что позволять каким-то параметрам расти бесконтрольно чревато.

Дальше идёт ограничение числа пиров, одновременно получающих данные. Почему это важно? Данные берутся не из воздуха, а читаются с диска. Практически всегда у нас передаются большие файлы, и разными пирами запрашиваются разные блоки, то есть происходит случайный доступ к далеко расположенным друг от друга данным. Само собой, есть кеширование, и клиент может попытаться предугадать, что пиру ещё понадобится, и одним запросом на чтение получить большой объём данных с диска вместо кучи маленьких чтений в разные моменты, но отдельные пиры и отдельные торренты всё равно независимо друг от друга генерируют случайную активность. На магнитных дисках случайное чтение с постоянным переносом головок гораздо медленнее последовательного, и при увеличении числа и частоты запросов диск начинает тормозить для всей системы. Так у нас есть некоторая консервативная оценка, позволяющая не слишком напрягать диск (и аналогичное ограничение для одного торрента, чтобы на порядки более популярные вещи не занимали все свободные места), потому что тормоза системы при работе хуже, чем пир, получающий свои данные на пять-десять секунд или минут позже.

Ещё посмотрим на такую картинку: допустим, у тебя в давние годы выделенка в целых 128 КБ/с, и ты что-то раздаёшь сотне пиров. Если честно с ними соединиться и поделить скорость на всех, каждый будет по 1 КБ/с медленно тянуть свой кусочек. Сколько времени уйдёт на передачу блока в 1 МБ? При этом кто-то закроет клиент, у кого-то соединение отвалится, и данные, переданные им, уйдут в мусор. Гораздо лучше нескольким пирам впихнуть несколько блоков на нормальной скорости, и пусть они их дальше раздают, потом другим пирам — другие блоки, и так далее всё потихоньку раскидать (за такое поведение отвечает режим super seeding). Ну и в обычной ситуации для торрента с тысячами пиров полезнее не соединяться сразу со всеми и что-то по капельке выдавливать по соединениям, мешающим друг другу, а с несколькими быстро обмениваться. Ещё надо знать, что при скачивании клиенты могут отбрасывать медленных пиров, если есть быстрые (чтобы не ждать пять минут последний кусок, который другой источник пришлёт за пять секунд), а при отдаче — не учитывать их (то есть ограничивается число мощно качающих пиров, а те, кто тянут что-то на 5 КБ/с, и так практически не влияют ни на соединение, ни на производительность).

Какие ограничения подходят для конкретной системы? Это зависит от множества факторов, некоторые из которых меняются с течением времени: количества запущенных торрентов, количества пиров на них, отношения числа сидеров к числу личеров, ширины канала у данной системы, ширины канала у пиров, производительности диска, количества свободной памяти под файловый кеш, алгоритма планировщика запросов ввода-вывода и так далее. Ты проигнорировал совет не трогать и решил заняться позорным шаманством, то есть ковырянием непонятно чего ради непонятно каких изменений. Во-первых, если ты не знаешь, что должно стать лучше или хуже, то как ты поймёшь, стало ли лучше или хуже (само собой, мы не обсуждаем эффект плацебо и пышные фантазии, никак не связанные с реальностью)? Во-вторых, если ты не знаешь, есть ли проблема, то почему ты считаешь, что проблема есть, и что-то надо менять? Вот если бы ты мог указать на конкретную ситуацию, в которой одна из этих настроек тебя ограничивает, вопросов не было бы.

Для того, чтобы не мешать другим устройствам в домашней сети, достаточно установить ограничения скорости загрузки и отдачи, пропорционально меньшие, чем у провайдера по тарифу. (Надо учитывать, что в часы пиковой нагрузки тарифная скорость может явно или неявно поджиматься, и рассчитывать по минимальной.) Если в клиенте есть автоматическое определение свободной ширины канала, можно использовать его, но максимум всё равно поставить в 80-90% от реального, и смотреть, чем заняты люди на других устройствах, и как временные пики перед сбросом скорости влияют на их приложения, чувствительные к задержке (например, видео- и аудиозвонки). Наконец, можно поехать конкретно и в качестве окончательного решения вопроса на роутере настроить QoS, но там обычно либо куски линуксовых настроек выведены, и надо читать целиком мануалы и догадываться, какие очереди там внутри добавлены, и как, либо под этим названием скрывается примитивное решение, когда для среднестатистического пользователя собираются порты и адреса самых популярных игр и сервисов, а всё остальное полагается менее важным, и не факт, что конкретные программы конкретных людей в приоритетный список попадут.