Где поместить свой сервер, чтобы обеспечить максимальную скорость? Насколько это важно?

Где поместить свой сервер, чтобы обеспечить максимальную скорость? Помимо времени, необходимого серверам для ответа на запросы, требуется время просто для доставки пакета из пункта А в пункт Б.

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

По мере роста сетевых задержек могут происходить странные вещи: «толстые» сайты могут стать более быстрыми (особенно если они полностью обслуживаются из CDN), а «тонкие» сайты, использующие API-интерфейсы, могут стать более медленными. Для пользователя настольного ПК/ноутбука типичная задержка достигает 200 мс, а для мобильного пользователя 4G составляет 300–400 мс. В этой статье предполагается, что пропускная способность равна 40 Мбит/с, поддерживается TLS, задержка CDN равна 40 мс и нет существующих соединений. «Исходная точка» здесь означает основной веб-сервер (в отличие от «пограничных» кэшей CDN).

Почему местоположение имеет значение

Время пересечения Интернета добавляется ко времени, затраченному на ответ на запрос. Даже если ваш API-интерфейс способен ответить на запрос за 1 мс, когда пользователь находится в Лондоне, а API-сервер — в Калифорнии, пользователю всё равно придется ждать ответа около 130 мс.

Весь процесс занимает немного больше 130 мс. В зависимости от того, что делают пользователи, в конечном счёте они могут совершить несколько таких операций передачи и подтверждения. Для загрузки веб-страницы обычно требуется пять полных операций передачи и подтверждения: одна  — для разрешения доменного имени с помощью DNS, одна — для установления TCP-соединения, ещё две — для настройки зашифрованного сеанса с TLS, и, наконец, одна — для страницы, которую вы хотели получить в первую очередь.

В последующих запросах можно (но не всегда) повторно использовать настройки DNS, TCP и TLS, но при каждом обращении к серверу, например при вызове API-интерфейса или при создании новой страницы, по-прежнему требуется новая операция передачи и подтверждения.

Сначала кажется, что 130 мс — это быстро, но вся эта долгая и муторная процедура с простым получением страницы и последующим выполнением пары API-вызовов может легко занять большую часть секунды только с точки зрения времени ожидания сетевого сигнала. Всё остальное необходимое время — время выбора сервером ответа на запрос, время загрузки нужных данных, а затем время визуализации содержимого в браузере — всё это дополнительное время.

Два вида понятия «быстрый» для сетей

При обсуждении сетей сбивает с толку то, что люди говорят о получении «более быстрых» сетей: «более быстрая» домашняя широкополосная связь, например, или «быстрый ethernet» (скорость «100 мегабит в секунду» уже не впечатляет).

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

API-интерфейсы, или сети CDN

Существует сеть, в которой операции выполняются быстрее, — это сеть дистрибуции содержимого (Content Distribution Network, CDN). Вместо того чтобы пройти весь путь до Калифорнии, возможно, вы сможете получить часть веб-страницы из кэша в Центральном Лондоне. Такой подход экономит время. Операция может занять всего 50 мс. Экономия достигает 60 %. Кэш отлично работает для CSS-файлов, изображений и JavaScript, т. е. для ресурсов, которые не меняются для всех пользователей. Он не так хорошо работает для ответов на API-вызовы, так как ответы различны для каждого пользователя, а порой и всегда.

Количественный подход

Немногие счастливчики все запросы могут обрабатывать с помощью CDN. Новостные сайты, например, показывают всем одно и то же. Другие менее удачливы и могут применять кэширование лишь в ограниченном объёме или вообще не использовать его. Эти несчастные люди должны выбрать такое место для своего основного сервера, чтобы максимально быстро доставлять свои данные пользователям, которые в них нуждаются. Если этот выбор направлен лишь на уменьшение задержки, какое место они должны выбрать?

Вот что я сделал:

1.   Я взял собственные журналы доступа за две недели в сентябре сразу после того, как опубликовал что-то новое. За этот период я получил около миллиона запросов от 143 тыс. уникальных IP-адресов. Я исключил очевидных роботов (на которые пришлись около 10 % запросов).

