Как интерпретировать этот трассировщик?

Question

У меня есть результат traceroute, который выглядит следующим образом:

HOST: local                       Loss%   Snt  Last   Avg  Best  Wrst StDev
  1.|-- 10.0.1.1                  0.0%    10    1.2  10.2   1.1  32.1  10.9
  2.|-- 111.111.11.21             0.0%    10    3.4  47.6   2.6 331.0 102.6
  3.|-- bt-128-389.bta.net.cn     0.0%    10    4.5  11.9   4.5  25.9   7.4
  4.|-- 124.65.28.229             0.0%    10    7.7  12.1   4.1  35.8   9.5
  5.|-- 152.75.194.93             0.0%    10   11.0  17.3   6.2  35.7  10.3
  6.|-- 219.111.6.110             0.0%    10   44.4  46.8  39.4  55.8   5.1
  7.|-- 119.138.23.25             0.0%    10   56.4  68.2  51.1 110.3  19.5
  8.|-- 212.111.96.222            0.0%    10   54.0  65.8  54.0  88.6  13.2
  9.|-- 189.158.97.242            0.0%    10   61.3  71.2  51.5  98.4  18.1
 10.|-- 231.158.40.102           10.0%    10   54.4  67.4  47.0  93.8  16.8
 11.|-- 118.188.104.14            0.0%    10   54.0  66.7  45.6 103.6  19.7
 12.|-- 116.151.36.153            0.0%    10   61.4  68.9  50.2 103.9  15.9
 13.|-- ???                      100.0    10    0.0   0.0   0.0   0.0   0.0
 14.|-- 57.30.49.32              10.0%    10   54.5  68.9  46.2 102.1  20.1

Я не понимаю

1. почему среднее время соединения ниже в прыжке 3-5, чем 2? (так как прыжок 3-5 еще дальше, почему он быстрее подключается к ним, чем прыжок 2?)
2. На этапе 13, если этот переход отбрасывает все пакеты, то как я в итоге подключился к переходу 14? (Означает ли это, что переход 13 не отвечает на ICMP, но все еще пересылает пакеты на переход 14?)

Answer 1

Для начала вам необходимо понять, как работает tracert.

tracert отправляет отдельные пакеты в пункт назначения с увеличивающимся временем жизни. каждый маршрутизатор уменьшает TTL, и когда он достигает 0, маршрутизатор обычно отправляет сообщение ICMP TTL Exceeded обратно на хост. таким образом, чтобы проверить первый переход, TTL равен 1 (который маршрутизатор уменьшает и немедленно отправляет обратно превышенный TTL), второй переход использует 2 и так далее.

таким образом, для перехода 13 устройство настроено не отправлять сообщения с превышением TTL. tracert просто ждет, пока истечет время ожидания, увеличивает TTL и пытается выполнить следующий переход.

Что касается вашей временной дисперсии, обратите внимание, что среднее значение высоко, потому что "худшее" было колоссальным 331 мс, а ваше "лучшее" составляет всего 2,6, а стандартное отклонение огромно, что указывает на то, что ваше "среднее" основано на цифрах, которые различаются широко (например, 2,6 и 331). Я бы сказал, что у второго прыжка просто плохая половина секунды.