Классический форум-трекер
canvas not supported
Нас вместе: 4 238 725

uTP в uTorrent 1.8 и выше: что, зачем, как?


Страницы:   1, 2, 3 ... 14, 15, 16  След. 
 
RSS
Начать новую тему   Ответить на тему    Торрент-трекер NNM-Club -> Информация и поддержка -> Техподдержка форум-трекера

Какой протокол больше подходит торренту и лучше работает?
Старый добрый TCP
26%
 26%  [ 219 ]
Новый uTP
31%
 31%  [ 258 ]
Кто здесь?
42%
 42%  [ 348 ]
Всего голосов : 825

Автор Сообщение
anonymous
Стаж: 16 лет 2 мес.
Сообщений: 3102
Поблагодарили: 100049
0%
Попробую собрать всё в один пост, любые исправления, дополнения и комментарии как всегда приветствуются.

Пара слов про TCP и UDP. Первый расшифровывается как Transmission Control Protocol, или протокол управления потоком. Он удобен тем, что даёт использующей его программе гарантию, что данные дойдут до адресата целыми, полностью и в том порядке, в котором были отправлены. Его использование требует предварительной установки соединения и его закрытия в конце. Этакое создание "трубы" через которую будет идти обмен данными. UDP же не предоставляет никаких гарантий что данные дойдут, или что дойдут в правильном порядке. Он только позволяет переслать небольшой блок данных (датаграмму) от одного адреса другому. Вся работа по проверке доставки, и при необходимости - повторной посылке, ложится на саму программу.

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

При этом, если посылающий сидит на широком канале, а принимающий - на модеме, то первый сразу отправляет большой блок данных, который может быстро дойти до провайдера второго, и потихоньку просачиваться в модем. В это время первый, не получив подтверждения о получении, перешлёт часть кусков заново. Ещё раз, и ещё, в результате магистраль провайдера оказывается забита этой ненужной перепосылкой. Одна из основных целей uTP - устранить эту лишнюю нагрузку на провайдеров от P2P-трафика.

Латентно uTP появился в µTorrent версии 1.8, но умел принимать только входящие uTP-соединения, инициировать их сам - не умел. Впервые это научилась альфа-версия 1.9, потом стало возможным включить это и в новых версиях 1.8 ключиком bt.transp_disposition. Его значение от версии к версии менялось, но сейчас устаканилось на следующих битовых флагах:

1 - разрешить инициировать исходящие TCP-соединения,
2 - разрешить инициировать исходящие uTP-соединения,
4 - разрешить принимать входящие TCP-соединения,
8 - разрешить принимать входящие uTP-соединения,
16 - новый uTP заголовок, который поддерживается только с версии 2.0 т.е. соединений с 1.8 не будет

Таким образом, 13 (1+4+8), значение по умолчанию в последних версиях 1.8, означает возможность принимать все виды соединений, но самостоятельно устанавливать только TCP. 15 (значение по умолчанию в 2.0) разрешает все виды как исходящих так и входящих соединений. Чтобы запретить uTP вообще (если он вызывает какие-либо проблемы) надо поставить 5 (1+4). Стоит ли ставить 15 в 1.8 - вопрос спорный, на официальном форуме пишут что поддержка uTP в версии 2.0 намного лучше, поэтому скорость в 1.8 может быть хуже, чем по TCP.

В версии 2.0 также появилась поддержка UDP-трекеров. Для трекера вообще TCP очень излишний и требует много лишних ресурсов пакетами установки/закрытия соединения, поэтому для открытых трекеров UDP - благо. Например, последнее время трекер anirena очень глючит по TCP и далеко не с первого раза отвечает, DHT там часто запрещён, а UDP-трекер работает прекрасно. Но для закрытых трекеров он не подходит, т.к. не позволяет послать пасскей, чтобы идентифицировать таким образом качающего. Так что нам он не подходит.

Ещё в 2.0 появится метод обхода некоторых NAT (STUN), что поможет соединяться большему числу NAT-страдальцев, хотя будет работать не во всех случаях.

