DNS-запросы и Web

Web-клиент вызывает gethostbyname(), чтобы преобразовать доменное имя в IP-адрес до установления соединения транспортного уровня с Web-сервером. Например, предположим, что пользователь вводит URL http://www.foo.eom/a.html в браузере. Если ресурс отсутствует в кэше браузера, браузер должен связаться с Web-сервером. В некоторых случаях клиенту не требуется обращаться к DNS для преобразования www.foo.com:

•          Запрос, направляемый прокси-серверу. Клиент может быть настроен для отправки запросов прокси-серверу. Установка ТСР-соединения с прокси-сервером требует, чтобы клиенту был известен IP-адрес прокси-сервера, а не исходного сервера. Если клиент настроен с указанием доменного имени ирокси-сервера, то вызов gethostbyname() может стать необходимым для определения IP-адреса прокси-сервера. Клиенту, который сконфигурирован с указанием IP-адреса ирокси-сервера, пет необходимости инициировать вызов gethost- byname().

•          Запрос, удовлетворяемый из кэша клиента. Перед выдачей НТТР-запроса клиент осуществляет поиск Web-pecypca в своем локальном кэше. Если в кэше имеется актуальная копия запрашиваемого ресурса, клиенту пет нужды связываться с Web-сервером. В противном случае клиент должен связаться с Web-сервером для проверки актуальности кэшировапного ресурса и, возможно, загрузки нового ресурса с сервера.

•          Использование результата предыдущего запроса. Клиент может загрузить несколько ресурсов с одного и того же сервера. При обработке запроса на ресурс http://www.foo.eom/a.html клиент определяет IP-адрес для www.foo.com.

Если Web-страница имеет встроенные изображения, клиент может установить дополнительные ТСР-соедииепия с сервером для загрузки этих ресурсов. Чтобы избежать повторных вызовов gethostbyname(), клиент может воспользоваться IP-адресом, полученным при предыдущем вызове. Сохранение результатов вызова gethostbyname() отличается от DNS-кэширования на локалыюм DNS- сервере, поскольку вызов gethostbyname() не возвращает TTL, ассоциированный с ответом на DNS-запрос. Чтобы уменьшить риск использования устаревшей информации, Web-клиенту не следует хранить IP-адрес для www.foo.com слишком долго (т.е. не более нескольких мипут).

Web-клиент должен выяснить IР-адрес Web-сервера, Web-cepвepy IP-адрес клиента становится известным при поступлении запроса, поскольку клиентский IP-адрес содержится в заголовке каждого IP-пакета. Сервер может узпать доменное имя, ассоциированное с этим IP-адресом, вызвав функцию gethostbyaddr(). Знание доменного имени клиента может быть полезно для различных применений, в том числе регистрации, аутентификации и целевой рекламы. Например, запись доменного имени в журнал сервера дает возможность администратору сайта определить, какие запросы поступили от пользователей из определенных организаций. Web-сервер может также ограничивать доступ к определенным ресурсам, основываясь на доменном имени обратившегося с запросом клиента. Или же сервер может настроить HTTP- ответ на основе доменного имени клиента. Наиболее типичный пример такой иа- сгройки — целевая реклама, при которой встроенные изображения на Web-странице выбираются на основе доменного имени клиента, обратившегося с запросом.

Установление соответствия между IР-адресом Web-клиента и доменным именем осуществляется DNS-сервером в сети Web-клиента. У Web-клиента может возникнуть соблази неправильно указать свое доменное имя. Например, предположим, что Web-клиент имеет IР-адрес 10.34.56.78 и доменное имя a.badclient.com. В то же время на локальном DNS-сервере Web-клиента IP-адресу 10.34.56.78 соответствует доменное имя b.goodclient.edu. Предоставление невериого доменного имени может ввести в заблуждение Web-сервер, и он предоставит доступ не тому клиенту. В качестве меры предосторожности Web-сервер может после вызова gethostbyaddr() вызвать gethostbyname(). Вызов gethostbyname() определяет IP-адрес, ассоциированный с b.goodclient.edu. В данном примере соответствие может контролироваться другой организацией, что приведет к возврату другого IР-адреса, скажем, 122.33.205.4. Узнав, что два IP-адреса отличаются друг от друга, Web-cepвер может отклонить НТТР-запрос.