2.   Я использовал базу данных GeoIP компании Maxmind для привязки каждого IP-адреса в этих журналах доступа к соответствующим географическим координатам.

3.   Затем я использовал опубликованные на сайте WonderNetwork данные о задержках в интернет-соединениях между примерно 240 городами мира.

4.   Я сопоставил (полуавтоматически, что было довольно мучительно) названия этих городов с идентификаторами Geonames, что позволило получить координаты городов.

5.   Затем я загрузили всё вышеперечисленное в базу данных Postgres с установленным расширением PostGIS для выполнения географических запросов.

6.   Я запросил оценку длительности (в процентах) выполнения запросов в ситуациях, когда мой сервер находился бы в каждом из 200 городов.

Результаты

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

●     среднее («P50»);

●     для трёх четвертей запросов («P75»);

● для 99 % запросов («P99»).

Все числа выражены в миллисекундах.

Вы также можете загрузить все результаты как csv-файл, если так проще.

Результат: восточное побережье Северной Америки — хорошо, прямо в Атлантике — лучше

Все лучшие места находятся в Северной Америке. Это, вероятно, не стало полным сюрпризом, учитывая, что это довольно плотный кластер носителей английского языка, от которого не так далеко (с точки зрения задержки), в Великобритании/Ирландской Республике, находится другой кластер. Кроме того, в Европе много тех, для кого английский — второй язык. Лучше всего находиться прямо в Атлантике: в штатах Нью-Джерси и Нью-Йорк есть много отличных мест для P99, и показатели в верхней части, между P50 и P99, варьируются не слишком сильно.

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

В настоящее время мой сервер находится в Хельсинки. Это был самый дешёвый вариант, что необычно для Финляндии. За этот сервер я плачу около трёх фунтов в месяц, всего лишь. Если бы я переместил его куда-нибудь в Нью-Джерси и потратил больше денег, в целом пользователи определённо сэкономили бы время: половина операций передачи и подтверждения была бы завершена за 75, а не за 105 мс, что позволило бы сэкономить 30 %. За несколько операций передачи и подтверждения время, вероятно, увеличилось бы примерно на шестую долю секунды по сравнению со средним показателем загрузки первой страницы, что не так уж плохо. Если вы не можете сказать, что этот веб-сайт очень обременителен для веб-браузеров с точки зрения визуализации, сокращение времени ожидания в сети сделает его значительно быстрее.

Поскольку на этом сайте ничего не генерируется динамически, в действительности мне лучше всего использовать CDN. Это действительно сэкономило бы много времени для всех: обслуживание из CDN почти в два раза лучше (~40 мс) установки сервера в самом быстром месте (71 мс).

Как это может меняться со временем

Задержки не фиксированы, и со временем они могут уменьшиться. Здесь предлагается таблиц задержек операций передачи и подтверждения при передаче данных из Лондона в другие города мира с населением более 5 млн. человек. Значения сравниваются с теоретической максимальной скоростью — скоростью света:

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

Как видно из таблицы, задержка в Нью-Йорке находится в пределах коэффициента 2 от значения для скорости света, но маршруты в другие места, такие как Дакка и Сеул, намного медленнее: они в 4 раза превышают значения для скорости света. Вероятно, маршрут между Лондоном и Нью-Йорком так хорошо оптимизирован по вполне понятным причинам. Я сомневаюсь, что то, что между этими городами в основном лежит океан, представляет большую проблему, так как подводные кабели можно прокладывать напрямую. Добираться до Сеула или Дакки придётся более окольным путём.

Вероятно, следует упомянуть, что новые протоколы обещают уменьшить количество операций передачи и подтверждения. Версия TLS 1.3 позволяет создать зашифрованный сеанс с одной операцией передачи и подтверждения, а HTTP3 может объединить операции передачи и подтверждения протоколов HTTP и TLS. Это означает, что теперь нужны лишь три такие операции: одна — для DNS, одна-единственная операция передачи и подтверждения — для соединения и зашифрованного сеанса, и, наконец, третья — для темы запроса.