Лично меня из всех новшеств 2.0 больше всего порадовал TCP Rate Control. Он позволяет подстраивать скорость и TCP-соединений так, чтобы они не мешали другим приложениям и минимизировать лишнюю перепосылку пакетов, о которой написано выше. Раньше это достигалось установкой cFos-драйвера, в котором можно было поставить низкий приоритет торренту, высокий - браузеру, а с версией 2.0 этого больше не требуется. Управляется это опцией bt.tcp_rate_control, если вам важнее чтобы торрент не мешает другим интернет-приложениям - его стоит включить, если важна максимальная скорость торрента - есть смысл отключить, на официальном форуме пишут что это иногда скорость увеличивает.

Добавление: в uTP это делается всегда, даже в версии 1.8, а скорость TCP-трафика подстраивается под загрузку канала только в 2.0.

Впрочем, тут есть интересный момент, что с ней или по uTP исходящий канал может забиваться на 95%, а без неё только с TCP - на 100%, но эта разница в 5% может оказаться той самой излишней перепосылкой одних и тех же пакетов, что канал забивает, а реальной пользы не приносит, так что imho не всегда когда канал чуть недозабивается это значит что новая версия хуже.

Ещё в обсуждениях часто мелькает ключ net.calc_overhead. Если он включен, то при настройке скорости учитывается и служебный трафик - запросы блоков, подтверждения, уведомления какие блоки у кого есть и т.п. Если отключен - считаются только сами блоки данных. Поэтому раньше советовали ограничивать исходящий канал в торренте до 80-90% от реального, иначе он весь забивался отправляемыми блоками, и уведомления о получении блоков и запросы новых не успевали проходить, поэтому серьёзно страдала скорость скачивания. Опять же, на широких каналах некоторые пишут что при выключении этой опции скорость чуть выше, но может это глюк бета-версии и в релизе всё будет нормально.

Тут ещё есть такой момент, в котором я не уверен на 100%, но кажется что служебного трафика в uTP больше. Ибо в каждой маленькой датаграмме надо передавать что это за блок, от какого торрента, а по TCP можно посылать большие блоки, не подписывая каждый кусочек. Впрочем, тут будет служебный трафик самого TCP, так что не факт что он сильно "экономичнее".

Ещё нельзя не упомянуть такое явление, как "шейпинг" или "резание" P2P-трафика некоторыми провайдерами. Для России это (пока?) не актуально, а на открытых трекерах, где много пиров со всего мира, скорость по uTP значительно выше.

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

Другие "продвинутые" опции, на которые можно обратить внимание:
bt.connect_speed - сколько максимум новых соединений можно устанавливать в секунду (стоит увеличить, у меня стоит 80),
net.max_halfopen - про это много писалось, и менять стоит вместе с патчем tcpip.sys, хотя с протоколом uTP это уже не важно.
net.utp_target_delay - это некий целевой "пинг" при подстройке соединений, в некоторых случаях при его увеличение где-то до 400-500 скорость лучше.
peer.disconnect_inactive_interval - через сколько секунд закрывается соединение с пиром, с которым нет обмена данными, актуально больше для открытых трекеров где больше народу и "плохих" пиров, либо на случай сетевых глюков - чтобы быстрее определять разрыв соединения и переустанавливать его. в некоторых случаях имеет смысл понизить до 90-120.

Добавлено спустя 3 минуты 5 секунд:

Версия 2.0 хотя и бета - вполне стабильная, скачать можно тут: http://forum.utorrent.com/viewtopic.php?id=60602

Добавлено спустя 3 часа 50 минут 31 секунду:

Вопрос к тем, кто голосует за TCP - почему?
Azger
Стаж: 15 лет 7 мес.
Сообщений: 301
Ratio: 6.868
Раздал: 4.387 TB
Поблагодарили: 648
93.75%
Откуда: Днепр
ukraine.gif
Цитата:
Вопрос к тем, кто голосует за TCP - почему?


