Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

Подождите немного. Документ загружается.

160

Часть III. Web-протоколы

В отличие от контрольной суммы IP-заголовка, когпрольная сумма TCP рас-

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

ность получателю выявить, был ли ТСР-сегмент поврежден во время переда-

чи по сети. Отправитель вычисляет контрольную сумму массива из заголовка

и данных. Получатель пересчитывает контрольную сумму и сравнивает ее со

значением в заголовке TCP. Если результаты различаются, получатель отвер-

гает поврежденный пакет. Получатель не подтверждает получение поврежден-

ного пакета. Следовательно, отправитель должен повторно передать не посту-

пившие данные.

• Указатель срочных данных (urgent pointer) (16 битов). Если флаг URG ус-

тановлен, 16-битный указатель срочных данных обращает внимание получате-

ля на определенную часть входных данных (например, символ ctrl-C, который

прерывает передачу данных). 16-битный указатель срочных данных иденти-

фицирует последний байт срочных данных как целочисленное смещение от

порядкового номера в ТСР-заголовке.

IP-заголовок содержит некоторую информацию, необходимую для ТСР-соеди-

нения, включая IP-адреса отправителя и получателя, а также размер пакета. Раз-

мер IP-пакета представляет собой сумму длин IP-заголовка, ТСР-заголовка и

ТСР-сегмента. Длина IP-заголовка включается в IP-заголовок, а длина ТСР-заго-

ловка включается в ТСР-заголовок.

• • •

-X-

-•^ -X-

4501-4600 4601-4700 4701-4800 4801-4900

SYN (4500)

Рис. 5.9. Четыре сегмента в ТСР-соедииепии (третий сегмент утерян)

При поступлении пакета получатель определяет диапазон байтов, занимаемый

ТСР-сегментом, основываясь на его порядковом номере и длине. Предположим,

что отправитель начал с исходного порядкового номера 4500 и передает данные

100-байтными сегментами, как показано на рис. 5.9. Порядковый номер 4500 соот-

ветствует открытию ТСР-соединения. Первый сегмент имеет порядковый номер

4501 и длину 100, и занимает байты с 4501 по 4600. Второй сегмент имеет порядко-

вый номер 4601 и длину 100, и т.д. Допустим, что В получает первый, второй и чет-

вертый сегменты; третий 100-байтный сегмент был утерян или задержан. Посколь-

ку В было получено только 200 последовательных байтов потока, подтверждаю-

щий пакет от В к А будет иметь номер подтверждения, равный 4701 (4501+200).

Номер байта 4701 представляет собой порядковый номер следующего байта, кото-

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

вует передаче сегмента, а ноле номера подтверждения соответствует получению

данных. Приложения А и В могут передавать данные друг другу одновременно.

Для любого пакета значения полей порядкового номера и номера подтверждения

не взаимосвязаны, поскольку они не относятся к одному и тому же направлению

передачи.

Глава 5. Протоколы, связанные с HTTP 161

5.3.

Служба именования доменов (DNS)

Служба именования доменов (DNS

—

Domain Name System) координирует пре-

образование доменных имен хостов в IP-адреса и IP-адресов в доменные имена

[Мос87Ь, Pos94]. В этом разделе будет рассмотрено, как приложение взаимодейст-

вует с DNS-нреобразователем, который выдает запросы локальному DNS-серверу.

Далее будет рассмотрена иерархическая и распределенная структура DNS, после

чего мы рассмотрим протокол DNS. Далее мы посмотрим, как Web-клиенты, про-

кси-серверы и Web-серверы выдают DNS-запросы, и как DNS используется для

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

5.3.1,

DNS-преобразователь

1Р-маршру1^изаторы пересылают пакеты на основе 32-битного адреса места назна-

чения в IP-заголовках. Однако цифровые адреса неудобны для гюльзователей и при-

ложений. Компьютеры в Internet обычно имеют доменные имена, например,

ftp.foo.com или cs.berkeley.edu, которые состоят из строк, разделяемых точками. За-

помнить доменное имя гораздо проще, чем IP-адрес. Кроме того, IP-адрес, ассоцииро-

ванный с домегшым именем, может со временем меняться. Например, IP-адрес

Web-сайта может зависеть от того, какая компания осуществляет хостинг. Если

Web-сайт передается другой хостинговой компании, IP-адрес может измениться. Если

