Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

• Название: TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
• Автор: Сидни Фейт
• Издательство: Лори
• Жанр: Программное обеспечение
• Год: 2000
• ISBN: 5-85582-072-6

 Второе издание популярного справочника полностью переработано и расширено с целью предоставить читателю наиболее полное описание средств разработки, конфигурирования, использования и обслуживания сетей TCP/IP и соответствующих служб.

Книга написана увлекательно и доступно. Она содержит дополнительные материалы о нескольких протоколах Интернета, используемых серверами и браузерами WWW, а также рассматривает все последние изменения в этой области. В книгу включены главы о новом стандарте безопасности IP и протоколе IP следующего поколения, известном как IPng или IPv6. Рисунки и таблицы наглядно показывают влияние средств безопасности IP и IPng на существующие сетевые среды.

Издание содержит следующие дополнительные разделы:

• Безопасность IP и IPv6

• Описание средств WWW, новостей Интернета и приложений для работы с gopher

• Подробное описание серверов имен доменов (DNS), маски подсети и бесклассовой маршрутизации в Интернете

• Таблицы и протоколы маршрутизации

• Руководство по реализации средств безопасности для каждого из протоколов и приложений

• Примеры диалогов с новыми графическими инструментами

Новое издание бестселлера по TCP/IP станет незаменимым помощником для разработчиков сетей и приложений, для сетевых администраторов и конечных пользователей.

---

15.17.3 Специальные утилиты

В идеале NFS должна быть прозрачна для пользователей. Файлы сервера должны открываться, читаться, записываться и закрываться так же, как локальные файлы, а применяться для этого должны обычные локальные команды.

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

Когда клиент DOS обращается к файловому серверу Unix, создаваемые и именуемые клиентом файлы должны соответствовать требованиям DOS и являться реальной частью клиентской файловой системы.

Когда клиенту DOS нужно прочитать текстовый файл, созданный в Unix, возникает несколько проблем. Прежде всего, имена файлов в DOS ограничены 8-ю символами, а далее следуют необязательные точка и еще 3 или меньше символов (расширение имени файла). В DOS все имена файлов принято записывать символами верхнего регистра. Например: COMMAND.COM. Имена файлов в Unix могут быть гораздо длиннее и состоять из символов верхнего и нижнего регистров. Например, в Unix вполне допустимо имя aLongerName.More.

Как же пользователь DOS получит доступ к такому файлу? Обычно разработчики реализуют автоматическую трансляцию имен или включают специальные утилиты, разрешающие пользователям указывать исходные имена файлов на сервере. (Более распространена эмуляция на клиентском компьютере операционной системы сервера — тогда при доступе к файлам можно не только использовать родные соглашения об именовании файлов, но и применять родные команды операционной системы для обработки этих файлов; когда же возникает необходимость в переносе файла из одной операционной системы в другую, применяются специальные программы-конвертеры. — Прим. пер.)

Однако существуют и другие проблемы. Строки текстовых файлов DOS завершаются символами возврата каретки (CR) и перевода строки (LF), в то время как в Unix применяется только LF. Некоторые разработчики реализуют автоматическую трансляцию на основе специальных утилит преобразования к локальному формату.

15.17.4 Блокировка файлов

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

Блокировка файлов в NFS реализуется двумя службами: диспетчером блокировки (lock manager) и программой статуса (status). Диспетчер блокировки управляет клиентскими запросами на блокировку файлов. Программа status на сервере отслеживает текущие блокировки, выполняемые клиентскими хостами. При крахе сервера программа статуса отсылает уведомление зарегистрированным клиентским хостам, запрашивая от них снятие блокировок файлов.

15.17.5 Заметки о реализациях NFS

Программа может постоянно запрашивать от своей операционной системы чтение или запись небольшого числа байт. Постоянный доступ к жесткому диску за небольшим количеством данных крайне неэффективен. Обычно операционная система проводит упреждающее чтение целого блока данных и отвечает на запрос, используя данные из собственной памяти. Аналогичным образом производится кеширование данных при записи на жесткий диск.

Частый доступ к удаленному серверу NFS за небольшим количеством данных еще более неэффективен, чем доступ к локальному жесткому диску. Клиентские реализации NFS тоже выполняют упреждающее чтение блоков данных.

Сервер NFS может существенно повысить производительность, сохраняя в памяти информацию о каталогах и атрибутах файлов, равно как и выполняя упреждающее чтение запрашиваемой клиентом информации. В NFS версии 3 поддерживается запись в кеш с фиксацией (commit) содержимого кеша на устройстве постоянного хранения.