Некоторые люди ложно надеются, что новые протоколы, такие как HTTP3, устранят необходимость в объединении (bundling) JavaScript/CSS. Это основано на недоразумении: в то время как HTTP/3 удаляет некоторые исходные операции передачи и подтверждения, эта версия не удаляет последующие операции передачи и подтверждения для дополнительных данных JavaScript или CSS. Так что объединение, к сожалению, никуда не делось.

Слабые стороны данных

Хотя, как мне кажется, это и интересное упражнение — и, надеюсь, показательное, — я должен честно признать, что качество используемых мной данных целиком относится к категории «от среднего до низкого».

Во-первых, база данных GeoIP неоднозначно показывает местоположение IP-адресов. Заявленная (т. е., вероятно, оптимистичная) точность колеблется до 1000 км в некоторых случаях, хотя для моего набора данных утверждается, что средняя точность составляет 132 км со стандартным отклонением 276 км. Это не так уж точно, но я думаю, всё ещё полезно.

Мой источник данных о задержке, WonderNetwork, действительно сообщает данные о задержке на момент их получения (30 ноября 2020 года) в отличие от долгосрочных данных. Иногда в определённых местах Интернет «барахлит».

У WonderNetwork много станций, но их охват не идеален. На Западе всё отлично — в Великобритании представлены даже второстепенные города (вроде Ковентри). Их охват во всём мире по-прежнему хорош, но более неоднозначен. У них не так много мест в Африке или Южной Америке, а некоторые задержки в Юго-Восточной Азии кажутся странными: задержка между Гонконгом и Шэньчжэнем составляет 140 мс, тогда как эти города находятся всего в 50 км друг от друга. Этот фактор замедления более чем в тысячу раз превышает значение для скорости света. Для других городов континентального Китая проверка связи также показывает плохие результаты (что странно), хотя и не в таком масштабе. Может быть, эти коммунисты проверяют каждый ICMP-пакет вручную?

Другая проблема с данными о задержке заключается в отсутствии истинных координат центров обработки данных, в которых находятся серверы. Мне пришлось самому геокодировать данные с помощью некоторых сценариев и большого количества ручного ввода данных в Excel (я опубликовал эту таблицу Excel в github, чтобы никому не пришлось делать эту работу заново). Я очень старательно проверял данные, но ошибки всё ещё могут быть.

Однако, по моему мнению, самая большая слабость заключается в том, что все начинают отсчёт прямо от центра своего ближайшего города. На практике это не так и добавляемое из-за этого смещение может варьироваться. Здесь, в Великобритании, домашний доступ к Интернету — это сложный процесс, основанный на отправке высокочастотных сигналов по медным телефонным линиям. Моя собственная задержка для других хостов в Лондоне достигает 9 мс, что плохо для такого короткого расстояния, но всё ещё на 31 мс лучше среднего значения. Многие маршрутизаторы потребительского уровня не очень хороши и добавляют значительную задержку. Печально известная проблема излишней сетевой буферизации — ещё один распространённый источник задержки. Особенно это влияет на процессы, для хорошей работы которых требуется последовательный уровень задержки. В качестве примера можно привести видеоконференц-связь и многопользовательские компьютерные игры. Использование сети мобильных телефонов тоже не помогает. Сети 4G в хороших условиях добавляют около 100 мс задержки, но, конечно, всё гораздо хуже, когда уровень сигнала низок и есть много ретрансляций на уровне канала.

Я пытался предположить глобальную среднюю задержку на километр (около 0,03 мс), чтобы компенсировать расстояние до ближайшего города, но обнаружил, что это просто добавило кучу шума к моим результатам, так как для многих IP-адресов в моём наборе данных окольный путь был нереалистичным: ближайший город, который я им приписал, совсем не так близок.

Универсальность

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

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

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

Бесплатные операции передачи и подтверждения

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

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

