Комментарии 28
>>целью которого является более эффективно направлять пользователей на ближайшие CDN конечной точки.
В google решили задачу коммивояжера)?
В google решили задачу коммивояжера)?
Это никаким образом не задача коммивояжёра. Здесь нет необходимости обходить все узлы за минимальное время.
А вот задачу поиска кратчайшего по времени пути, я верю, в Google решать умеют.
А вот задачу поиска кратчайшего по времени пути, я верю, в Google решать умеют.
OSPF протокол умеет.
ru.wikipedia.org/wiki/OSPF
Правда, сам протокол изначально был на это рассчитан. А вот DNS — нет. Хотя, впрочем, система DNS-серверов иерархична, поэтому для «глобального ускорения интернета» достаточно будет обновить только часть серверов.
ru.wikipedia.org/wiki/OSPF
Правда, сам протокол изначально был на это рассчитан. А вот DNS — нет. Хотя, впрочем, система DNS-серверов иерархична, поэтому для «глобального ускорения интернета» достаточно будет обновить только часть серверов.
Нихера из написанного не понял. Какому серверу какой адрес передавать? они хотят похерить кеширование DNS и слать все запросы на авторитетные за зону сервера? Если нет, то не вижу проблем, потому что ресолвер и так знает IP клиента из заголовка IP пакета с запросом.
Ага, первая же мысль про кеширование.
Но работать, по идее, будет и с кешированием. Например, сосед Вася резолвит example.com, первый из всей сети провайдера, ему новая система определеяет ближайший ip, это попадает в кеш, ты попадаешь уже на ближайший к тебе сервер, как и вся сеть провайдера, в кеше резолвера которого засел нужный адрес.
Просто фишка новинки в том, что авторитетный сервер сможет получать первые три октета айпишника клиента, а не последнего из днс-форвардеров в цепочке.
Но работать, по идее, будет и с кешированием. Например, сосед Вася резолвит example.com, первый из всей сети провайдера, ему новая система определеяет ближайший ip, это попадает в кеш, ты попадаешь уже на ближайший к тебе сервер, как и вся сеть провайдера, в кеше резолвера которого засел нужный адрес.
Просто фишка новинки в том, что авторитетный сервер сможет получать первые три октета айпишника клиента, а не последнего из днс-форвардеров в цепочке.
т.е. 192.168.1? очень клёвую коллекцию соберут dns-серверы
Нас ждет ipv6, забыл? -)
Никто не мешает при внесении правок в протокол предусмотреть ситуации с приватными айпишниками и передавать публичный адрес nat-транслятора.
Никто не мешает при внесении правок в протокол предусмотреть ситуации с приватными айпишниками и передавать публичный адрес nat-транслятора.
Бог мой, да мелкие домашние маршрутизаторы и так задыхаются, куда им там ещё dns alg? :)
По-моему, задачу решаются не на том уровне. А именно, задача выбора узла — это задача уровня сетевого, IP. А для реализации конкретно данной задачи в нём есть anycast.
По-моему, задачу решаются не на том уровне. А именно, задача выбора узла — это задача уровня сетевого, IP. А для реализации конкретно данной задачи в нём есть anycast.
Что-то тебя кидает от одного к другому. Никакой проблемы с SOHO-железками я не вижу, днс-запросы составляют ничтожно малую часть от общего количества пакетов. А anycast как раз решает задачу балансировки для самих ДНС-серверов, т.к. изначально предназначался скорее для UDP. Его использование также подразумевает траты на автономку или, как минимум, PI-блок, наличие недешевых роутеров с поддержкой BGP, правильную настройку этого самого BGP и т.п.
А сабж поможет сделать гео-балансинг хоть любому школьнику, который просто купил пару VDS-ок на разных континентах по $10 каждая. Принесет гео-балансинг в массы, так сказать. Я только «за».
А сабж поможет сделать гео-балансинг хоть любому школьнику, который просто купил пару VDS-ок на разных континентах по $10 каждая. Принесет гео-балансинг в массы, так сказать. Я только «за».
Авторитетному серверу передавать первые три октета адреса клиента. Сейчас если вы пользуетесь днсом гугла, то авторитетный днс не знает ничего о вашем фактическом местоположении — к нему пришёл запрос от гуглоднса. В предлагаемой схеме запрос состоит не просто из адреса, а из пары (адрес, первые три октета клиентского адреса), таким образом авторизованный сервер может выдать ответ учитывая ваше фактическое местоположение. Кэширование тоже будет производиться по двум параметрам.
Ну так это явное усложнение системы: будет передаваться больше данных, а кэширующим серверам потребуется больше памяти для их хранения.
Как это может привести с ускорению DNS (при прочих равных)?
Как это может привести с ускорению DNS (при прочих равных)?
То есть они предалагют увеличить нагрузку на кеширующий сервер по памяти раза так в 3-4…
В n раз, где n — количество обслуживаемых /24 сетей. При нынешней цене на память это не то чтобы большая проблема, имхо.
Ок, ресолвер обслуживает 10/8. Допустим, мы щедро режем адреса по отделам/серверам и т.д. Имеем 30-40к сеток. Итого — вместо «мелкого сервиса в углу www» мы имеем необходимость иметь отдельные сервера кеширующего DNS.
а серые сети здесь причём?
А каким святым духом ресолвер угадает, для каких сетей это делать надо, а для каких нет?
rfc1918?
Если клиент может достучаться до резолвера по серой сети, то это наверняка означает, что они географически близко и для определения ближайшего сервера авторитетному днсу вполне достаточно адреса резолвера. Описанная схема актуально для резолверов, обслуживающих географически распределённых клиентов.
Если клиент может достучаться до резолвера по серой сети, то это наверняка означает, что они географически близко и для определения ближайшего сервера авторитетному днсу вполне достаточно адреса резолвера. Описанная схема актуально для резолверов, обслуживающих географически распределённых клиентов.
на авторитетный, он же будет выбирать «ближайший» адрес.
А чем тогда занимается кеширующий? Кеширует с учётом сети или всё срёт на авторитетные сервера? И так и так плоховато выглядит.
Вычислений он никаких не производит, а в кэше хранит помимо ответов еще и сети клиентов, которым эти ответы предназначались. То есть памяти будет жрать больше.
Где еще полезно применять описанное в драфте, кроме связки CDN + 3rd party DNS (типа OpenDNS, SkyDNS), я не знаю. Да и в такой связке, преимущества спорны.
Где еще полезно применять описанное в драфте, кроме связки CDN + 3rd party DNS (типа OpenDNS, SkyDNS), я не знаю. Да и в такой связке, преимущества спорны.
Вообще-то это задача топологии. Интересно что там за алгоритмы. Напомнило поиск пути на игровой сетке, куда и как двигаться юниту.
IETF Draft of edns-client-subnet
This Internet-Draft will expire on July 31, 2011.
Интересно
This Internet-Draft will expire on July 31, 2011.
Интересно
Рекламу они хотят лучше таргетировать, а не интернет ускорить.
Чтобы ускорить доступ нужно не географически близкий сервер выбирать, а тот, до которого ртт меньше. Потому что географически сервер может в соседней комнате стоять, но если маршрут к нему пролегает через западное полушарие или он загружен «с горкой», то можно представить как будет «ускорен» доступ при использовании этой технологии.
Чтобы ускорить доступ нужно не географически близкий сервер выбирать, а тот, до которого ртт меньше. Потому что географически сервер может в соседней комнате стоять, но если маршрут к нему пролегает через западное полушарие или он загружен «с горкой», то можно представить как будет «ускорен» доступ при использовании этой технологии.
А чем принципиально задача уменьшения минимизации rtt отличается от задачи минимизации географического расстояния? Это просто метрики, все алгоритмы одинаковые. Для минимизации rtt _тоже_ нужно знать адрес клиента, а не его днса.
Для таргетирования рекламы такие фокусы не нужны.
Для таргетирования рекламы такие фокусы не нужны.
Принципиально rtt — более объективная (в части скорости доступа) величина. В некотором роде rtt противоположно предлагаемому в драфте. Там DNS сервер говорит клиенту куда идти, rtt — клиент сам выбирает. Такой подход с точки зрения массового пользователя правильней.
Кроме этого к драфту есть еще некоторое кол-во претензий:
1) Никак не описано каким образом авторитетный сервер генерирует ответ, отдает он адрес только ближайшего сервера или нескольких ближайших? Если второе, то эффективность метода несколько падает.
2) Как фича из драфта коррелирует с DNSSEC? Если плюет на него, то достоверность данных проверить нельзя. Если не плюет, тогда в ответе авторитетный сервер должен указать все адреса, потому что подписывается набор записей, а не по одной, и смысл драфта в общем-то пропадает.
По поводу таргетирования я не буду спорить, потому как не осведомлен о технологиях.
Кроме этого к драфту есть еще некоторое кол-во претензий:
1) Никак не описано каким образом авторитетный сервер генерирует ответ, отдает он адрес только ближайшего сервера или нескольких ближайших? Если второе, то эффективность метода несколько падает.
2) Как фича из драфта коррелирует с DNSSEC? Если плюет на него, то достоверность данных проверить нельзя. Если не плюет, тогда в ответе авторитетный сервер должен указать все адреса, потому что подписывается набор записей, а не по одной, и смысл драфта в общем-то пропадает.
По поводу таргетирования я не буду спорить, потому как не осведомлен о технологиях.
про rtt вы на какой-то другой вопрос ответили (:
Ещё раз задача:
У вас есть сервер в европе и сервер в америке. Вы хотите чтобы статическая страничка www.example.com/index.html отдавалась для европейских пользователей с европейского сервера, а для американских — с американского. Причём по одному урлу и без редиректов.
Вы настраивайте свой DNS так чтобы на запросы с европейских ip www.example.com резолвился в адрес европейского сервера, а с американских — в адрес американского.
А теперь к вам приходит запрос от гуглоднса. Какой адрес ему отдать?
Ещё раз задача:
У вас есть сервер в европе и сервер в америке. Вы хотите чтобы статическая страничка www.example.com/index.html отдавалась для европейских пользователей с европейского сервера, а для американских — с американского. Причём по одному урлу и без редиректов.
Вы настраивайте свой DNS так чтобы на запросы с европейских ip www.example.com резолвился в адрес европейского сервера, а с американских — в адрес американского.
А теперь к вам приходит запрос от гуглоднса. Какой адрес ему отдать?
Ну да :) я рассказал почему rtt лучший показатель чем географическая близость. Отвечая на ваш: бОльшим простором для маневра.
А если пользователь пришел из Новой Зеландии, какой адрес ему отдать? Как вы можете быть уверены, что этот адрес будет для него актуален?
Кроме того, в драфте не указано, что у администратора DNS должна быть возможность явно указывать кому что отдавать. То есть, на данный момент это зависит от реализации. Соответственно, если выбор кому что отдать происходит автоматически, то могут быть очень неприятные и непредсказуемые казусы.
К примеру у меня есть два сервера, в Америке и России, как DNS сервер выберет какой адрес отдать, если оба проходят в GeoIP как российские?
На мой взгляд, гораздо полезней дать клиенту выбирать какой сервер ему ближе. Клиент сделает этот выбор эффективней.
И я тут еще касательно рекламы пообщался: у опенднс есть фича, что они показывают рекламу при, к примеру, NXDOMAIN. Вот тут есть простор для улучшения точности показа.
А если пользователь пришел из Новой Зеландии, какой адрес ему отдать? Как вы можете быть уверены, что этот адрес будет для него актуален?
Кроме того, в драфте не указано, что у администратора DNS должна быть возможность явно указывать кому что отдавать. То есть, на данный момент это зависит от реализации. Соответственно, если выбор кому что отдать происходит автоматически, то могут быть очень неприятные и непредсказуемые казусы.
К примеру у меня есть два сервера, в Америке и России, как DNS сервер выберет какой адрес отдать, если оба проходят в GeoIP как российские?
На мой взгляд, гораздо полезней дать клиенту выбирать какой сервер ему ближе. Клиент сделает этот выбор эффективней.
И я тут еще касательно рекламы пообщался: у опенднс есть фича, что они показывают рекламу при, к примеру, NXDOMAIN. Вот тут есть простор для улучшения точности показа.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Google работает над ускорением DNS