CDN — оптимизация загрузки контента на вашем сайте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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