Допустим, вы отправляете эхо-запрос с устройства 1 на устройство 2. В результате вы получите значение RTT.
Теоретически (поскольку реально задействовано множество переменных) будет ли RTT таким же, если проверить связь с устройством 1 с устройства 2?
Когда все работает, как задумано, в задержке будет преобладать скорость света. Если две конечные точки расположены очень близко друг к другу (скажем, в одном здании), время обработки на любых маршрутизаторах и коммутаторах на пути может быть больше, чем задержка из-за скорости света.
Однако эти факторы будут одинаковыми до тех пор, пока пакеты в обоих направлениях идут по одному и тому же пути.
Когда существует более одного пути, пакеты могут принимать маршрутизаторы, а коммутаторы обычно используют многопутевый режим с равной стоимостью (ECMP), чтобы решить, в каком направлении отправлять каждый пакет. Обычно для выбора пути используется хеш выбранных полей заголовка. Используемые поля заголовка обычно представляют собой подмножество:
Первые пять из них будут одинаковыми независимо от того, с какого направления вы запускаете команду ping.
Метка потока может быть другой и может привести к тому, что пакеты будут идти по разным маршрутам. Однако это поле существует только в IPv6, и не все маршрутизаторы будут учитывать его при выборе пути.
ICMP не имеет номеров портов, поэтому эти поля не будут учитываться. Маршрутизатор может использовать вместо этого поле ID, однако маловероятно, что такой особый случай будет реализован только для пакетов эхо-запроса / ответа ICMP.
Таким образом, в целом маловероятно, что пакеты будут идти по разным маршрутам.
Еще одна более вероятная причина видеть разное время приема-передачи в двух направлениях - это время обработки на самих двух конечных точках. Получение эхо-запроса и ответ эхо-ответом выполняется ядром в каждой известной мне ОС и, следовательно, происходит очень быстро. Но сама команда ping работает в пользовательском режиме и будет иметь большую задержку, если она выполняется на загруженном компьютере. Если две машины загружены неравномерно, вы можете ожидать, что команда ping на занятой машине по этой причине увидит немного большее время приема-передачи.
Да, даже если каждое направление использует совершенно другой путь, устройства L3 (маршрутизаторы) не принимают во внимание, является ли пакет эхо-запросом ICMP, а не эхо-ответом ICMP, и они не принимают во внимание, является ли пакет TCP SYN или TCP SYN-ACK.
В целях иллюстрации, давайте представим, что для перехода от A к B пакет должен пройти 5 переходов, и это займет 12 мс, затем для того, чтобы пакет перешел от B к A, он должен пройти через 12 переходов, в общей сложности 22 мс. . RTT, измеренный в этом сценарии, независимо от того, с какой стороны вы решите начать измерение, будет 34 мс (12 мс + 22 мс).
Да, с любой значительной точностью RTT всегда будет одинаковым. Пройденное расстояние является доминирующим фактором задержки, и оно всегда должно быть одинаковым. Крайне необычно видеть какие-либо крайние случаи, когда пройденное расстояние не будет одинаковым, но заметным исключением может быть изменение в балансировке нагрузки. Некоторые маршрутизаторы могут использовать расширенную функцию, чтобы решить, по какому маршруту направить ваш трафик, и это может измениться между двумя вашими измерениями. Если использовалась адаптивная балансировка нагрузки на основе агента, вы могли выбрать другой маршрут в зависимости от того, сколько трафика использовало различные доступные пути на вашем маршруте. Обычно это небольшие различия, но при заторах или в разное время дня они могут стать значительными.