Время отклика и расстояние: есть ли между ними связь?::Журнал СА 7-8.2018
www.samag.ru
Журнал «БИТ. Бизнес&Информационные технологии»      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы
1001 и 1 книга  
12.02.2021г.
Просмотров: 410
Комментарии: 0
Коротко о корпусе. Как выбрать системный блок под конкретные задачи

 Читать далее...

11.02.2021г.
Просмотров: 258
Комментарии: 0
Василий Севостьянов: «Как безболезненно перейти с одного продукта на другой»

 Читать далее...

20.12.2019г.
Просмотров: 7155
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 8199
Комментарии: 2
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 9393
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Время отклика и расстояние: есть ли между ними связь?

Архив номеров / 2018 / Выпуск №7-8 (188-189) / Время отклика и расстояние: есть ли между ними связь?

Рубрика: Администрирование /  Сети

Александр Зырянов АЛЕКСАНДР ЗЫРЯНОВ, сетевой инженер, CDNvideo, резидент ИТ-кластера фонда «Сколково»

Время отклика и расстояние:
есть ли между ними связь?

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

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

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

Ping – чрезвычайно полезная диагностическая утилита, но, к сожалению, она часто используется хакерами для обнаружения доступных для атаки узлов. По этой причине во многих сетях осуществляется блокировка внешней ping, что препятствует выполнению точных измерений. По нашим наблюдениям, даже для ping на основе ICMP, который блокируется меньше всего, примерно 10-15% префиксов не содержат ни одного отвечающего на ping IP-адреса. Для таких префиксов необходимо выполнить оценку времени отклика иным образом, и одним из возможных способов проведения такой оценки является использование геолокации.

Оценка времени отклика с помощью геолокации

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

Для определения географических координат мы можем использовать геобазы различных поставщиков. Точность определения положения зависит от страны, в которой расположен клиент, и поставщика геобазы. Обычно точность находится в районе 70-90%, однако одновременное использование геобаз различных поставщиков позволяет дополнительно повысить ее, что делает данный метод пригодным для применения.

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

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

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

Проверка допустимости применения

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

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

Рисунок 1. Теоретическое распределение количества префиксов в зависимости от отношения расстояния и реального времени отклика (идеальный – синяя линия – и учитывающий погрешности варианты – красная линия)

Рисунок 1. Теоретическое распределение количества префиксов в зависимости от отношения расстояния и реального времени отклика (идеальный – синяя линия – и учитывающий погрешности варианты – красная линия)

А что же на практике? На практике картина совершенно другая.

Так, в одном из дата-центров Москвы время отклика до префиксов из Украины существенно лучше, чем в другом дата-центре, также расположенном в Москве. При этом в обоих случаях расчетное время отклика до префиксов из Турции сильно отличается от наблюдаемого в реальности. Префиксы из России оказываются практически равномерно распределены по всему диапазону значений (за исключением ожидаемого пика в районе нуля). При этом ближе всего к теоретическому распределению оказываются США и Канада, расположенные на другой стороне земного шара (см. рис. 2 и 3).

Рисунок 2. График распределения в одном из дата-центров Москвы

Рисунок 2. График распределения в одном из дата-центров Москвы

Рисунок 3. График распределения в другом дата-центре Москвы

Рисунок 3. График распределения в другом дата-центре Москвы

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

Рисунок 4. График распределения в Израиле

Рисунок 4. График распределения в Израиле

Впрочем, и внутри России нередка ситуация, когда связь между двумя провайдерами одного города осуществляется через Москву. Это можно наблюдать, к примеру, на графике Перми, где виден существенный сдвиг российских префиксов в левую (более отдаленную от теоретической) часть графика (см. рис. 5).

Рисунок 5. График распределения в Перми

Рисунок 5. График распределения в Перми

В Европе и США различия между расчетным и реальным временем отклика менее выражены, однако в наибольшей степени они проявляются как раз для местного трафика и трафика близкорасположенных стран – картина оказывается похожей на то, что мы видели на серверах в Москве для трафика из России (см. рис. 6-8).

Рисунок 6. График распределения в Амстердаме, Голландия

Рисунок 6. График распределения в Амстердаме, Голландия

Рисунок 7. График распределения в Лос-Анджелесе, США

Рисунок 7. График распределения в Лос-Анджелесе, США

Рисунок 8. График распределения в Нью-Йорке, США

Рисунок 8. График распределения в Нью-Йорке, США

В других странах и городах России наблюдается аналогичная картина.

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


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru