я нашел это объяснение как работает CDN. Но есть одна вещь, которую я действительно не понимаю. Предположим, я установил несколько DNS-серверов в своем местоположении, и они используют домены серверов имен. dns1.example.com, dns2.example.com и dns3.example.com. Эти DNS-серверы могут предоставлять IP-адрес сервера в зависимости от местоположения посетителей (пинг, географическая база данных, язык браузера или что-то еще). Теперь я обновляю настройки этого сервера имен для своего домена www.example.org в реестре.
Итак, самый первый запрос на www.example.org с истекшим TTL пытается разрешить домен. Спрашивает:
dns1.example.comНо если я правильно понимаю, новый IP-адрес добавляется во все эти кеши серверов имен, пока снова не истечет TTL. Итак, как можно отправить посетителю другие IP-адреса в зависимости от его местоположения?
В этот ответ theandym сказал, что запрос «пересылается», но я не думаю, что так работает CDN, потому что «пересылка» означает удлинение пути передачи, что приводит к увеличению времени загрузки. Или CDN требует нулевого TTL для домена?
Обновление1
Через этот вопрос я нашел Документ Google описывая, как они оптимизировали производительность CDN. В нем не объяснялось, как работает CDN в целом, но были интересные объяснения вроде следующего:
После этого всякий раз, когда клиент пытается получить контент, размещенный в CDN, клиент перенаправляется на узел, у которого определена наименьшая задержка для своего префикса. Однако это перенаправление основано на префиксе, соответствующем IP-адресу DNS-сервера имен, который разрешает URL-адрес контента от имени клиента, который обычно совпадает с клиентом.
Это означает, что Google сначала проверяет задержку всех IP-префиксов и определяет таблицу разрешения DNS (?) Для всех доступных префиксов. И если у посетителя есть IP 198.51.100.231 используется IP-адрес сервера Google, установленный для префикса 198.51.100.0. Но еще раз: как DNS Google узнает, какой IP-адрес использует посетитель? Большинство посетителей разрешают домен Google через своего интернет-провайдера, и при этом разрешение выполняется через эти внешние DNS-серверы или нет?
В качестве дополнительного примера: если я запускаю разрешение DNS для домена facebook.com с помощью разных онлайн-инструментов (размещенных в разных странах) он разрешается для разных IP-адресов с разными доменами, например:
После этого я подумал, что это может зависеть от местоположения DNS-сервера, используемого посетителем, но я попробовал свой собственный (Deutsche Telekom, Германия), Google (8.8.8.8) и крупный из Франции (Orange), и все они вернулись за facebook.com IP 31.13.92.36.
Хорошо, кажется, теперь я могу дать приблизительный ответ на свой вопрос. Анураг Бхатия говорит, что существует два метода работы CDN:
DNS
DNS должен творить чудеса, т.е. когда пользователи из сети ISP A ищут cdn.website.com, они должны получить взамен одноадресный IP-адрес Cache A, аналогично для пользователей, приходящих из сети ISP B, одноадресный IP Cache B должен возвращаться.
Допустим, у нас есть сервер с IP 1.2.3.4 находится в США и кеш-сервер с IP 2.3.4.5 находится в Германии. Теперь посетитель пытается разрешить домен example.org. Если он не менял свои сетевые настройки, он использует DNS-сервер своего интернет-провайдера (ISP). И этот провайдер сейчас спрашивает dns1.example.com (сервер имен домена) для IP. Теперь это зависит от местонахождения провайдера. Если он расположен в Германии, dns1.example.com возвращается 2.3.4.5 и если он находится в США, он возвращается 1.2.3.4.
Но у этого метода может быть недостаток: каждый раз, когда пользователь меняет свои сетевые настройки и использует EDNS0 (см. проект IETF) несовместимый DNS-провайдер (например, центральный DNS-сервер компании) dns1.example.com снова ответит с ближайшим IP-адресом к этим DNS-адресам, но на этот раз посетитель, скорее всего, находится в другом месте, что приведет к более высокой задержке.
EDNS0 совместимый Поставщики DNS передают информацию о пользователе к авторитетному DNS-серверу. Таким образом, авторитетный DNS-сервер может ответить IP-адресом рядом с местонахождением пользователя:
Сегодня, если вы используете OpenDNS или Google Public DNS и посещаете веб-сайт или пользуетесь услугой, предоставляемой одной из участвующих сетей или CDN в Global Internet Speedup, то в запрос DNS будет добавлена усеченная версия вашего IP-адреса. Интернет-служба или CDN будет использовать этот усеченный IP-адрес, чтобы принять более обоснованное решение о том, как он будет реагировать, чтобы вы могли подключиться к наиболее оптимальному серверу.
...
; EDNS: version: 0, flags:; udp: 512 ; CLIENT-SUBNET: 130.89.89.0/24/21
Anycast
Имейте маршрутизацию для маршрутизации к ближайшему узлу кеша на основе концепции «произвольной маршрутизации». Здесь Cache A, Cache B и Cache C будут использовать одинаковый IP-адрес, а маршрутизация позаботится о достижении ближайшего из них.
Я действительно не понимаю Anycast из-за BGP и т. Д., Но я думаю, что дальнейшее объяснение Anurag Bhatia дает представление о том, как это может работать:
- Оптимизация основана на маршрутизации и анонсе BGP с небольшой ролью DNS.
- Эту настройку очень сложно создать и масштабировать, поскольку для идеальной работы anycast на глобальном уровне требуется множество пиринговых и согласованных транзитных провайдеров в каждом месте. Если какой-либо из одноранговых узлов утекает маршрут к вышестоящим узлам или другим одноранговым узлам, может возникнуть много неожиданного трафика в данном кластере из-за прерывания любой передачи.
- Эта настройка не зависит от DNS-рекурсора, и, следовательно, Google DNS или OpenDNS работают нормально.
- Это позволяет сэкономить значительное количество IP-адресов, поскольку одни и те же пулы используются в нескольких местах.
У Anycast также есть недостаток: маршрутизация гибкая. Хотя в начале сеанса TCP целевой узел может находиться в сети A, он может измениться на сеть B. Поэтому Anycast будет использоваться на практике только для UDP. UDP - это бессессионный протокол.
Большинство CDN используют DNS для трафика HTTP / HTTPS и Anycast для запросов DNS.