бы URL Web-сайта включал IP-адрес (например, http://10.187.56.3/ bar.html), а не

доменное имя (например, http://www.foo.com/ bar.html), URL изменялся бы каж-

дый раз при изменении IP-адреса. Любые попытки использовать старый URL (на-

пример, из списка закладок браузера) оканчивались бы неудачей. Наконец, один и

тот же Web-сайт может быть доступен на нескольких хостах, каждый из которых

имеет собственный IP-адрес. Идентификация сайта по доменному имени обеспечи-

вает гибкость при принятии решения, с каким сервером контактировать. Помимо

преобразования доменных имен в IP-адреса, приложению может потребоваться ус-

тановить доменное имя, ассоциированное с определенным IP-адресом. Например,

FTP-сервер может проверять, принадлежит ли ЕТР-клиент домену верхнего уров-

ня .edu.

Преобразование доменных имен в IP-адреса и IP-адресов в доменные имена

осуществляется DNS. Internet-приложения, например, браузеры, осуществляют

доступ к DNS через преобразователь (resolver), представляющий собой программ-

ную библиотеку, которая связана с приложением. DNS-преобразователь выполняет

две основные функции. Функция gethostbynameQ преобразовывает доменное имя

в IP-адрес, а функция gethostbyaddrQ преобразовывает IP-адрес в доменное имя.

Преобразователь взаимодействует с одним или с несколькими DNS-серверами для

выполнения этих функций от имени приложения. Чтобы осуществить этот про-

цесс,

преобразователь должен знать, как связаться по крайней мере с одним

DNS-сервером. Для компьютера, подключенного к Internet, обычно указывается

список IP-адресов, каждый из которых соответствует локальному DNS-серверу.

Сетевые администраторы обычно стараются размещать локальные DNS-серверы

ближе к клиентам, обращающимся с запросами. Например, факультет университе-

та может иметь сеть Ethernet, объединяющую все компьютеры, в составе которой

имеются локальные DNS-серверы. Провайдер может размещать свои DNS-серверы

вблизи от модемного пула, через который пользователи взаимодействуют с сетью.

Итак, предположим, что пользователь вводит в Web-браузере URL

http://www.foo.eom/a.html. Программное обеспечение браузера извлекает имя до-

162 Часть IIL Web-протоколы

мена www.foo.com из URL. Чтобы связаться с Web-сервером, браузер должен пе-

ревести www.foo.com в IP-адрес. Программное обеспечение браузера вызывает для

этого функцию gethostbynameQ, которая связывается с одним из локальных DNS-

серверов. Ответ DNS-сервера содержит IP-адрес Web-сервера, который возвраща-

ется функцией gethostbynameQ. После этого браузер может инициировать взаимо-

действие с www.foo.com. В некоторых случаях приложение вызывает функцию

gethostbynameQ с полностью заданным именем домена, которое идентифицирует

полное доменное имя, такое как zippy.bar.com. В других случаях приложение об-

ращается к хосту по усеченному имени, например, zippy. При настройке клиент-

ского компьютера указывается имя домена но умолчанию, используемое для

DNS-запросов. Так, предположим, что клиентский компьютер настроен для ис-

пользования bar.com в качестве имени домена но умолчанию. Если пользователь

вводит URL http://zippy в Web-браузере, функция gethostbynameQ запрашивает

DNS-сервер для определения IP-адреса, ассоциированного с полным именем доме-

на zippy.bar.com.

Практически каждое Internet-нриложение вызывает функцию gethostbynameQ

перед началом взаимодействия с другим компьютером. Например, при отправке со-

общения электро1Н10Й почты но адресу buddy@zippy.bar.com или загрузке файла

с ftp.foo.com требуется, чтобы приложение знало IP-адрес удаленного компьютера.

Приложению, выполняющемуся на удаленном компьютере, может потребоваться

отправить ответ. Для этого приложение-получатель должно знать IP-адрес отпра-

вителя. IP-адрес отправителя доступен из заголовка IP-пакета. Таким образом,

удаленному компьютеру не нужно связываться с DNS-сервером для ответа отпра-

вителю. Однако приложению-получателю не известно доменное имя компьютера,

отправившего сообщение. Знать доменное имя полезно, если удаленное приложе-

ние выполняет регистрацию или аутентификацию. Например, предположим, что

администраторы ftp.bar.com не хотят предоставлять доступ пользователям с zip-

py.bar.com но Telnet. Для этого Telnet-нриложению на ftp.bar.com понадобится

определить доменное имя компьютера, запрашивающего соединение, перед тем,

как разрешить доступ. Telnet-приложение должно преобразовать IP-адрес отправи-

теля в доменное имя, воспользовавшись функцией gethostbyaddrQ.

5.3.2. Архитектура DNS

На первых порах существования ARPANET преобразование доменных имен

в IP-адреса выполнялось централизованно. Один главный файл содержал список

IP-адресов, ассоциированных с доменными именами. Файл обновлялся несколько

раз в неделю. Каждая организация, подсоединенная к ARPANET, была ответствен-

на за обновление своей локальной копии этого файла. Подобный подход годился,

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

файла стало вызывать затруднения. Для решения этой проблемы была создана

служба DNS, представляющая собой распределенную базу данных с иерархической

системой серверов, каждый из которых ответственен за группу доменных имен и

IP-адресов. Архитектура DNS отражает иерархию доменных имен и IP-адресов.

Преобразование доменных имен в IP-адреса осуществляется на основе составляю-

щих доменных имен. Аналогично, преобразование IP-адресов в доменные имена

осуществляется на основе чисел в IP-адресе.

DNS имеет иерархическое пространство имен с безымянной корневой частью,

как показано на рис. 5.10. Первый уровень древовидной структуры содержит доме-

ны верхнего уровня. Имена доменов верхнего уровня отражают историю эволюции

Глава 5. Протоколы, связанные с HTTP

163

Безымянная корневая часть

Домены

верхнего уровня

Домены

второго уровня

(www) { ftp ) (users)

www.west.bar.com ftp.east.bar.com users.cam.ac.uk

Рис. 5.10. Иерархия DNS

Internet из сети ARPANET, созданной в США. Верхний уровень включает грех-

символьные родовые домены:

• коммерческие организации (.com),

• образовательные учреждения (.edu),

• правительственные учреждения США (.gov),

• военные учреждения США (.mil),

• сети (.net),

• другие организации (.org).

Хотя имена .edu, .gov и .mil зарезервированы для учреждений США, остальные

домены верхнего уровня используются за пределами США. В ноябре 2000 г. были

введены семь новых доменов верхнего уровня:

• отрасли, связанные с воздушным транспортом (.aero),

• организации, связанные с бизнесом (.biz),

• некоммерческие организации (.coop),

• для неограниченного использования (.info),

• музеи (.museum),

• отдельные личности (.name),

• бухгалтеры, юристы и врачи (.pro).

К доменам верхнего уровня также относятся двухсимвольпые домены, соответ-

ствующие странам от острова Вознесения (.ас) до Зимбабве (.zw). Отдельный до-

мен .агра управляет преобразованием IP-адресов в имена доменов. Этот процесс

будет более подробно описан далее в данном разделе.

164 Часть III. Web-протоколы

До конца 90-х годов за управление DNS и присвоение IP-адресов и имен доме-

нов отвечали организации, контролируемые правительством США. В конце 90-х

годов эти функции были переданы Корпорации по присвоению имен и номеров

(ICANN — Internet Corporation for Assigned Names and Numbers) [ICAJ. Домены

верхнего уровня обслуживаются группой корневых серверов. Предположим, Web-

пользователь вводит URL http://www.east.bar.eom/a.html в браузере. Преобразо-

ватель связывается с локальным сервером имен для преобразования

www.east.bar.com в IP-адрес. Если информация не была кэширована, локальный

сервер имен связывается с корневым сервером, чтобы определить IP-адрес DNS-

сервера .com. Затем локальный DNS-сервер связывается с DNS-сервером .com,

чтобы узнать IP-адрес DNS-сервера, ответственного за зону bar.com. Каждая зона

представляет собой часть дерева в иерархии DNS, администрируемую отдельно.

Зона обычно имеет первичный сервер и несколько вторичных серверов, которые

могут замещать первичпый в случае аварии. В зависимости от размера организа-

ции домен может быть поделен на множество зон в соответствии, например, с раз-

личным географическим положением.

Первоначальный подход, при котором все доменные имена и IP-адреса содержа-

лись в одном файле, не мог быть использован для обслуживания множества домен-

ных имен, которое имеется сегодня в Internet. Разделение административной от-

ветственности имело важное значение для поддержки быстрого роста Internet. Ор-

ганизации не нужно уведомлять центральную базу данных при добавлении или

удалении хостов в своей сети. Аналогично, организация bar.com может принять ре-

шение иметь две отдельные зоны для east.bar.com и west.bar.com. Компания мо-

жет иметь два главных офиса в США, один на восточном побережье, а другой

—

на

западном. Деление bar.com на две зоны дает возможность каждому офису обнов-

лять соответствия между доменными именами и IP-адресами независимо друг

с другом. Хостам же надо лишь знать IP-адрес одного или нескольких DNS-серве-

ров.

Им не нужно располагать информацией о добавлении или удалении других

хостов. Организации нужно обновлять данные в своей родительской зоне только

в том случае, если добавляется или удаляется DNS-сервер. Это случается не слиш-

ком часто.

Иерархия имен доменов не соответствует иерархической структуре IP-адресов.

Хотя и www.east.bar.com, и www.west.bar.com имеют в составе имени bar.com, их

IP-адреса могут быть совершенно различными. Для эффективного установления со-

ответствия IP-адресов и доменных имен требуется отдельная иерархия на основе

IP-адресов. В начале двадцать первого века выделение IP-адресов осуществляется

тремя региональными Internet-регистрами: APNIC (Asia-Pacific Network Information

Centre), ARIN (American Registry for Internet Numbers) и RIPE NCC (Reseaux IP

Europeens Network Coordination Centre). ICANN распределяет фрагменты простран-

ства IP-адресов между этими организациями, которые, в свою очередь, вьщеляют ад-

реса организациям внутри их регионов. Выделение фиксированного набора адресов

каждому из регионов помогает осуществлять эффективное выделение оставшихся

адресов IPv4. Кроме того, вьщеление больших блоков IP-адресов по географическо-

му принципу облегчает маршрутизацию. В идеале маршрутизатору в одной части

земного шара не нужно знать, как достичь каждой из организаций в другой части

земного шара.

При получении блока IP-адресов организация становится ответственной за

часть пространства имен in-addr.arpa. Пространство имен in-addr.arpa представля-

ет собой иерархию, основанную на октетах в 32-битном IP-адресе, начиная с верх-

пего уровня иерархии адресации — крайнего левого октета в адресе. Например,

Глава

Протоколы,

связанные

HTTP

165

чтобы найти доменное имя, ассоциированное с IP-адресом 12.34.56.78, необходимо

связаться с сервером 12.in-addr.arpa. Этот домен может быть поделен на состав-

ляющие домены, одним из которых является домен 34.12.in-addr.arpa. Такое раз-

деление ответственности по октетам отражает исторически сложившуюся практику

выделения IP-адресов с фиксированной длиной префикса, равной 8, 16 и 24. В со-

ответствии с положениями CIDR, организация может иметь блок IP-адресов, кото-

рый не совпадает с границами октетов. Так, предположим, что адресный блок

12.34.56.0/23 выделен одной компании. При этом DNS-сервер, ответственный за

домен 34.12.in-addr.arpa, может выделить этой компании как адрес 56.34.12.in-

addr.arpa, так и адрес 57.34.12.in-addr.arpa. Компания будет отвечать за связь от-

дельных IP-адресов в пространстве 12.34.56.0/23 с доменными именами.

5.3.3.

Протокол DNS

Протокол DNS управляет взаимодействием между DNS-клиентом и DNS-серве-

ром. DNS-клиент посылает

запрос

(например, на IP-адрес, ассоциированный с опре-

деленным доменным именем) DNS-серверу, а DNS-сервер возвращает ответ с за-

прошенной информацией (например, IP-адрес). Локальный DNS-сервер посылает

ответы преобразователям и выдает запросы другим DNS-серверам. Корневые DNS-

серверы посылают ответы на запросы других DNS-серверов, а сами не выдают за-

просы. Предположим, что приложение вызывает функцию

gethostbynameQ

для опре-

деления IP-адреса для www.foo.bar.com. Преобразователь связывается с локальным

DNS-сервером, который обращается к корневому DNS-серверу с целью узнать IP-ад-

рес DNS-сервера .com. Затем локальный DNS-сервер посылает запрос DNS-серверу

.com, чтобы узнать IP-адрес DNS-сервера bar.com, после этого локальный DNS-сер-

вер посылает запрос DNS-серверу зоны bar.com. Если зона имеет подзоны, то может

быть выдан дополнительный запрос домену foo.bar.com, который отвечает IP-адре-

сом для www.foo.bar.com. Аналогично, установление связи IP-адреса 12.34.56.78

с доменным именем сопровождается серией DNS-запросов к различным DNS-серве-

рам в иерархии in-arpa.

DNS-занрос может быть рекурсивным или

итеративным.

Рекурсивный запрос

требует, чтобы DNS-сервер, принимающий запрос, сам осуществил преобразование.

Например, преобразователь выдает рекурсивный запрос локальному серверу имен

на преобразование доменного имени в IP-адрес. Как показано на рис. 5.11, на этапе 1

преобразователь активизируется посредством системного вызова из приложения. За-

тем преобразователь направляет DNS-запрос локальному DNS-серверу (этап 2) и

ожидает ответа (этан 9). Локальный DNS-сервер осуществляет действия по обработ-

ке запроса преобразователя. Итеративный запрос требует, чтобы принимающий

DNS-сервер напрямую ответил DNS-клиепту IP-адресом следующего DNS-сервера

в иерархии DNS. Корневые серверы обслуживают только итеративные запросы. Ло-

кальный DNS-сервер посылает запрос корневому DNS-серверу (этап 3), чтобы уз-

нать имена и IP-адреса DNS-сервера (серверов) для зоны на следующем уровне

иерархии (этап 4). Это помогает разгрузить корневые серверы от выполнения пол-

ного процесса преобразования. Затем локальный DNS-сервер может отправить за-

прос следующему DNS-серверу в цепочке (этапы 5, 6, 7 и 8). Наконец, локальный

DNS-сервер отвечает преобразователю (этап 9), а преобразователь предоставляет

IP-адрес приложению (этап 10).

166

Часть III. Web-протоколы

Компьютер клиента

Web-браузер

\-f

DNS-

преобразователь

DNS-запрос

DNS-ответ

Кэш DNS

Локальный

DNS-сервер

Корневой сервер

^ Сервер домена

верхнего уровня

Сервер домена

второго уровня

Локальная сеть

Рис. 5.11. DNS-преобразоватсль и локальный DNS-ссрвср

DNS-серверы используют кэширование для уменьшения времени ожидания при

ответах на запросы и уменьшения DNS-трафика в Internet [DOK92J. Локальный

DNS-сервер имеет кэш, который храпит ответы, посылаемые преобразователям

клиентов. Кроме того, кэш может хранить IP-адреса каждого из DNS-серверов,

участвующих в обработке запроса. Для будущих запросов локальный DNS-сервер

может избежать взаимодействия с корневым сервером, обратившись вместо этого

к DNS-серверам первого или второго уровней напрямую, па основе кэшированпой

информации. Например, при преобразовании www.foo.com локалынлй DNS-сер-

вер может определить IP-адрес DNS-сервера верхнего уровня .com и DNS-сервера

второго уровня foo.com напрямую. Преобразователь не выполняет кэширование,

поскольку информация существует только во время работы приложения и не мо-

жет быть использована совместно другими приложениями, выполняющимися на

том же компьютере, или другими компьютерами в этой же сети.

DNS-сервер кэширует ответы па запросы, основываясь на поле TTL. Каждый

DNS-ответ содержит TTL, указывающий число секунд, в течение которых ответ

может быть кэширован. DNS-кэшировапие значительно сокращает время на преоб-

разование доменных имен в IP-адреса. Первый запрос на www.foo.com может со-

провождаться большим временем ожидания па соединение с корневым сервером и

сервером зоны, но последующие запросы будут обрабатываться непосредственно

локальным DNS-сервером. После истечения TTL информация удаляется из кэша и

вновь сохраняется в нем при получении другого запроса на преобразование

www.foo.com в IP-адрес. DNS-серверы также кэшируют негативную информацию

о неудачных запросах. Так, предположим, что пользователь сделал ошибку и ввел

URL http://www.boo.com вместо http://www.foo.com. Если www.boo.com не су-

ществует, локальный DNS-сервер получает негативный ответ па свой запрос и воз-

вращает сообщение об ошибке преобразователю. Локальный DNS-сервер помнит,

что запрос па www.boo.com был безуспешным, поэтому он может в дальнейшем

быстрее среагировать па ошибку.

DNS в основном использует протокол UDP для передачи запросов и получения

ответов, хотя может быть также использован протокол TCP. Применение UDP

дает возможность преобразователю и DNS-серверам взаимодействовать с помощью

однопакетпых сообщений без необходимости тратить ресурсы на установку соеди-

нений. Это очень полезно, поскольку большинство DNS-запросов и ответов явля-

ются очень короткими. Однако UDP-пакет может быть утерян в сети. Отправитель

DNS-запроса повторно передает запрос, если ответ не поступил по истечении неко-

торого времени. Если отсчет времени таймером завершается до получения ответа,

запрос выдается снова. TCP используется вместо UDP для более дли1Н1ых носы-

Глава 5. Протоколы, связанные с HTTP 167

лок. Например, организация может иметь вторичный DNS-сервер, который ис-

пользуется в качестве резервного в случае отказа первичного сервера. Вторичный

DNS-сервер должен иметь копию информации, доступной на первичном сервере.

TCP обычно применяется для копирования этих данных с первичного сервера па

вторичный сервер.

5.3.4. DNS-запросы и Web

Web-клиент вызывает gethostbynameQ, чтобы преобразовать доменное имя

в IP-адрес до установления соединения транспортного уровня с Web-сервером. На-

пример, предположим, что пользователь вводит URL http://www.foo.eom/a.html

в браузере. Если ресурс отсутствует в кэше браузера, браузер должен связаться

с Web-сервером. В некоторых случаях клиенту не требуется обращаться к DNS для

преобразования www.foo.com:

• Запрос, направляемый прокси-серверу. Клиент может быть настроен для от-

правки запросов прокси-серверу. Установка ТСР-соединепия с прокси-серве-

ром требует, чтобы клиенту был известен IP-адрес прокси-сервера, а не исход-

ного сервера. Если клиент настроен с указанием доменного имени прокси-сер-

вера, то вызов gethostbynameQ может стать необходимым для определения

IP-адреса прокси-сервера. Клиенту, который сконфигурирован с указанием

IP-адреса прокси-сервера, пет необходимости инициировать вызов gethost-

bynameQ.

• Запрос, удовлетворяемый из кэша клиента. Перед выдачей HTTP-запроса

клиент осуществляет поиск Web-pecypca в своем локальном кэше. Если

в кэше имеется актуальная копия запрашиваемого ресурса, клиенту нет нуж-

ды связываться с Web-сервером. В противном случае клиент должен связать-

ся с Web-сервером для проверки актуальности кэшировагнюго ресурса и, воз-

можно, загрузки нового ресурса с сервера.

• Использование результата предьщущего запроса. Клиент может загрузить не-

сколько ресурсов с одного и того же сервера. При обработке запроса па ресурс

http://www.foo.eom/a.html клиент определяет IP-адрес для www.foo.com.

Если Web-сграница имеет встроенные изображения, клиент может установить

дополнительные ТСР-соединепия с сервером для загрузки этих ресурсов. Что-

бы избежать повторных вызовов gethostbynameQ, клиент может воспользовать-

ся IP-адресом, нолучегптым при предыдущем вызове. Сохранение результатов

вызова gethostbynameQ отличается от DNS-кэшировапия на локальном DNS-

сервере, поскольку вызов gethostbynameQ не возвращает TTL, ассоциированный

с ответом на DNS-запрос. Чтобы уменьшить риск использования устаревшей

информации, Web-клиенту не следует хранить IP-адрес для www.foo.com

слишком долго (т.е. не более нескольких минут).

Web-клиент должен выяснить IP-адрес Web-сервера, Web-серверу IP-адрес кли-

ента становится известным при поступлении запроса, поскольку клиентский IP-ад-

рес содержится в заголовке каждого IP-пакета. Сервер может узнать доменное имя,

ассоциированное с этим IP-адресом, вызвав функцию gethostbyaddrQ. Знание домен-

ного имени клиента может быть полезно для различных применений, в том числе

регистрации, аутентификации и целевой рекламы. Например, запись доменного име-

ни в журнал сервера дает возможность администратору сайта определить, какие за-

просы поступили от пользователей из определенных организаций. Web-сервер мо-

жет также ограничивать доступ к определенным ресурсам, основываясь на доменном

168

Часть

III. Web-протоколы

имени обратившегося с запросом клиента. Или же сервер может настроить HTTP-

ответ на основе доменного имени клиента. Наиболее типичный пример такой на-

стройки

—

целевая реклама, при которой встроенные изображения на Web-cTpaiinue

выбираются на основе доменного имени клиента, обратившегося с запросом.

Установление соответствия между IP-адресом Web-клиента и доменным име-

нем осуществляется DNS-сервером в сети Web-клиента. У Web-клиента может

возникнуть соблазн неправильно указать свое доменное имя. Например, предполо-

жим, что Web-клиент имеет IP-адрес 10.34.56.78 и домегнюе имя a.badclient.com.

В то же время на локальном DNS-сервере Web-клиента IP-адресу 10.34.56.78 соот-

ветствует доменное имя b.goodclient.edu. Предоставление неверного доменного

имени может ввести в заблуждение Web-сервер, и он предоставит доступ не тому

клиенту. В качестве меры предосторожности Web-сервер может после вызова

gethostbyaddrQ вызвать gethostbynameQ. Вызов gethostbynameQ определяет IP-ад-

рес,

ассоциированный с b.goodclient.edu. В данном примере соответствие может

контролироваться другой организацией, что приведет к возврату другого IP-адреса,

скажем, 122.33.205.4. Узнав, что два IP-адреса отличаются друг от друга, Web-сер-

вер может отклонить HTTP-запрос.

Определение по IP-адресу клиента соответствующего доменного имени часто

сопровождается значительной задержкой. Вызов функции gethostbyaddrQ приво-

дит к запросу к локальному DNS-серверу Web-сервера. Этот DNS-сервер вряд ли

имеет информацию об IP-адресе клиента в своем кэше, если только клиент недавно

не посылал Web-запрос этому же Web-серверу. Следовательно, должен быть выдан

запрос к корневому серверу и к различным зональным серверам в домене in-

addr.arpa. Запрос может оказаться неудачным. Многие клиенты имеют динамиче-

ски выделяемые IP-адреса или IP-адреса, располагающиеся за корпоративным се-

тевым экраном. Эти адреса обычно не ассоциируются с доменными именами, по-

добные запросы приводят к задержкам в обходе DNS-иерархии и не возвращают

полезной информации. Даже если запрос был успешным, выполнение последующе-

го вызова gethostbynameQ для проверки корректности соответствия IP-адреса до-

менному имени приведет к увеличению времени ожидания.

Помимо прочего, DNS-запросы потребляют ресурсы Web-сервера. Процесс, вы-

зывающий функцию gethostbyaddrQ, должен ожидать, пока будет сформирован от-

вет. Это увеличивает продолжительность времени обработки HTTP-запроса, что,

в свою очередь, увеличивает число процессов, выполняющихся на сервере. Чтобы

избежать перегрузки, Web-сервер, одновременно обрабатывающий большое коли-

чество запросов, может пропускать этап преобразования IP-адреса клиента в до-

менное имя. В зависимости от конкретного Web-сайта, знание доменного имени

обратившегося с запросом клиента может быть и необязательным для корректной

работы сервера. Однако в некоторых случаях Web-сервер может осуществлять на-

стройку или аутентификацию на основе доменного имени клиента. Для достиже-

ния максимальной эффективности сервер может быть настроен таким образом,

чтобы ограничить применение функции gethostbyaddrQ только теми Web-запроса-

ми,

которые требуют эту информацию.

5.3.5. Выравнивание нагрузки на Web-серверы

с помощью DNS

DNS также играет важную роль в перенаправлении HTTP-запросов в группе

Web-серверов, которые предоставляют доступ к одному и тому же содержанию.

Хотя доменное имя обычно соответствует одному IP-адресу, достаточно активно

Глава

Протоколы,

связанные

HTTP

169

используемый 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-адрес в списке. Это приведет к большей загруженности HTTP-запросами

компьютера с 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-содержимого. Однако подоб-

ный подход не учитывает текущей нагрузки каждого из компьютеров и сети. Кроме

того,

он не учитывает расстояний между клиентским компьютером и каждой из ре-

плик. Расширения реализаций 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 не знает IP-адрес Web-клиента,

который отправил запрос локальному DNS-серверу. При выборе наилучшей реп-

лики Web-сайта DNS-сервер для www.big.com может предположить, что Web-