Как география влияет на задержку в сети?

У меня есть возможность разместить нашу базу данных / веб-сервер в управляемой хостинговой компании на Восточном побережье (США) или на Западном побережье (США). Наша компания базируется за пределами Нью-Йорка, и оба хостинг-провайдера предоставляют нашей коробке выделенную линию T1.

Какой удар по производительности (при условии, что все остальные факторы равны) я бы взял с точки зрения задержки в сети, если бы выбрал один на западном побережье, а не на восточном? Я не слишком уверен, как география влияет на скорость интернета, когда цифры и расстояния становятся действительно большими (T1 и выше, и тысячи миль).

Благодарность!

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

При прочих равных у вас будет дополнительная задержка в 44 миллисекунды только из-за скорости света. Дайте или возьмите 1/20 секунды для каждого пакета туда и обратно. Не очень для типичного использования в Интернете. Сносно для SSH сессий. Существенно, если вы обращаетесь к своей БД напрямую с помощью множества небольших последовательных транзакций.

Я проигнорировал дополнительную задержку, вызванную дополнительными маршрутизаторами / повторителями, которые могли быть намного, намного выше. Я предположил, что расстояние 4400 км и скорость света в волокне 200000 км / с.

У нас был клиент, с которым мы потратили немало времени, связавшись с этим. Первоначально они были размещены в Нью-Йорке, и их сотрудники в основном расположены в районе Бостона. Они перемещали свои серверы на наш объект, расположенный в Денвере, примерно в двух третях пути по всей стране.

Переехав, они начали поднимать проблемы с производительностью из своих ссылок Comcast в домашних офисах. Раньше они имели задержку <10 мс, и она достигала 80 мсек. Они заметили снижение производительности на своих сайтах, но сказали: «Может быть, нам просто придется смириться с переходом от невероятно быстрой к простой смертной скорости». Казалось, они понимают, что существуют ограничения из-за географии, и что их пользователи на западном побережье будут потенциально получать более высокую производительность.

Мы ходили туда-сюда несколько раз. Примерно через 6 месяцев мы переключились на другого основного провайдера восходящего трафика по причинам, не связанным с этим клиентом (лучшая цена, большая пропускная способность, недовольная количеством окон обслуживания у другого провайдера), а с новым провайдером мы получили около 45 мс. средняя задержка для этого клиента. На данный момент их проблемы производительности, кажется, исчезли.

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

Попробуйте использовать «mtr», чтобы показать информацию о задержке и потере пакетов на разных удаленных концах. Если вы не полностью понимаете маршрутизацию по «медленному пути», игнорируйте все, кроме последнего перехода, указанного в этом выводе. Ван Якобсон говорит, что люди замечают задержку, начинающуюся с 400 мс, но понимают, что многие соединения требуют многократных обменов назад и вперед, поэтому задержка в 100 мс может быстро добавить в секунду ...

По моему опыту, задержка 250 мс начинает ощущаться как заметно медленная связь. 10 мс или лучше ощущается как сверкающее соединение. Это действительно зависит от того, что вы делаете.

Шон

Что ж, пакеты перемещаются по проводам на скорости, достаточно близкой к скорости света, поэтому необработанное время передачи незначительно по сравнению с другими факторами. Важна эффективность маршрутизации и то, насколько быстро устройства маршрутизации могут выполнять маршрутизацию. К сожалению, это не может быть определено исключительно на основе географического расстояния. Между расстоянием и задержкой существует сильная корреляция, но нет строгого правила, о котором я знаю.

Количество прыжков между точкой A и точкой B приведет к задержке. Подсчитайте количество прыжков, так как это ваш лучший показатель.

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

Для traceroute, попробуйте использовать -I, -Uили -Tпосмотреть, как меняется путь. Также посмотрите на -t 16или -t 8. трассировка

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

Я думаю, что география будет во многом зависеть от времени передачи пакетов, поскольку чем дальше, тем больше переходов вы, скорее всего, добавите, влияя на общую задержку. Если ваши клиенты будут базироваться в основном на западном побережье, то я бы пошел на хостинг на западном побережье ... То же самое на восточном побережье. Если ваши клиенты будут приезжать со всего США или со всего мира ... тогда вам просто придется принять сложное решение относительно того, какая сторона получает меньше задержек.

В нашем случае мы находимся в нашей собственной Сети (одна большая интрасеть) и можем позволить нашим маршрутизаторам принимать решения на основе OSPF по всему штату :) К сожалению, все, что находится за пределами нашей сети, зависит главным образом от нашего макета ISP.