Вычисление сетевого расстояния между двумя хостами

Question

Я хочу вычислить некоторые метрики относительно «расстояния» между двумя хостами в сетевом приложении.Я придумал следующее наивное решение, вдохновленное ping.

1. Отправкой пакетов UDP различного размера.
2. Ожидание ответа другого узла.
3. Подсчитать время между отправкой и получением.
4. Нормализовать эти данные и вычислить мои метрики по ним.

Я бы хотел избежать управления необработанными сокетами, но если это лучший вариантСкажите, пожалуйста.

Не могли бы вы порекомендовать другое решение?

РЕДАКТИРОВАТЬ:

Я думаю, что я не был ясен в этом.Я знаю, что такое TTL и traceroute, и это не то, что я ищу.

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

Answer 1

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

В общем, вы ищете какую-то функцию distance(A, B). В общем случае это будет зависеть от ширины полосы и задержки между A и B:

distance(A, B) = f(bandwidth(A, B), latency(A, B))

форма функции f () будет зависеть от цели, от приложения - что вам действительно нужно оптимизировать. Простейшим было бы использовать линейную функцию:

distance(A, B) = alpha * bandwidth + beta * latency

и снова, коэффициенты альфа и бета будут зависеть от того, что вы пытаетесь оптимизировать. Если вы измерили некоторую переменную, которая измеряет производительность вашей системы, вы можете выполнить статистический анализ (регрессию), чтобы найти оптимальные параметры:

performance(A, B) ~ alpha * bandwidth(A, B) + beta * latency(A, B)

Также будьте осторожны, когда говорите о метриках. Каждый показатель должен соответствовать следующему условию:

distance(A, B) + distance(B, C) >= distance(A, C)

Что не всегда верно в компьютерных сетях, поскольку это зависит от решения маршрутизатора.

Answer 2

Возникает вопрос: не можете ли вы изменить существующий протокол или быть более трудолюбивым и собрать RTT подробности из существующих сообщений запроса-ответа?

Если вы измените существующий протокол, скажем, добавивна отметке времени передачи вы можете выполнить дополнительную аналитику на стороне сервера.Вы могли бы по-прежнему выводить времена, если есть запрос-ответ от сервера к клиенту.

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

Answer 3

ИМХО, это сильно зависит от конкретных деталей вашего приложения.

• Некоторые приложения более чувствительны "задержка" , в то время как потеря некоторых пакетов принимается - как VOIP. Чем нужно измерить время ответа, игнорируя потерянные пакеты
• другим нужны быстрые репо, (поэтому «задержка» чувствительна) и потерянные пакеты должны быть переданы , но объем данных невелик - чем вам нужно измерять, как вы сделай это
  • в зависимости от того, как ретрансляция влияет на ваше приложение, вы должны либо рассчитать: среднее значение, дисперсия или другое - пусть это будет d
  • В зависимости от допустимости избыточности вы можете отправлять каждый пакет n раз, чтобы уменьшить повторную передачу. Затем сделайте функцию d = f (n) и сравните функции.
• некоторым приложениям требуется в основном скорость , тогда как задержка может быть очень большой (например, часы). Чем вас может заинтересовать создание статистики «скользящего окна» за данный период времени, чтобы узнать, сколько данных было передано за «последние t минут» и постоянно обновлять значение.

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

Answer 4

В сетях «расстояние» обычно измеряется в пересчете на хмель. Время не совсем точно отражает расстояние, поскольку оно подвержено кратковременной перегрузке и другим сетевым проблемам. Взгляните на traceroute, чтобы узнать, как измерить расстояние с точки зрения прыжков, отправляя пакеты с возрастающим TTL.

Изменить: Теперь, когда ваш вопрос имеет дополнительные детали - задержка и пропускная способность никогда не могут быть осмысленно объединены в общий показатель. Вы можете настроить вес в зависимости от того, что предпочитает ваше приложение (задержка по сравнению с пропускной способностью).

Мне кажется, что сглаженное RTT будет вам лучше служить. Что-то вроде того, что поддерживает TCP, долгое среднее RTT с коэффициентом сглаживания для учета аномалий. Нет хорошего способа сделать это, поэтому вы можете поискать «сглаживание RTT» и поэкспериментировать с некоторыми из них.

Answer 5

Я думаю, что вам нужно использовать поле времени жизни пакета :

Время жизни (TTL)

Восьмибитовое поле времени жизни помогает предотвратить сохранение дейтаграмм (например, по кругу) в Интернете.Это поле ограничивает время жизни дейтаграммы.Он указывается в секундах, но временные интервалы менее 1 секунды округляются до 1. В типичных на практике задержках это стало полем подсчета скачков.Каждый маршрутизатор, который пересекает дейтаграмма, уменьшает поле TTL на единицу.Когда поле TTL достигает нуля, пакет больше не пересылается коммутатором пакетов и отбрасывается.Как правило, сообщение ICMP (в частности, превышенное время) отправляется обратно отправителю, чтобы сообщить ему, что пакет был отброшен.Прием этих ICMP-сообщений лежит в основе работы traceroute.

В двух словах, вы можете отправлять последовательные IP-пакеты, уменьшая время жизни каждого отправляемого вами пакета.Как только вы перестанете получать ответ, вы примерно узнаете, сколько прыжков должно существовать между исходным и целевым хостами.

Если вы не хотите работать с сокетами самостоятельно, вы можете просто использовать команду ping , которая предоставляет опцию, которая позволяет вам указать значение времени жизни, которое будет использоваться дляпинг пакеты.