The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
CDN расшифровывается как сеть доставки контента. Технически, это набор серверов, расположенных в разных странах и на разных континентах. Вы даете им свой logo.gif, а они дают вам URL, который разрешается в разные серверы в зависимости от того, кто пытается его разрешить. В результате файл всегда близок к конечному пользователю, и ваш веб-сайт загружается намного быстрее, чем без CDN. Звучит хорошо, но все поставщики CDN хотят деньги за свои услуги и обычно требуют довольно сложной настройки и процедуры регистрации. Мой собственный проект jare.io - это бесплатный CDN, который прост в настройке. Он использует ресурсы AWS CloudFront.
Сначала я покажу, как это работает, а затем, если вам интересны подробности, я объясню, как это делается внутри. Предположим, у вас есть такой HTML:
Я хочу, чтобы этот logo.svg доставлялся через CDN. Есть два шага. Сначала я регистрирую свой домен на jare.io:
Второй шаг - я изменяю свой HTML:
That’s it.
Попробуйте это с использованием ваших собственных ресурсов, и вы увидите, насколько быстрее они будут загружаться.
Это абсолютно бесплатно, но я прошу вас быть разумными. Если у вас огромный трафик, вам нужен собственный аккаунт в CloudFront или где-то еще. Моя услуга предназначена для небольших проектов.
Теперь немного технических деталей, если вы хотите узнать, как технически работает это решение. Сначала обсудим, что такое CDN и как оно работает.
Когда ваш браузер хочет загрузить изображение, у него есть URL, как в примере выше. Вот этот URL: http://www.teamed.io/image/logo.svg. В этом адресе есть три важные части. Первая - http, протокол. Вторая - www.teamed.io, имя хоста, и хвост /images/logo.svg, который является путем. Чтобы загрузить изображение, браузер должен открыть сокет, соединяющий ваш компьютер и сервер, на котором находится изображение. Чтобы открыть сокет, браузеру нужно знать IP-адрес сервера.
В этом URL нет такого адреса. Чтобы найти IP-адрес, браузер выполняет так называемый поиск. Он подключается к ближайшему именному серверу и спрашивает: “какой IP-адрес у www.teamed.io?” Ответ обычно содержит один IP-адрес:
IP-адрес www.teamed.io на момент написания составляет 199.27.79.133.
Когда адрес известен, браузер открывает новый сокет и отправляет через него HTTP-запрос.
Сервер отвечает с HTTP ответом:
Это изображение SVG, которое мы ищем. Браузер отображает его на веб-странице и всё.
Пока все хорошо, но если расстояние между вашим браузером и этим IP-адресом достаточно велико, загрузка изображения займет много времени. Что-то вроде сотен миллисекунд. Попробуйте загрузить это изображение, которое находится на сервере, размещенном в Праге, Чешская Республика (я использую curl, как рекомендовано здесь).
Я пытаюсь сделать это из Пало-Альто, Калифорния, что находится примерно на половине земного шара от Праги. Как видите, это занимает более 500 мс. Это слишком много, особенно если на веб-странице содержится много изображений. В целом, загрузка страницы может занимать несколько секунд, только потому что сервер находится слишком далеко от меня. Что ж, он всегда будет слишком далеко от некоторых пользователей, независимо от того, где мы его разместим. Если мы его разместим здесь, в Калифорнии, он будет достаточно близко ко мне, и изображение будет загружаться мгновенно (менее 50 мс). Но для пользователей в Праге это будет слишком медленно.
У этой проблемы нет решения, если сервер генерирует изображения или страницы на лету в каком-то уникальном формате, и если мы не можем установить несколько серверов в разных странах и на разных континентах. Но в большинстве случаев, как в нашем примере с логотипом, это не проблема. Этот логотип не должен быть уникальным для каждого пользователя. Он является очень статичным ресурсом, который должен быть создан только один раз и доставлен всем без изменений.
Итак, что если мы установим сервер где-нибудь здесь, в Калифорнии, и позволим пользователем из Калифорнии подключаться к нему? Когда запрос на logo.gif поступает на один из крайних серверов, он будет подключаться к центральному серверу в Праге и загружать файл. Это произойдет только один раз. После этого, крайний сервер не будет запрашивать файл у центрального сервера. Он будет сразу возвращать его из своего внутреннего кэша.
Нам нужно иметь много крайних серверов, желательно во всех странах, где могут находиться наши пользователи. Первый запрос займет больше времени, но все последующие будут гораздо быстрее, так как они будут обрабатываться ближайшим крайним сервером.
Теперь вопрос в том, как браузер будет знать, какой крайний сервер является наиболее близким, верно? Мы просто обманываем процесс разрешения доменного имени. В зависимости от того, кто спрашивает, DNS будет давать разные ответы. Давайте возьмем, например, cf.jare.io (это имя всех крайних серверов, ответственных за доставку нашего контента в AWS CloudFront, CNAME для djk1be5eatcae.cloudfront.net). Если я запрашиваю его из Калифорнии, я получаю следующий ответ:
Находится крайний сервер с IP-адресом 54.230.141.211 в Сан-Франциско. Это довольно близко ко мне, менее чем в пятидесяти милях. Если я выполняю ту же операцию с сервера в Вирджинии, я получаю другой ответ:
Крайний сервер с IP-адресом 52.85.131.217 расположен в Вашингтоне, что находится далеко от меня, но очень близко к серверу, с которого я выполнял поиск.
По всему миру существует тысячи серверов имен, и у каждого из них есть разная информация о том, где физически находится этот крайний сервер cf.jare.io. В зависимости от того, кто спрашивает, ответ будет разным.
CloudFront - одно из самых простых решений CDN. Все, что вам нужно сделать, чтобы начать доставку контента через их узлы, это создать “распределение” и настроить его. Распределение является связующим звеном между исходным контентом и краевыми серверами:
skinparam componentStyle uml2 Browser -right-> [Edge] [Edge] -right-> [Central] [Central] -right-> [Origin]
Один из краевых серверов получает HTTP-запрос. Если у него уже есть logo.svg в своем кэше, он сразу возвращает HTTP-ответ с его содержимым. Если его кэш пуст, краевой сервер отправляет HTTP-запрос на центральный сервер. Этот сервер знает о “распределении” и его настройках. Он устанавливает HTTP-соединение с исходным сервером, который является www.teamed.io, и запрашивает возврат logo.svg. После выполнения изображение возвращается на краевой сервер, где оно кэшируется.
Это выглядит довольно просто, но это не бесплатно и настройка занимает некоторое время. Вам нужно создать учетную запись в CloudFront, зарегистрировать там свою кредитную карту и получить одобрение. Затем вам нужно создать распределение и настроить его. Вы также должны создать CNAME на своем сервере имен. Если вы делаете это для одного веб-сайта, это не проблема. Если у вас есть дюжина веб-сайтов, это займет много времени.
Jare.io - это дополнительный компонент в этой диаграмме, который облегчает вашу жизнь:
skinparam componentStyle uml2 Браузер -right-> [Соединение] [Соединение] -right-> [Центральный] [Центральный] -down-> [Реле] [Реле] -right-> [Источник]
У Jare.io есть “реле”, которое действует как исходный сервер для CloudFront. Все запросы, которые поступают на cf.jare.io, отправляются на реле. Реле решает, что с ними делать. Решение основано на информации из URI HTTP-запроса. Например, у запроса из браузера есть такой путь URI:
Помните, что запрос делается на cf.jare.io, который является адресом крайнего сервера. Точно такой же URI достигает relay.jare.io. URI содержит достаточно информации для принятия решения о том, какой файл должен быть возвращен. Реле делает новый HTTP-запрос на www.teamed.io и получает изображение.
Преимущество этого решения заключается в его простоте. Для небольших веб-сайтов это бесплатный и быстрый CDN.
Кстати, когда мы запрашиваем то же изображение через jare.io (и CloudFront), оно возвращается намного быстрее.
Большая часть работы выполняется AWS CloudFront, в то время как jare.io является всего лишь ретранслятором, который облегчает его настройку. Кроме того, это бесплатно, потому что jare.io спонсируется Zerocracy. Другими словами, моя компания будет оплачивать использование CloudFront. Я был бы благодарен, если вы учтете это и не использовали jare.io для ресурсов, требующих большого объема трафика.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-22 at 10:33