15.17.6 Мониторинг NFS

Команда nfsstat из Unix выводит сведения о действиях NFS. Подобные команды доступны и в других операционных системах. В представленном ниже примере локальная система работает и как сервер, и как клиент. Ее деятельность в качестве сервера почти незаметна. Однако пользователи системы формируют большое число клиентских запросов.

В отчете команды показано количество использований запросов каждого типа за период мониторинга. Видно множество операций просмотра (lookups), что связано с последовательным, пошаговым получением описателей файлов при движении вниз по дереву каталогов.

> ntsstat

Server rpc:

Calls    badcalls nullrecv badlen xdrcall

25162314    0         0       0      0

Server nfs:

Calls    badcalls

25162314  491

Null   getattr     setattr   root lookup      readlink

478 0% 9689121 38% 380591 1% 0 0% 5596396 22% 5992775 23%

read

1009813 4%

Wrcache write      create    remove   rename   link    symlink

0 0%    1146142 4% 627381 2% 66180 0% 13089 0% 6042 0% 265 0%

Mkdir   rmdir readdir   fsstat

1718 0% 66 0% 626437 2% 5820 0%

Client rpc:

Calls   badcalls retrans badxid timeout wait newcred timers

3931394 2069       0      42    2037     0      0    1697

Client nfs:

Calls   badcalls nclget  nclsleep

3929178   32     3929357    0

Null getattr     setattr root lookup      readlink

0 0% 2221718 56% 6689 0% 0 0% 1423702 36% 93498 2%

Read     wrcache write    create  remove  rename

54110 1% 0 0%    19501 0% 7362 0% 6493 0% 158 0%

Link symlink mkdir rmdir readdir  fsstat

5 0% 0 0%    28 0% 12 0% 95804 2% 98 0%

15.18 Дополнительная литература

На момент выхода книги portmapper и RPCBIND были определены в RFC 1833, протокол Remote Procedure Call версии 2 в RFC 1831, a XDR в RFC 1832.

Версия 2 системы NFS рассматривается в RFC 1094, а версия 3 описана в RFC 1813. Очень полная спецификация версии 2 системы NFS приведена в X/Open CAE Specification: Protocols for X/Open Internetworking: XNFS, опубликованной X/Open Company, Ltd.

Глава 16 Электронная почта

16.1 Введение

Среди всех приложений TCP/IP наибольшей популярностью пользуется электронная почта (далее мы будем называть ее для краткости просто почтой. — Прим. пер.). Когда в организации появляется хороший доступ к почтовой службе, всегда резко увеличивается число пользователей сети — ведь почтовые программы могут успешно применять даже люди, ранее и не мечтавшие использовать компьютер в своей работе.

Электронная почта обеспечивает простой и удобный способ обмена сообщениями между людьми. Показанный ниже диалог представляет взаимодействие с одной из базовых почтовых программ Unix. Программа выводит подсказку Subject (тема сообщения), и далее можно вводить сам текст сообщения. Ввод будет завершен после набора символа точки как единственного символа строки.

> mail fred

Subject: New Materials

The manuals have arrived.

Let's discuss them next week.

.

Существуют более элегантные почтовые программы, имеющие полноэкранный пользовательский интерфейс и операции с мышью. Например, на рис. 16.1 показан интерфейс почтовой программы Chameleon для Windows, а на рис. 16.2 — Eudora для Macintosh.

Рис. 16.1. Пользовательский интерфейс для Windows

Рис. 16.2. Пользовательский интерфейс программы Eudora для Macintosh

Формальным названием почтовой программы для конечного пользователя является "пользовательский агент" (User Agent — UA). Этот агент должен обеспечивать несколько возможностей:

■ Вывод информации о поступивших почтовых сообщениях, сохраненных в почтовом ящике (mailbox)

■ Сохранение входящих и исходящих сообщений в папке или локальном файле

■ Обеспечение хороших средств редактирования для ввода текста сообщений

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

Вернемся к рассмотренному выше примеру. Диалог выглядит очень простым, однако остается большой объем работы. Введенное имя "fred" является кратким именем (nickname) или псевдонимом (alias), который определен в адресной книге пользователя. Когда пользовательский агент просматривает адресную книгу, он по указанному псевдониму извлекает из нее реальный идентификатор получателя сообщения (например, [e-mail]).

Такой идентификатор имеет общий для почты Интернета формат. Однако существует лицензионное программное обеспечение для почты и ее служб, предоставляющее различные варианты для формата адреса получателя. Согласование форматов происходит на почтовых шлюзах (mail gateways).