Google работает над ускорением DNS

http://www.webmonkey.com/2011/08/opendns-and-google-working-with-cdns-on-dns-speedup/
  • Перевод
Группа DNS провайдеров и сети доставки контента (CDN) разработали новое расширение для протокола DNS, целью которого является более эффективно направлять пользователей на ближайшие CDN конечной точки. Google, OpenDNS, BitGravity, EdgeCast и CDNetworks участвующих в программе, которую они называют «Глобальное ускорение интернета» (Global Internet Speedup).

Новое расширение протокола DNS описывается в сообществе IETF: Для того, чтобы осуществить оптимизирование маршрутизации, Global Internet Speedup предлагают передавать DNS-серверам вместе с запросом адреса сайта фрагмент пользовательского IP-адреса размером в три первых октета, что позволит направить к нему поток данных с географически ближайшего сервера.

Новое расширение протокола уже реализуется OpenDNS и Google Public DNS. Они работают с сетями CDN и подписали контракт. Google и OpenDNS надеются сделать расширение протокола официальным стандартом IETF. Другие потенциальные усыновители, такие как интернет-провайдеры, могут свободно реализовать его из проекта спецификации.

На практике не совсем понятно, насколько это влияние скажется производительность сети. Стоит отметить, что технология GeoIP уже используется некоторыми серверами DNS для определения местоположения маршрутизации.

