Внутреннее устройство Linux - Уорд Брайан. Страница 70

9.12.3. Кэширование и службы DNS без конфигурирования

Традиционная конфигурация службы DNS имеет две основные проблемы. Во-первых, локальный компьютер не кэширует имя, которое возвращает сервер, поэтому частый повторяющийся доступ к сети может неоправданно замедлиться вследствие запросов к серверу имен. Чтобы справиться с этой проблемой, многие компьютеры (и маршрутизаторы, если они работают в качестве серверов имен) запускают промежуточный демон, чтобы перехватывать запросы к серверу имен и возвращать на них, если это возможно, кэшированный ответ. В противном случае запросы отправляются на реальный сервер имен. Два наиболее распространенных демона Linux для этой цели — dnsmasq и nscd. Можно также настроить демон BIND (стандартный демон сервера имена в Unix) в качестве кэша. Часто можно понять, запущен ли демон кэширования имен, если в файле конфигурации /etc/resolv.conf присутствует адрес 127.0.0.1 (localhost) или же в качестве имени сервера отображается 127.0.0.1, когда вы запускаете команду nslookup -debug host.

Может оказаться непросто выяснить конфигурацию, если вы используете демон кэширования имен. По умолчанию для демона dnsmasq применяется файл конфигурации /etc/dnsmasq.conf, но в вашей версии системы это может быть переопределено. Например, в Ubuntu, если вы вручную настроили интерфейс, который управляется менеджером NetworkManager, вы найдете его конфигурацию в соответствующем файле каталога /etc/NetworkManager/system-connections, поскольку менеджер NetworkManager при активизации соединения запускает также и демон dnsmasq с данной конфигурацией. Можно переопределить все это, если снять комментарии с записи в файле NetworkManager.conf, относящейся к демону dnsmasq.

Другой проблемой, связанной с традиционным устройством сервера имен, является то, что оно может оказаться чрезвычайно негибким, когда вам потребуется выяснить имена в вашей локальной сети, не вникая в детали сетевой конфигурации. Если, например, вы настраиваете сетевое устройство в своей сети, вам может понадобиться немедленно вызвать его по имени. Это часть идеи, которая заложена в такие службы имен, не требующие конфигурации, как mDNS (Multicast DNS, многоадресная служба DNS) и SSDP (Simple Service Discovery Protocol, простой протокол обнаружения службы). Если необходимо найти в локальной сети хост по его имени, то вы просто рассылаете запрос по этой сети; если требуемый хост в ней присут­ствует, то он возвращает в ответ свой адрес. Эти протоколы выходят за рамки разрешения имени хоста, предоставляя также информацию о доступных службах.

Наиболее широко используемая реализация mDNS для Linux называется Avahi. Вариант mdns часто указывается в качестве функции разрешения имен в файле /etc/nsswitch.conf, который мы сейчас рассмотрим более подробно.

9.12.4. Файл /etc/nsswitch.conf

Файл /etc/nsswitch.conf контролирует параметры старшинства, связанные с именами, такие как информация о пользователе и пароле. Однако мы будем говорить в данной главе лишь о параметрах DNS. В этом файле должна быть строка, подобная следующей:

hosts:        files dns

Параметр files помещен перед параметром dns, чтобы система искала запрашиваемый вами IP-адрес в файле /etc/hosts, прежде чем обратиться к серверу DNS. Обычно такой способ хорош (особенно при отыскании локального хоста, как описано ниже), но при этом файл /etc/hosts должен быть по возможности коротким. Не помещайте в него ничего для улучшения производительности, это только навредит вам впоследствии. Можно поместить данные о всех хостах небольшой част­ной локальной сети в файл /etc/hosts, однако общее правило здесь таково: если у какого-либо хоста есть запись в службе DNS, его не следует указывать в файле /etc/hosts. Файл /etc/hosts полезен также для разрешения имен на ранних этапах загрузки системы, когда сеть может оказаться недоступной.

