3.3 Описание протокола DNS
Служба Доменных Имен (Domain Name System) предназначена для того, чтобы машины, работающие в Internet, могли по доменному имени узнать IP-адрес нужной им машины, а также некоторую другую информацию; а по IP-номеру могли узнать доменное имя машины.
Служба Доменных Имен была разработана для именования машин в глобальной сети. Основной особенностью глобальной сети является распределенное администрирование, когда один администратор физически не может уследить за выделением имен. Поэтому Служба Доменных Имен функционирует на принципе делегирования полномочий. Каждая машина либо знает ответ на вопрос, либо знает кого спросить. При правильном функционировании система замкнута, т.е. если запрошенная информация имеется у кого-либо, то она будет найдена и сообщена клиенту, либо, если вопрос не имеет ответа, клиент получит сообщение о невозможности получения ответа на вопрос.
Каждый клиент знает своего сервера; обычно указывается не один, а несколько серверов - если первый не отвечает, клиент обращается ко второму и так далее до исчерпания списка. В принципе неважно, к какому серверу обращаться - они дают (должны давать при правильном функционировании) одинаковые ответы на любой запрос. Поэтому для ускорения работы обычно указывают ближайший. Следует помнить, что на одной машине могут функционировать одновременно Name-сервер и программы-клиенты; поэтому если на машине запущен Name-сервер, то в качестве Name-сервера на ней должен быть прописан "я сам".
Имеется некий домен верхнего уровня, обозначаемый точкой: ".". Имеется девять серверов (по крайней мере на моем Name-сервере записано столько), которые отвечают за эту зону. Они не знают ни одного доменного имени - они только авторизуют серверы верхних зон. Серверы верхних зон тоже гнушаются хранить информацию о конкретных машинах и передают это право нижележащим серверам. Тут уже появляются первые упоминания о конкретных машинах, равно как и происходит авторизация нижележащих серверов.
Очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко.
Допустим, клиент запросил адрес "www.организация.город.страна". Поиск информации по доменному имени происходит следующим образом:
Клиент спрашивает своего сервера.
Если тот является сервером данной зоны, то ответит, на чем все заканчивается.
Сервер спрашивает корневой сервер.
Тот не может ответить, потому что не знает; зато знает, какой сервер отвечают за зону "страна".
Сервер зоны "страна" тоже не может ответить, но знает, что нужно спросить сервер зоны "город.страна".
Тот в свою очередь отсылает запрос серверу зоны "организация.город.страна", который сообщит нужную информацию.
Это приближенная модель, которая тем не менее позволяет представить работу системы DNS.
Однако эту стройную картину искажают системы кэширования и вторичных серверов. Дело в том, что получив ответ на свой вопрос, DNS-сервер получает также некоторое число, которое говорит ему о том, по истечении какого времени эта информация должна считаться устаревшей. Таким образом, все серверы, участвовавшие в поиске ответа на вопрос, заданный клиентом, могут (и скорее всего будут) помнить как ответ на заданный вопрос, так и путь, по которому шел поиск. При следующих запросах, имеющих общую правую часть с недавно сделанными запросами, поиск будет упрощен (ускорен).
Следует обратить внимание на сходство, различие и взаимодействие систем DNS и IP-маршрутизации. Как и IP-маршрутизация, DNS работает по принципу делегирования полномочий, но выделение доменных имен совершенно не зависит от выделения IP-адресов. Для примера рассмотрим домен freebsd.org. Это - домен организации, занимающейся распространением операционной системы FreeBSD Unix. FTP-сервер, содержащий дистрибутив операционной системы и множества утилит для нее, имеет копии в нескольких десятках стран.
Политика и стратегия назначения имен
Имена зон условно можно разделить на "организационные" и "географические". В высшей зоне зарегистрированы следующие "организационные" зоны:
com - commercial (коммерческие);
edu - educational (образовательные);
gov - goverment (правительственные);
mil - military (военные);
net - network (организации, обеспечивающие работу сети);
org - organization (некоммерческие организации).
3.4 Протокол NFS
Система NFS обеспечивает разнообразным приложениям на клиентских хостах прозрачный доступ к файловым системам и файлам на сервере. Слово доступ здесь означает, что становятся доступными разнообразные операции с отдельными частями содержимого файлов (а не только копирование файлов целиком с помощью специализированного клиента подобно тому, как это происходит при пересылке файлов в FTP). Предоставляемый доступ является прозрачным в том смысле, что каждое приложение на клиентской машине, работающее с локальными файлами, точно так же работает через NFS и с файлами на удаленной системе, причем без каких-либо изменений в коде этого приложения.
Система NFS построена по принципу клиент-сервер и базируется на RPC фирмы Sun Microsystems. NFS-клиент получает доступ к файлам на хосте NFS-сервера, посылая ему RPC-запросы. С принципиальной точки зрения NFS-клиент и NFS-сервер могли бы быть обычными пользовательскими процессами, взаимодействующими через RPC, однако из практических соображений NFS обычно реализуют иначе, и на это есть две причины. С одной стороны, как было сказано, доступ к файлам с помощью NFS должен быть прозрачным для любых приложений на стороне клиента. Следовательно, все обеспечивающие удаленную работу с файлами NFS-запросы с клиентской машины должны автоматически генерироваться операционной системой. С другой стороны, высокая производительность NFS-сервера достигается, только если он функционирует как часть операционной системы на его хосте. Если бы NFS-сервер был реализован как пользовательский процесс, то обращения сервера с запросом к файловой системе вместе с записываемыми и считываемыми данными в каждой транзакции пересекали бы границу между ядром и этим пользовательским процессом, что неизбежно повлекло бы значительные издержки и резко снизило производительность. Поэтому NFS-серверы реализуют в коде ядра.
1. Для пользовательского приложения скрыто, обращается он к местному файлу или через NFS к файлу на удаленном хосте (далее последние будем кратко называть NFS-файлами). За него это знает ядро: в момент открытия файла оно определяет его местонахождение и в зависимости от этого в последующем все обращения к местным файлам отдает на обработку своей файловой системе, а те, что относятся к дальним файлам, направляет NFS-клиенту.
2. NFS-клиент посылает RFC-запросы на NFS-сервер через используемый транспортный протокол. Большей частью NFS работает по UDP, но последние реализации могут быть конфигурированы на установление соединений по TCP.
3. NFS-сервер принимает дейтаграммы с запросами NFS-клиента на свой UDP-порт 2049. Хотя, в принципе, NFS-сервер мог бы использовать эфемерный порт, объявляя его на регистраторе портов, в большинстве реализаций NFS зафиксирован стандартный порт 2049.
4. При поступлении запроса от NFS-клиента NFS-сервер транслирует его в запросы к своей местной файловой системе, которая и осуществляет соответствующие действия на диске хоста сервера.
5. Обработка запроса на сервере может занять значительное время, особенно если потребуется выполнить манипуляции в его файловой системе. Чтобы в период выполнения одного запроса не блокировать запросы от других NFS-клиентов, NFS-сервер должен обрабатывать их параллельно. Способ параллельной обработки зависит от возможностей конкретной операционной системы. Поскольку большинство реализаций Unix не поддерживают механизм нитей (multithreading), то обычно используемый искусственный прием состоит в следующем. Запросы от клиента на стороне сервера обрабатывает пользовательский процесс, называемый демоном. NFS (обычное его имя — nf sd), который может сам себя копировать в некотором числе экземпляров. Эта простейшая программа посылает один не требующий ответа вызов в код встроенного в ядро NFS-сервера.
6. В свою очередь, и NFS-клиент, обслуживающий свой пользовательский процесс, вынужден, выслав RPC-запрос, в течение достаточно длительного времени ждать завершения его обработки на сервере до получения RPC-ответа. Поэтому и на клиентском хосте необходимо так или иначе обеспечить параллельное обслуживание многих использующих NFS пользовательских процессов, что также решается различными способами в зависимости от операционной системы. В Unix на хосте клиента NFS часто используется тот же прием, что и в случае сервера: создается новая копия пользовательского процесса, называемого здесь демоном блочного ввода-вывода (biod), который посылает один не требующий ответа вызов в код встроенного в ядро NFS-клиента.
Большинство хостов в Unix поддерживают либо NFS-клиента, либо NFS-сервера, либо обоих одновременно. Реализации NFS-клиентов существуют и для персональных компьютеров с операционными системами, например, от Microsoft. Мэйнфреймы, в частности фирмы IBM, часто выполняют роль только NFS-сервера.
В системе NFS на стороне сервера кроме программы, реализующей собственно сам протокол NFS, действуют еще и другие работающие поверх RPC программы, включая непременный для RPC регистратор портов.
Та или иная файловая система NFS-сервера становится доступной с машины NFS-клиента только после того, как будет на ней должным образом смонтирована. Для этого NFS-клиент обращается с соответствующим запросом к демону монтирования (mount daemon) NFS-сервера. Сам протокол монтирования в NFS будет рассмотрен ниже.
Менеджер блокировок (lock manager) и монитор состояний (status monitor) позволяют блокировать фрагменты файлов на сервере. Эти две программы необходимы как отдельные дополнения к протоколу NFS, поскольку для временной блокировки обращений к частям файла при их модификации необходимо, чтобы клиент и сервер могли из одного состояния переходить в другое. (Протоколом NFS не предусмотрено запоминание состояний на стороне сервера).
3.5 Выводы по разделу
В данном разделе были рассмотрены алгоритмы функционирования автоматизированной информационной системы, а также детально рассмотрены протоколы используемые системой для настройки и конфигурирования серверного программного обеспечения.
0 комментариев