Один из плюсов TCP — это его способность сообщать о недополучении данных, а в случае крупной потери — уменьшать скорость передачи, чтобы не перегружать сеть. У uTP ничего подобного нет: он будет продолжать отправку, даже если линия будет забита напрочь.

_________________
Namo tassa bhagavato arahato samma sambuddhassa
anonymous ®
Стаж: 16 лет 2 мес.
Сообщений: 3102
Поблагодарили: 100049
0%
Azger писал(а):
uTP ничего подобного нет

как раз наоборот
r0k0t
 
Стаж: 15 лет 7 мес.
Сообщений: 106
Ratio: 19.085
Поблагодарили: 1967
100%
Откуда: уже отсюда
benin.gif
alex14san писал(а): link

Версия 2.0 хотя и бета - вполне стабильная


попробовал - упала через 5 минут после запуска :( - Win7
anonymous ®
Стаж: 16 лет 2 мес.
Сообщений: 3102
Поблагодарили: 100049
0%
r0k0t писал(а):
Win7

м... надо на офф. форуме читать, там точно кэширование сильно глючит - советуют отключать...
Azger
Стаж: 15 лет 7 мес.
Сообщений: 301
Ratio: 6.868
Раздал: 4.387 TB
Поблагодарили: 648
93.75%
Откуда: Днепр
ukraine.gif
alex14san писал(а): link
Azger писал(а):
uTP ничего подобного нет

как раз наоборот


Поподробней? :смущение:
Где это написано? :незнает:

_________________
Namo tassa bhagavato arahato samma sambuddhassa
Kavasar
Релизер
Стаж: 16 лет 2 мес.
Сообщений: 776
Ratio: 47.75
Раздал: 14.42 TB
Поблагодарили: 22914
100%
Откуда: Необъятные просторы Земли
cod4.gif
Цитата:
Таким образом, 13 (1+4+8), значение по умолчанию в последних версиях 1.8, означает возможность принимать все виды соединений, но самостоятельно устанавливать только TCP. 15 (значение по умолчанию в 2.0) разрешает все виды как исходящих так и входящих соединений. Чтобы запретить uTP вообще (если он вызывает какие-либо проблемы) надо поставить 5 (1+4). Стоит ли ставить 15 в 1.8 - вопрос спорный, на официальном форуме пишут что поддержка uTP в версии 2.0 намного лучше, поэтому скорость в 1.8 может быть хуже, чем по TCP.

Действительно, столкнулся с такой проблемой (версия 1.8.4) - месяц мучался, стояло "13" - скорость плавала кошмарно (с максимальной в нуль за пару секунд). Поставил "15" - скорость стабилизировалась но на самом минимуме. Вчера вечером, установил значение "5" - до сих пор скорость стабильная на максимуме - спасибо техникам клуба :приветствую:

_________________
Приобретение денег требует доблести; сохранение денег требует рассудительности; трата денег требует искусства. (Бертольд Авербах)
Azger
Стаж: 15 лет 7 мес.
Сообщений: 301
Ratio: 6.868
Раздал: 4.387 TB
Поблагодарили: 648
93.75%
Откуда: Днепр
ukraine.gif
Возможно провайдер резал udp...
У меня сейчас utorrent 2.0 beta и стоит 15 (в тестовых целях), пока все нормально.

_________________
Namo tassa bhagavato arahato samma sambuddhassa
anonymous ®
Стаж: 16 лет 2 мес.
Сообщений: 3102
Поблагодарили: 100049
0%
Azger писал(а):
Где это написано?
Цитата:
uTP, the micro transport protocol. This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it. In addition, we use information from this transport, if active, to control the transfer rate of TCP connections. This means uTorrent, when using uTP, should not kill your net connection - even if you do not set any rate limits.
Цитата:
uTP is an alternative communication method for BitTorrent traffic that allows the client to automatically regulate its bandwidth usage to avoid adversely impacting your internet connection. This will allow you or other users on the network to download their torrents but still allow others on the network to function with little difference. This does not require any additional setup.

uTP делает даже больше, чем то что ты написал про TCP - в нём меряется время отклика от пиров, с которыми происходит обмен данными. как только этот "пинг" начинает увеличиваться, ещё задолго до недополучения или потерь пакетов, уТоррент сбавляет скорость.

за счёт этого, пока канал свободен - он используется на полную. как только например другое приложение (броузер) начинает грузить канал - в уТорренте начинает возрастать время отклика, и он автоматически освобождает канал для броузера. как только пинг вернулся обратно (канал снова освободился) - уТоррент увеличивает загрузку канала.

при этом лишних перепосылок пакетов гораздо меньше, чем если бы это происходило на TCP-уровне
Kavasar
Релизер
Стаж: 16 лет 2 мес.
Сообщений: 776
Ratio: 47.75
Раздал: 14.42 TB
Поблагодарили: 22914
100%
Откуда: Необъятные просторы Земли
cod4.gif
Azger писал(а): link
Возможно провайдер резал udp...

Т.е., в моем случае получается, что "5" надо ставить в любой версии торрента???

_________________
Приобретение денег требует доблести; сохранение денег требует рассудительности; трата денег требует искусства. (Бертольд Авербах)
Зингельшухер
Покровитель талантов
Стаж: 16 лет 5 мес.
Сообщений: 27838
Ratio: 23.83
Раздал: 6.782 TB
Поблагодарили: 4165
100%
Откуда: фан-клуб Ведьмаси!
estonia.gif
alex14san писал(а):
больше подходит

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

_________________
мой принцип прост как 3.14159.... "Открыто говорить что думаю, и (если трезвый) думать что говорю." © Vladson
anonymous ®
Стаж: 16 лет 2 мес.
Сообщений: 3102
Поблагодарили: 100049
0%
ёёёdgjёёё писал(а):
Т.е., в моем случае получается, что "5" надо ставить в любой версии торрента???

или искать багу в железе, софте, провайдере, или кто ещё не справляется с UDP-трафиком
там на офф. форуме как-то попадался список несовместимого железа или нечто в таком духе...

Зингельшухер писал(а):
так что пока TCP и без вопросов...

ну речи о полном отключении TCP нигде и не идёт
Azger
Стаж: 15 лет 7 мес.
Сообщений: 301
Ratio: 6.868
Раздал: 4.387 TB
Поблагодарили: 648
93.75%
Откуда: Днепр
ukraine.gif
Зингельшухер писал(а): link
alex14san писал(а):
больше подходит

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


Ну почему же? Сейчас в utorrent-е имеется поддержка обоих протоколов. По этому особой разницы старые клиенты чувствовать не должны..

Alex14san
Теперь понятно, значит та статья которую я читал до этого, не во всем была верна...

_________________
Namo tassa bhagavato arahato samma sambuddhassa
Зингельшухер
Покровитель талантов
Стаж: 16 лет 5 мес.
Сообщений: 27838
Ratio: 23.83
Раздал: 6.782 TB
Поблагодарили: 4165
100%
Откуда: фан-клуб Ведьмаси!
estonia.gif
Просто опрос показался мне не более логичным чем "что лучше, вертолёт или унитаз"

_________________
мой принцип прост как 3.14159.... "Открыто говорить что думаю, и (если трезвый) думать что говорю." © Vladson
anonymous ®
Стаж: 16 лет 2 мес.
Сообщений: 3102
Поблагодарили: 100049
0%
Зингельшухер
смысл опроса - узнать мнение тех, кто уже успел uTP пощупать, стало ли лучше, или они были вынуждены его отключить, или какие ещё от этого впечатления. у мя в старых альфах 1.9 при скачивании с открытых трекеров если до этого входящий канал загружался где-то на 1/3, с uTP стал грузиться где-то на 2/3. а при скачивании с закрытых трекеров раньше канал загружался так, что броузер еле-еле ползал, а в 2.0 всё летает.
Показать сообщения:   
Начать новую тему   Ответить на тему    Торрент-трекер NNM-Club -> Информация и поддержка -> Техподдержка форум-трекера Часовой пояс: GMT + 3
Страницы:   1, 2, 3 ... 14, 15, 16  След.
Страница 1 из 16