Я пытаюсь понять, как RTD для серверов Google может быть таким низким:
$ ping google.com
PING google.com (173.194.113.64): 56 data bytes
64 bytes from 173.194.113.64: icmp_seq=0 ttl=57 time=28.166 ms
173.194.113.64зарегистрирован в Маунтин-Вью, Калифорния, а я в Германии. Пинг до хоста в Калифорнии будет намного длиннее. Выдача traceroute дает мне имя хоста fra02s21-in-f0.1e100.net. Я спрашиваю себя, какие методы они используют для перенаправления моего запроса?
решение1
Вы правы, RTD не может быть < 30 мс для США. Из Европы в США должно быть около 60 мс (в одну сторону).
Так что у Google, вероятно, есть какой-то кэш-сервер по эту сторону океана
(и он просто зарегистрирован для Маунтин-Вью, хотя на самом деле находится в Европе).
я нашелЭта статьяобъясняя это:
секретность Google
Google усложнил задачу как по поиску своих дата-центров, так и по поиску их количества. Одной из главных причин этого является то, что почти все IP-адреса, которые использует Google (а их много)указаны по адресу Маунтин-Вью, Калифорния, поэтому просто просматриваем IP-адреса (с помощью IP WHOIS или баз данных IP-адресов)не поможет вам выяснить, где находятся их центры обработки данныхили сколько их у них есть.
Кроме того, Google обычно запрашивает разрешения на свои проекты центров обработки данных, используя компании (LLC), в которых Google вообще не упоминается, например, Lapis LLC в Северной Каролине и Tetra LLC в Айове.
Поскольку Google в целом имеет тенденцию сохранять в тайне информацию о своих центрах обработки данных, представленная нами здесь информация, скорее всего, не является на 100% полной.
Бонусная ссылка ;)Взгляд изнутри на центры обработки данных Google.
Вотдругой источник:
2) Крупные компании с офисами по всему миру не делятся информацией о своем реальном местоположении в whois.
- Пример: Google Inc. имеет свои дата-центры по всему миру, но whois всегда указывает на головной офис в Маунтин-Вью (Калифорния, США). В реальности пользователи из разных стран будут перенаправлены в ближайший дата-центр. Для немца, например, главная страница будет загружена из немецкого дата-центра (74.125.39.104).
Редактировать:(имейте в виду, что я не эксперт в этой теме:)
Вы, вероятно, правы, что "авторитетный сервер имен" делает некоторые перенаправления. Я не уверен, есть ли несколько серверов зачтокоторые делают дальнейшую переадресацию. Вы можете сделать, dig google.com +traceчтобы увидеть, с какого сервера на какой сервер идет ваш DNS-запрос. (Читатьздесьо некоторых основах, лежащих в его основе)
Что касается механизма перенаправления. Вы упомянули Akamai CDN. Google использует свой собственный CDN. Ходили слухи о том, что Google покупает Akamai несколько лет назад, но этого не произошло. Я думаю, что Apple использует Akamai CDN (среди некоторых других CND).
Наэта страницавы можете прочитать, что Google использует «расширение edns-client-subnet».
OpenDNS и Google DNS уже давно поддерживают расширение edns-client-subnet. Этот механизм был разработан Google специально для решения этой проблемы. И он прекрасно работает. CDN могут отправлять перенаправление на лучший сервер независимо от того, какой резолвер вы используете.
С некоторыми дальнейшимиГуглитевы можете узнать больше об этом механизме. Нравитсяздесь:
Google, Bitgravity, CDNetworks, DNS.com и Edgecast развернули поддержкуedns-клиент-подсеть. Идея довольно проста. Он передает часть вашего IP-адреса (только часть, чтобы сохранить его полуанонимным) в запросе. Сервер, поддерживающий это расширение, может использовать его для геотаргетинга и поиска ближайшего к вам узла CDN. Раньше лучшее, что можно было сделать, — это использовать местоположение DNS-сервера, который во многих случаях мог находиться далеко.
Еще одна полезная статья о CDN и расширении edns-client-subnet:этот.
Достаточно материала для чтения черезGoogle;)