По словам главы OpenDNS Дэвида Улевича (David Ulevitch), с 30 августа, когда новая технология была впервые реализована, улучшение могли заметить 30 млн пользователей OpenDNS и Google Public DNS.
Метки:
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 28
  • –7
    >>целью которого является более эффективно направлять пользователей на ближайшие CDN конечной точки.

    В google решили задачу коммивояжера)?
    • +9
      Это никаким образом не задача коммивояжёра. Здесь нет необходимости обходить все узлы за минимальное время.
      А вот задачу поиска кратчайшего по времени пути, я верю, в Google решать умеют.
      • –1
        OSPF протокол умеет.
        ru.wikipedia.org/wiki/OSPF

        Правда, сам протокол изначально был на это рассчитан. А вот DNS — нет. Хотя, впрочем, система DNS-серверов иерархична, поэтому для «глобального ускорения интернета» достаточно будет обновить только часть серверов.
      • +3
        Нихера из написанного не понял. Какому серверу какой адрес передавать? они хотят похерить кеширование DNS и слать все запросы на авторитетные за зону сервера? Если нет, то не вижу проблем, потому что ресолвер и так знает IP клиента из заголовка IP пакета с запросом.
        • +1
          Ага, первая же мысль про кеширование.
          Но работать, по идее, будет и с кешированием. Например, сосед Вася резолвит example.com, первый из всей сети провайдера, ему новая система определеяет ближайший ip, это попадает в кеш, ты попадаешь уже на ближайший к тебе сервер, как и вся сеть провайдера, в кеше резолвера которого засел нужный адрес.
          Просто фишка новинки в том, что авторитетный сервер сможет получать первые три октета айпишника клиента, а не последнего из днс-форвардеров в цепочке.
          • +2
            т.е. 192.168.1? очень клёвую коллекцию соберут dns-серверы
            • 0
              Нас ждет ipv6, забыл? -)
              Никто не мешает при внесении правок в протокол предусмотреть ситуации с приватными айпишниками и передавать публичный адрес nat-транслятора.
              • 0
                Бог мой, да мелкие домашние маршрутизаторы и так задыхаются, куда им там ещё dns alg? :)

                По-моему, задачу решаются не на том уровне. А именно, задача выбора узла — это задача уровня сетевого, IP. А для реализации конкретно данной задачи в нём есть anycast.
                • 0
                  Что-то тебя кидает от одного к другому. Никакой проблемы с SOHO-железками я не вижу, днс-запросы составляют ничтожно малую часть от общего количества пакетов. А anycast как раз решает задачу балансировки для самих ДНС-серверов, т.к. изначально предназначался скорее для UDP. Его использование также подразумевает траты на автономку или, как минимум, PI-блок, наличие недешевых роутеров с поддержкой BGP, правильную настройку этого самого BGP и т.п.
                  А сабж поможет сделать гео-балансинг хоть любому школьнику, который просто купил пару VDS-ок на разных континентах по $10 каждая. Принесет гео-балансинг в массы, так сказать. Я только «за».
          • 0
            Авторитетному серверу передавать первые три октета адреса клиента. Сейчас если вы пользуетесь днсом гугла, то авторитетный днс не знает ничего о вашем фактическом местоположении — к нему пришёл запрос от гуглоднса. В предлагаемой схеме запрос состоит не просто из адреса, а из пары (адрес, первые три октета клиентского адреса), таким образом авторизованный сервер может выдать ответ учитывая ваше фактическое местоположение. Кэширование тоже будет производиться по двум параметрам.
            • 0
              Ну так это явное усложнение системы: будет передаваться больше данных, а кэширующим серверам потребуется больше памяти для их хранения.

              Как это может привести с ускорению DNS (при прочих равных)?
              • +1
                У топика неверный заголовок. Смысл не в ускорении ДНС, смысл в ускорении работы Интернета, за счет того, что ДНС будет учитывать географию. Костыли для этого существуют много лет, теперь предложено сделать это частью протокола.
              • 0
                То есть они предалагют увеличить нагрузку на кеширующий сервер по памяти раза так в 3-4…
                • 0
                  В n раз, где n — количество обслуживаемых /24 сетей. При нынешней цене на память это не то чтобы большая проблема, имхо.
                  • 0
                    Ок, ресолвер обслуживает 10/8. Допустим, мы щедро режем адреса по отделам/серверам и т.д. Имеем 30-40к сеток. Итого — вместо «мелкого сервиса в углу www» мы имеем необходимость иметь отдельные сервера кеширующего DNS.
                    • 0
                      а серые сети здесь причём?
                      • 0
                        А каким святым духом ресолвер угадает, для каких сетей это делать надо, а для каких нет?
                        • +1
                          rfc1918?
                          Если клиент может достучаться до резолвера по серой сети, то это наверняка означает, что они географически близко и для определения ближайшего сервера авторитетному днсу вполне достаточно адреса резолвера. Описанная схема актуально для резолверов, обслуживающих географически распределённых клиентов.
                  • 0
                    на авторитетный, он же будет выбирать «ближайший» адрес.
                    • 0
                      А чем тогда занимается кеширующий? Кеширует с учётом сети или всё срёт на авторитетные сервера? И так и так плоховато выглядит.
                      • +1
                        Вычислений он никаких не производит, а в кэше хранит помимо ответов еще и сети клиентов, которым эти ответы предназначались. То есть памяти будет жрать больше.
                        Где еще полезно применять описанное в драфте, кроме связки CDN + 3rd party DNS (типа OpenDNS, SkyDNS), я не знаю. Да и в такой связке, преимущества спорны.
              • 0
                Вообще-то это задача топологии. Интересно что там за алгоритмы. Напомнило поиск пути на игровой сетке, куда и как двигаться юниту.
                • 0
                  IETF Draft of edns-client-subnet
                  This Internet-Draft will expire on July 31, 2011.

                  Интересно
                  • +4
                    Рекламу они хотят лучше таргетировать, а не интернет ускорить.
                    Чтобы ускорить доступ нужно не географически близкий сервер выбирать, а тот, до которого ртт меньше. Потому что географически сервер может в соседней комнате стоять, но если маршрут к нему пролегает через западное полушарие или он загружен «с горкой», то можно представить как будет «ускорен» доступ при использовании этой технологии.
                    • 0
                      А чем принципиально задача уменьшения минимизации rtt отличается от задачи минимизации географического расстояния? Это просто метрики, все алгоритмы одинаковые. Для минимизации rtt _тоже_ нужно знать адрес клиента, а не его днса.
                      Для таргетирования рекламы такие фокусы не нужны.
                      • +1
                        Принципиально rtt — более объективная (в части скорости доступа) величина. В некотором роде rtt противоположно предлагаемому в драфте. Там DNS сервер говорит клиенту куда идти, rtt — клиент сам выбирает. Такой подход с точки зрения массового пользователя правильней.

                        Кроме этого к драфту есть еще некоторое кол-во претензий:
                        1) Никак не описано каким образом авторитетный сервер генерирует ответ, отдает он адрес только ближайшего сервера или нескольких ближайших? Если второе, то эффективность метода несколько падает.
                        2) Как фича из драфта коррелирует с DNSSEC? Если плюет на него, то достоверность данных проверить нельзя. Если не плюет, тогда в ответе авторитетный сервер должен указать все адреса, потому что подписывается набор записей, а не по одной, и смысл драфта в общем-то пропадает.

                        По поводу таргетирования я не буду спорить, потому как не осведомлен о технологиях.
                        • 0
                          про rtt вы на какой-то другой вопрос ответили (:

                          Ещё раз задача:
                          У вас есть сервер в европе и сервер в америке. Вы хотите чтобы статическая страничка www.example.com/index.html отдавалась для европейских пользователей с европейского сервера, а для американских — с американского. Причём по одному урлу и без редиректов.

                          Вы настраивайте свой DNS так чтобы на запросы с европейских ip www.example.com резолвился в адрес европейского сервера, а с американских — в адрес американского.

                          А теперь к вам приходит запрос от гуглоднса. Какой адрес ему отдать?
                          • 0
                            Ну да :) я рассказал почему rtt лучший показатель чем географическая близость. Отвечая на ваш: бОльшим простором для маневра.

                            А если пользователь пришел из Новой Зеландии, какой адрес ему отдать? Как вы можете быть уверены, что этот адрес будет для него актуален?
                            Кроме того, в драфте не указано, что у администратора DNS должна быть возможность явно указывать кому что отдавать. То есть, на данный момент это зависит от реализации. Соответственно, если выбор кому что отдать происходит автоматически, то могут быть очень неприятные и непредсказуемые казусы.
                            К примеру у меня есть два сервера, в Америке и России, как DNS сервер выберет какой адрес отдать, если оба проходят в GeoIP как российские?

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

                            И я тут еще касательно рекламы пообщался: у опенднс есть фича, что они показывают рекламу при, к примеру, NXDOMAIN. Вот тут есть простор для улучшения точности показа.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.