чому mtr набагато швидше, ніж traceroute?

На mtrсторінках man на ньому написано:

mtr поєднує функціональність програм traceroute та ping в єдиному інструменті діагностики мережі

Я mtrбагато використовую , і вважаю, що це набагато швидше, ніж traceroute. Інстинктивно, mtrдає мені відповідь з нетерпінням, tracerouteперераховуючи кожну ip адресу кожні секунди. На власному комп’ютері я використав time mtr www.google.comі time traceroute www.google.com, результат - 21,9s VS 6.1s.

Питання - чому? Оскільки mtr = ping + tracerouteце не означає, що це повільніше або принаймні те саме, що traceroute.

Хтось може дати мені розумну та детальну відповідь?

Паралелізм є головною причиною коливання швидкості цих інструментів. Ще одним фактором, що сприяє, є те, як довго вони чекають відповіді, перш ніж скачеться, що стрибок не відповідає. Якщо виконується зворотний DNS, вам доведеться чекати і цього. Проста команда traceroute стає набагато швидшою, якщо вимкнути зворотний DNS.

Ще одна важлива відмінність, яку я не бачив згаданої, - це те, як два інструменти надають результат. Traceroute виробляє вихід у порядку зверху вниз. Mtr надає вихід по-іншому, де mtr може повертатися назад і оновлювати вихід у попередніх рядках.

Це означає, що mtr може відображати вихід, як тільки він буде доступний, оскільки якщо пізніші відповіді призводять до того, що вихід не буде точним, mtr може повернутися назад і оновити його. Оскільки traceroute не може повернутися та оновити вихід, він повинен почекати, поки він остаточно не вирішить, що він відображатиме.

Наприклад, якщо перехідний номер 2 не відповідає (що є симптомом, який я бачив у кількох провайдерах), traceroute відобразить перехідний номер 1, а потім зачекає деякий час, перш ніж він відобразить перехідний номер 2 і 3. Навіть незважаючи на те, що відповідь з перехідного номера 3 прийшов, він не відображається, тому що traceroute все ще чекає відповіді від перехідного номера 2. Mtr не має цього обмеження і може відображати відповідь з перехідного номера 3 і все ще повертатися назад, щоб відобразити відповідь з перехідного номера 2, якщо воно надходить пізніше.

Занадто великий паралелізм може призвести до неточності результатів. У деяких сценаріях є обмеження щодо кількості пакетів, на які можна отримати відповіді. Надсилання більшої кількості пакетів у цих випадках не прискорить процес, однак це призведе до втрати більше пакетів, оскільки ви отримаєте однакову кількість відповідей із надсиланням більшої кількості пакетів.

Одним із прикладів цього є те, коли скачок на маршруті не відповідає на запити ARP. Зазвичай перший пакет викликає запит ARP, і якщо більше пакетів надійде до того часу, коли запит ARP вичерпається, буде завантажений лише останній з цих пакетів і отримає відповідь.

Ще одна відмінність полягає в тому, скільки хмелів без відповідей буде показано, перш ніж інструмент перестане показувати більше хмелю. Я бачив, що команда traceroute триває протягом стількох переходів, скільки вимагається (за замовчуванням 30), тоді як команда mtr припиняється, як тільки пройшло п'ять переходів, без відповідей.

Команда traceroute надсилає 3 зонди на хоп, якщо ви обмежите його на 1 зонд, -q 1то результати стануть порівнянними

time mtr -r -c 1 google.com
.
.
.
real    0m2.640s
user    0m0.003s
sys     0m0.018s


time traceroute6 -q 1 google.com
.
.
.
real    0m0.445s
user    0m0.006s
sys     0m0.007s

Я б очікував, що основні відмінності між порівняльними тестами пов'язані з часом запиту DNS та різницею шляху. Ви зауважите, що мій traceroute швидше, ніж mtr, але це не завжди так.

Я гадаю, що це походить від того, як здійснюється трасування маршруту. tracerouteнадсилає щонайменше 3 пакети за кожен перехід у маршруті до пункту призначення послідовно.

mtr спочатку виявляйте стрибки в маршруті, а потім надсилайте пакет паралельно кожному вузлу.

Мені також здається, що існує різниця в тому, як mtrобробляється стрибок, не реагуючи на ping / зонди; то він ігнорує швидше, ніж tracerouteякий, здається, постійно надсилає свої 3 пакети, навіть якщо перші спроби не змогли отримати відповідь.

Основна причина - спосіб проходження трасування. Він надсилає пакет UDP (або ICMP на windows) з TTL одного на перший хост, і коли він отримує відповідь на час очікування (або він проходить внутрішній тайм-аут), то генерує наступний пакет для наступного хоста з TTL з двох тощо (додавання по одному в TTL для кожного хоста). Таким чином, загальний час traceroute включає надсилання та отримання пакетів для кожного хоста послідовно.

mtr, після визначення шляху, який проходять пакети, паралельно надсилає всі пакети ICMP ECHO.