Определение но IP-адресу клиента соответствующего доменпого имени часто сопровождается значительной задержкой. Вызов функции gethostbyaddr() приводит к запросу к локальному DNS-серверу Web-сервера. Этот DNS-сервер вряд ли имеет информацию об IP-адресе клиента в своем кэше, если только клиент недавно не посылал Web-запрос этому же Web-серверу. Следовательно, должен быть выдан запрос к корневому серверу и к различным зональным серверам в домене in- addr.arpa. Запрос может оказаться неудачным. Мпогие клиенты имеют динамически выделяемые IP-адреса или IP-адреса, располагающиеся за корпоративным сетевым экраном. Эти адреса обычно не ассоциируются с доменными именами, подобные запросы приводят к задержкам в обходе DNS-иерархии и не возвращают полезной информации. Даже если запрос был успешным, выполнение последующего вызова gethostbyname() для проверки корректности соответствия IP-адреса доменному имени приведет к увеличению времени ожидания.

Помимо прочего, DNS-запросы потребляют ресурсы Web-сервера. Процесс, вызывающий функцию gethostbyaddr(), должен ожидать, пока будет сформирован ответ. Это увеличивает продолжительность времени обработки HTTP-запроса, что, в свою очередь, увеличивает число процессов, выполняющихся на сервере. Чтобы избежать перегрузки, Web-сервер, одновременно обрабатывающий большое количество запросов, может пропускать этап преобразования IP-адреса клиента в доменное имя. В зависимости от конкретного Web-сайта, знание доменного имени обратившегося с запросом клиента может быть и необязательным для корректной работы сервера. Однако в некоторых случаях Web-сервер может осуществлять па- стройку или аутентификацию на основе доменного имени клиента. Для достижения максимальной эффективности сервер может быть настроен таким образом, чтобы ограничить применение функции gethostbyaddr() только теми Web-запроса- ми, которые требуют эту информацию.

Выравнивание нагрузки на Web-cepвера с помощью DNS

DNS также играет важную роль в перенаправлении HTTP-запросов в группе Web-серверов, которые предоставляют доступ к одному и тому же содержанию. Хотя доменное имя обычно соответствует одному IP-адресу, достаточно активно используемый Web-сайт может быть реплицирован на несколько компьютеров, имеющих одно и то же доменное имя, о чем говорилось в главе 4 (раздел 4.5.2). Реплики необходимы, чтобы иметь возможность обрабатывать больше запросов. Кроме того, реплики могут быть размещены в различных географических зонах, чтобы предоставить лучший сервис различным клиентам. Например, доменному имени www.big.com могут соответствовать четыре Компьютера с IP-адресами 10.198.3.47, 10.198.3.48, 10.34.99.1 и 10.34.99.2. Чтобы поддерживать доменные имена с несколькими IP-адресами при ответе на запрос IP-адреса для www.big.com локальный DNS-сервер должен знать все четыре IP-адреса. Локальный DNS-сервер выбирает один из этих IP-адресов, чтобы вернуть его преобразователю, сделавшему запрос к DNS-серверу.

В традиционной реализации DNS локальный DNS-сервер будет выбирать первый IP-адрес в списке. Это приведет к большей загруженности НТТР-запросами Компьютера с IP-адресом 10.198.3.47. Чтобы избежать этого, DNS-сервер, ответственный за www.big.com, может варьировать порядок IP-адресов для каждого запроса. Например, ответ на первый DNS-запрос вернет 10.198.3.47, 10.198.3.48, 10.34.99.1 и 10.34.99.2, в то время как следующий ответ может вернуть 10.198.3.48, 10.34.99.1, 10.34.99.2 и 10.198.3.47. Подобная карусельная последовательность помогает распределить нагрузку между репликами Web-содержимого. Однако подобный подход не учитывает текущей нагрузки каждого из компьютеров и сети. Кроме того, он не учитывает расстояний между клиентским Компьютером и каждой из pe- нлик. Расширения реализаций DNS-серверов позволяют устранить эти недостатки без внесения изменений в протокол DNS. Эти изменения могут быть применены к DNS-серверу, получающему запрос, или к DNS-серверу, посылающему ответ.