Операции передачи и подтверждения легко добавить случайно. Особенно удивительным источником операций передачи и подтверждения служат предварительные запросы общего доступа к ресурсам независимо от источника (CORS). По соображениям безопасности, связанным с предотвращением атак на основе межсайтового скриптинга, браузеры должны «проверять» определённые HTTP-запросы, созданные кодом JavaScript. Для этого на тот же URL-адрес предварительно отправляется запрос с помощью специальной команды OPTIONS. На основе полученного ответа принимается решение о допустимости исходного запроса. Правила, определяющие точный момент отправки предварительных запросов, сложны, но в сети появляется удивительное количество запросов: в частности, включая POST-запросы JSON к поддоменам (например, к поддомену api.foo.com от домена foo.com) и сторонние веб-шрифты. В предварительных проверках на основе CORS-запросов используется другой набор заголовков кэширования по сравнению с остальным HTTP-кэшированием, которые редко задаются правильно и в любом случае применимы только к последующим запросам.

В наши дни многие сайты написаны как «одностраничные приложения», где вы загружаете некоторый статический пакет JavaScript (надеюсь, из CDN), а затем создаёте (надеюсь, небольшое) количество API-запросов внутри своего браузера, чтобы решить, что показывать на странице. Есть надежда, что этот процесс станет быстрее после первого запроса, так как не придётся перерисовывать весь экран, когда пользователь попросит загрузить вторую страницу. Как правило, это не помогает, потому что одна HTML-страница обычно заменяется несколькими последовательными API-вызовами. Пара последовательных API-вызовов к исходному серверу почти всегда обрабатывается медленнее перерисовки всего экрана, особенно в сети мобильной связи.

Я всегда считаю немного вздорной ситуацию, когда я получаю загружающуюся панель на веб-странице — вы уже отправили мне страницу, но почему сразу не отправили нужную мне страницу?! Один из величайших парадоксов Интернета заключается в том, что, хотя Google не очень хорошо справляется с обходом таких одностраничных приложений, эта компания, безусловно, создаёт большое их количество. Особенно дьявольской является «консоль поиска» (веб-сайт, ранее известный как «средства веб-мастера»). Я полагаю, Google не нужно слишком беспокоиться об оптимизации поисковых систем (SEO).

Пропускная способность быстро увеличивается, но задержка уменьшается медленно

Пропускная способность Интернета становится всё лучше и лучше. Сейчас можно передавать гораздо больше байт в секунду, чем даже несколько лет назад. Однако улучшения задержки довольно редки, и по мере приближения к значению для скорости света они совсем сойдут на нет.

100 мегаватт в секунду менее убедительны, когда вам по-прежнему приходится ждать всё те же полсекунды для загрузки каждой страницы.

Смотрите также

В прошлом году в центре APNIC проанализировали производительность CDN по всему миру и пришли к выводу, что задержка 40 мс типична. Мне бы хотелось, чтобы в эту публикацию были включены процентильные данные, но у меня сохраняется смутное впечатление, что сети CDN лучше всего работают на Западе и менее хорошо в Южной Америке, Китае и Африке, что является проблемой, учитывая, что большинство серверов находится на Западе.

Пока я писал эту статью, произошла вспышка «клубов», основанных на весе страницы, таких как Клуб 1МБ и, предположительно, более элитный Клуб 512К. Пожалуй, я одобряю это чувство (и всё это во имя веселья, я уверен). Я думаю, что они слишком подчёркивают размер передаваемых данных. Если вы в Лондоне запрашиваете динамически генерируемую страницу из Калифорнии, весь процесс всё равно займёт большую часть секунды (130 мс умножить на 5 операций передачи и подтверждения), независимо от того, насколько велик размер этой страницы.

На карту подводных кабелей всегда приятно смотреть. Если вы хотите увидеть признак разной важности разных мест: Нормандские острова (население 170 тыс. человек) имеют 8 подводных кабелей, в том числе два, которые просто соединяют Гернси и Джерси. У Мадагаскара (население 26 млн. человек) их всего четыре. Я также считаю забавным то, что, хотя Аляска и Россия довольно близки, между ними нет ни одного кабеля.

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

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering