Назад | Перейти на главную страницу

Задержка в сети и скорость света

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

Сценарий следующий; у нас есть два противоположных сайта: один на западном побережье США, а другой в Ирландии. Заказчик находится в Центральной Европе и запросил тест задержки. Ирландия дает ответы ~ 65-70 мс. Однако парни с западного побережья утверждают, что они быстрее с ответом 60 мс.

Теперь быстрая проверка показывает, что свету в оптоволокне потребуется около 42 мс, чтобы добраться до Штатов, и 8,5 мс до Ирландии. Таким образом, очевидно, что это одиночный переход и не включает маршрутизаторы, коммутаторы, межсетевые экраны, служебные данные протокола и т. Д.

Правильно ли я назову чушь по их цифрам?

В заключение я протестировал пинг на IP-адрес Google, который предположительно находился на западном побережье, с сайта, который проходил такое же расстояние, и был удивлен, получив время отклика в 20 мс. Предлагаем пакеты ICMP, которые путешествуют вдвое быстрее света.

Итак, А) чего мне не хватает? Б) Правильно ли я подозреваю махинации?

ОБНОВИТЬ: Ребята, спасибо за вашу помощь, и я читал различные предыдущие вопросы по этому поводу. Около 5 лет у меня была проблема, когда переход из Великобритании в Ирландию увеличивал задержку на 10 мс независимо от того, что мы делали. В конце концов я переместил серверы; Так что представьте мое удивление, когда у меня есть парни, которые утверждают, что они на 5 мс быстрее в трансатлантическом путешествии.

Так я должен снова позвонить в BS? Да, и предположим, что оба сайта - нормальные смертные, у которых нет доступа к волшебной маршрутизации Google, погружениям варпа или конденсаторам потока. :)

ОБНОВЛЕНИЕ 2: Последнее обновление, услышав приведенные ниже аргументы и прочитав различные другие статьи, вы бы назвали BS о его временах?

В последних моделях коммутаторов и / или маршрутизаторов часто используется только однозначное число. микросекунды задержки, поэтому количество переходов не так важно для этого теста ping.

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

Еще одна вещь, на которую следует обратить внимание: когда кто-то говорит о «задержке связи», они вполне могут иметь в виду время, в течение которого пакет должен перейти на другую сторону. ping сообщает о задержке приема-передачи, поэтому вполне вероятно, что число будет удвоено.

Что касается Google, я бы не знал, где он на самом деле находится. Ты конечно сервер находится на западном побережье?

А вот реальный пример того, как я (мой дом в Токио) проверяю связь с зеркалом ядра в США (это немного меньше 9000 км по прямой) и получаю приличное время отклика 110 мс туда и обратно, что составляет 55 мс в одну сторону. задержка связи.

> ping  -i0.2 -c5 mirrors.us.kernel.org
PING mirrors.us.kernel.org (149.20.4.71) 56(84) bytes of data.
64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=1 ttl=52 time=109 ms
64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=2 ttl=52 time=115 ms
64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=3 ttl=52 time=109 ms
64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=4 ttl=52 time=110 ms
64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=5 ttl=52 time=117 ms

--- mirrors.us.kernel.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 839ms
rtt min/avg/max/mdev = 109.654/112.563/117.892/3.350 ms

Эмпирическое правило гласит, что скорость света в SMF составляет ~ .6c (в том же районе, что и описание Криса С.). Межпортовая задержка, вносимая маршрутизаторами и коммутаторами, будет усредняться в диапазоне малых двузначных цифр, как только будут добавлены какие-либо виды буферизации или необычные функции. Существует также номинальная задержка сериализации, которая возникает каждый раз, когда пакет отображается на сам носитель. Это значение уменьшается в зависимости от пропускной способности канала, поэтому будут ощутимые различия, скажем, между каналом OC3 и OC768. Это также обычно занимает микросекунды.

Я обычно использую эмпирическое правило: около 0,25 мс на 100 км фактического соединения (одностороннее) с минимальным использованием оборудования (например, оборудования DWDM). Эта оценка очень хорошо пригодилась при строительстве частных сетей метро и даже нескольких выделенных магистралей на большие расстояния. Тем не менее, взаимосвязь между этим числом и реальностью в условиях облака MPLS оператора связи, общедоступного Интернета и т. Д. В значительной степени является несостоятельной. Я бы предложил что-то подобное для установления минимальной практической задержки.

Тем не менее ...

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

Во-вторых, на самом деле процесс отправки IP-трафика через одну или несколько точек обмена не может, а может и не быть, действительно в пути. Экономика как построения каналов, так и мест передачи оператора связи в большей степени влияет на практическую разработку, чем на абсолютную минимизацию задержки.

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

Попробуйте использовать IP-адрес, например 4.2.2.4 (это для Sun Microsystems), который определенно находится в США. Вы не можете получить подсказку, просто выполнив PING. Возможно, на некоторых сайтах ICMP-пакеты имеют форму, хотя пинг Google звучит странно, потому что он меньше, чем ожидалось, не больше!