Сначала рассмотрим изменения в программном обеспечении DNS-сервера, выдающего запрос. Предположим, что локальный DNS-сервер получает запрос от преобразователя на определение IP-адреса для www.big.com. DNS-сервер, ответственный за www.big.com, предоставляет список из четырех IP-адресов. Вместо того чтобы вериуть первый IP-адрес преобразователю, обратившемуся с запросом, ло- кальпый DNS-сервер может определить, какая из реплик подходит наилучшим образом. Этот процесс может основываться на различных факторах, таких как время передачи в прямом и обратном направлении (RTT) при взаимодействии с компьютером сервера или число маршрутизаторов на пути к серверу. Локальный DNS-сервер может время от времени измерять эти характеристики, чтобы уточнить оценки. Затем преобразователю предоставляется IP-адрес «наилучшей» реплики. Подобный подход не требует внесения изменений в программный код преобразователя или в программное обеспечение, выполняющееся на DNS-сервере, ответственном за www.big.com. Нуждается в изменении лишь программное обеспечение локального DNS-сервера. Однако выполнение оценок текущих характеристик времени передачи в обоих направлениях (RTT) обусловливает дополнительную загрузку локального DNS-сервера и сети.

Далее рассмотрим изменения в программном обеспечении DNS-сервера, отвечающего за ответ на запрос. DNS-сервер, ответственный за www.big.com, может попытаться выбрать «наилучший» из IP-адресов. Этот DNS-сервер может иметь доступ к актуальной информации о текущей загрузке каждого из четырех компьютеров www.big.com. Кроме того, DNS-сервер, ответственный за www.big.com, может попытаться оценить, какая из реплик ближе всего к локальному DNS-серверу, выдавшему запрос. DNS-сервер для www.big.com не знает IР-адрес Web-клиента, который отправил запрос локальному DNS-серверу. При выборе наилучшей реплики Web-сайта DNS-сервер для www.big.com может предположить, что Web- клиент находится вблизи локального DNS-сервера. Близость Web-клиента сокращает время ожидания при обработке Web-запросов и снижает объем сетевых ресурсов, требующихся для доставки IP-пакетов. Решение, какой IP-адрес возвращать, может основываться на различных факторах, в числе которых близость к клиенту, нагрузка на сеть и нагрузка на реплики сервера.

Как правило, ответ на DNS-запрос может кэшироваться достаточно продолжительное время в зависимости от значения поля TTL. Значения TTL может достигать дней или даже недель. Однако большие значения TTL не дают возможности DNS-серверу big.com контролировать, к каким репликам www.big.com осуществляется доступ. Чтобы добиться большей степени контроля, DNS-ответы должны использовать меньшие значения TTL, порядка мииут. Это гарантирует, что локальный DNS-сервер не будет кэшировать ответ слишком долго. По истечении времени храпения записи в кэше Локальный DNS-сервер не сможет обработать следующий запрос от преобразователя, не связываясь с DNS-сервером big.com повторно. Это дает DNS-серверу возможность отвечать различными IP-адресами для www.big.com. Однако это также требует, чтобы Web-бpayзep дольше ожидал завершения вызова gethostbyname() при истечении времени хранения кэшированной информации на локальном DNS-сервере. Помимо этого, небольшие Значения TTL ведут к более высокой загрузке системы в целом. Инфраструктура DNS не была предназначена для поддержки выравнивания нагрузки на серверы. Рост Web и уменьшение значений TTL ноднял вопрос об изменении и расширении инфраструктуры DNS. Методы направления клиентских запросов репликам подробнее обсуждаются в главе 11 (раздел 11.12).

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100