примечание

Тема, посвященная DNS, достаточно обширна. Если вы каким-либо образом ответственны за доменные имена, прочитайте книгу Крикета Лиу (Cricket Liu) и Пола Альбитца (Paul Albitz) DNS and BIND («Службы DNS и BIND»), 5-е издание (O’Reilly, 2006).

9.13. Локальный хост

Если запустить команду ifconfig, можно заметить интерфейс lo:

lo       Link encap:Local Loopback

         inet addr:127.0.0.1 Mask:255.0.0.0

         inet6 addr: ::1/128 Scope:Host

         UP LOOPBACK RUNNING MTU:16436 Metric:1

Интерфейс lo является виртуальным сетевым интерфейсом, который называется возвратной петлей, поскольку он «закольцован» сам на себя. Результат таков, что при подключении к адресу 127.0.0.1 происходит подключение к компьютеру, которым вы пользуетесь в данный момент. Когда исходящие данные для локального хоста доходят до сетевого интерфейса lo в ядре, ядро просто заново упаковывает их как входящие данные и отправляет обратно через интерфейс lo.

Интерфейс возвратной петли lo часто является единственным местом, где можно увидеть статическую сетевую конфигурацию в сценариях загрузки системы. Так, например, команда ifup в Ubuntu читает файл /etc/network/interfaces, а в Fedora используется файл /etc/sysconfig/network-interfaces/ifcfg-lo. Часто можно обнаружить конфигурацию какого-либо устройства с возвратной петлей, если поискать в каталоге /etc с помощью команды grep.

9.14. Транспортный уровень: протоколы TCP, UDP и службы

До сих пор мы видели лишь то, как пакеты перемещаются от хоста к хосту по сети Интернет, другими словами, ответ на вопрос «куда?» из начала этой главы. Теперь начнем отвечать на вопрос «что?». Важно знать, как ваш компьютер представляет данные пакета, которые он получает от других хостов, своим работа­ющим процессам. Для команд из пространства пользователя трудно и неудобно иметь дело с набором пакетов таким образом, как с ними может работать ядро. В особенности важна гибкость: сразу несколько приложений должны иметь возможность одновременного обращения к сети (например, вам может потребоваться запустить почтовый клиент и браузер).

Протоколы транспортного уровня заполняют разрыв между необработанными пакетами интернет-уровня и «рафинированными» потребностями приложений. Двумя самыми популярными транспортными протоколами являются TCP (Transmission Control Protocol, протокол управления передачей) и UDP (User Datagram Protocol, протокол передачи дейтаграмм пользователя). Мы сосредоточимся на протоколе TCP, так как он безоговорочно является наиболее используемым, и вкратце рассмо­трим и протокол UDP.

9.14.1. Порты TCP и соединения

Протокол TCP предоставляется нескольким сетевым приложениям на одном компьютере с помощью сетевых портов. Порт — это просто число. Если IP-адрес можно уподобить почтовому индексу какого-либо жилого дома, то порт похож на номер почтового ящика: это дальнейшее деление на более мелкие части.

При использовании протокола TCP приложение открывает соединение (не смешивайте с подключениями в менеджере NetworkManager) между одним из портов данного компьютера и каким-либо портом удаленного хоста. Например, такое приложение, как браузер, могло бы открыть соединение между портом 36406 компьютера и портом 80 удаленного хоста. С точки зрения приложения порт 36406 является локальным портом, а порт 80 — удаленным портом.

Можно идентифицировать соединение с помощью пары, составленной из IP-адреса и номера порта. Чтобы увидеть соединения, которые в данный момент открыты на компьютере, воспользуйтесь командой netstat. Приведем пример, в котором показаны TCP-соединения (параметр -n отключает разрешение имен (DNS), а параметр -t ограничивает результаты только протоколом TCP):

$ netstat -nt

Active Internet connections (w/o servers)

Proto Recv-Q Send-Q Local Address         Foreign Address         State