При использовании в сети TCP/IP существует вероятность, что в сети применяется DHCP для раздачи IP-адресов клиентским машинам и, возможно, некоторым принтерам. Нечего и говорить, что если TCP/IP является единственным протоколом в сети, то клиентская машина должна иметь допустимый IP-адрес, чтобы общаться с другими устройствами в сети, например компьютерами, маршрутизаторами, принтерами и серверами. Этот IP-адрес должен иметь подходящий сетевой адрес, адрес хоста и маску подсети, иначе коммуникация просто не будет происходить. Если имеется несколько сегментов, то требуется также используемый по умолчанию шлюз.
DHCP может управлять этими простыми задачами, и даже сделать больше. В действительности это четкий и эффективный протокол, которому требуются только четыре кадра для выдачи адреса и два кадра для обновления этого адреса позже. Рассмотрим это подробнее.
Процесс получения адреса Когда загружается клиент DHCP, первое что он должен сделать, это найти сервер DHCP, выдающий IP-адреса для подсети, к которой он присоединен. Для этого устройство пошлет сообщение поиска DHCP, указывающее, что оно хотело бы получить IP-адрес. Сервер DHCP, получив сообщение поиска, ответит предложением DHCP. Оно говорит: "Я получил ваш запрос и вот адрес, который у меня есть". Клиентская машина может получить несколько предложений DHCP от нескольких серверов, которые могут услышать сообщение поиска DHCP. Клиент выберет первое полученное им предложение DHCP и ответит серверу DHCP, что он хочет получить предложенный IP-адрес. Это называется запросом DHCP. Сервер DHCP при получении запроса ответит подтверждением (АСК): "Можете начинать использовать IP-адрес". Таблица резюмирует этот процесс.
Как можно видеть в таблице, DHCP использует широковещание в течение всего процесса. Это позволяет другим машинам в сети знать о том, что происходит. Рассмотрим этот процесс подробнее. В приведенной ниже распечатке заголовка Ethernet можно видеть, что адресом назначения является FFFFFFFFFFFF. Это широковещательный адрес для уровня доступа к среде передачи. Все устройства в сегменте Ethernet должны будут обрабатывать этот кадр, пока не дойдут до раздела UDP (порта дейтаграмм пользователя) и не обнаружат, что они не имеют указанного порта UDP. В распечатке также видно, что размер кадра Ethernet равен 342 байтам. Это размер данного кадра Ethernet, включая заголовок. Число остающихся байтов равно 328, что является полезной нагрузкой минус 14-байтовый заголовок Ethernet.
Получив подходящий IP-адрес, клиентский компьютер должен зарегистрировать в сети свое имя NetBIOS. В большинстве ситуаций эта регистрация будет вовлекать WINS. Большинство ресурсов, доступных в сети, включает некоторый вид компьютерного имени. Компьютеры в сети должны регистрировать по крайней мере одно имя. Как правило они будут регистрировать более одного имени, чтобы обеспечить в сети коммуникацию по имени. В мире Windows NT имя хоста и имя NetBIOS обычно совпадают (они не являются одним и тем же по сути, но обозначаются одним и тем же словом или комбинацией символов). В мире Unix имя хоста и имя NetBIOS могут быть различаться.
В главе 1 говорилось, что NetBIOS (сетевая базовая система ввода-вывода) не то же самое, что NetBEUI. NetBIOS является протоколом, используемым различными приложениями. Он может переноситься через TCP/IP, IPX/SPX и, конечно, NetBEUI. Мы рассмотрим NetBIOS, потому что она используется через TCP/IP.
Чтобы приложения могли общаться, имя NetBIOS должно быть преобразовано в адрес IP. Способ, которым это обычно делается, состоит в испо льзовании либо широковещания b-узлов, либо сервера имен NetBIOS, например WINS. Есть несколько преимуществ использования сервера WINS, а не просто широковещания. Первое состоит в том, что широковещание является очень дорогим предложением, когда речь идет о сетевой производительности. Каждое одиночное устройство в сегменте должно остановить и проверить каждый одиночный кадр широковещания, чтобы определить, не может ли он обслужить запрос. В большой сети широковещание NetBIOS может буквально заполнить всю сеть. С этим надо как-то бороться. К счастью, компания Microsoft разработала для этой цели WINS. WINS полностью соответствует реализации сервера имен NetBIOS на основе RFC. С помощью WINS хосты могут отбрасывать кадр, как только они видят адрес MAC места назначения. Все функции службы имен NetBIOS через TCP/IP используют UDP порт 137. Рассмотрим регистрацию имен и процесс обновления.
Регистрация имен и обновление
Имена NetBIOS должны быть зарегистрированы для каждой службы или приложения, которые хотят использовать их коммуникационный механизм. Примерами таких регистрируемых служб являются служба рабочей станции и служба сервера. Другие имена указывают специальные роли, которые выполняются в сети, такие как основной, или первичный, контроллер домена (Primary Domain Controller, PDC) или резервный контроллер домена (Backup Domain Controller, BDC). Регистрируется само имя домена, а также имена пользователей, регистрирующихся в домене. Эти имена нужны для некоторых функций сообщений и коммуникации. Например, если необходимо послать сообщение, используя сетевую команду send (послать) некому Джейсону, он должен иметь зарегистрированное имя пользователя, иначе ничего не получится. Общее число зарегистрированных имен зависит, очевидно, от числа запущенных служб. Каждое зарегистрированное имя будет использовать всего 214 байтов — 110 байтов для запроса регистрации имени и 104 байта для ответа. Посмотрим теперь на такую транзакцию на листинге ниже:
Хотя автор предполагает, что читатели знакомы с концепцией просмотра, необходимо рассмотреть несколько терминов, чтобы убедиться, что речь идет об одном и том же. В системе просмотра есть пять ролей просмотра. При чтении следующего далее списка помните, что один компьютер может выполнять более одной роли. Компьютер, выполняющий любую из этих ролей, называется броузером (browser).
1. Мастер-броузер домена. Это всегда основной контроллер домена. Он отвечает за сбор объявлений для всего домена, включая все подсети сети TCP и сетевые сегменты. Когда этот список собран, мастер-броузер домена предоставляет список ресурсов всем мастер-броузерам в сети. Мастер-броузер домена может также быть мастер-броузером для своего сегмента.
2. Мастер-броузер. Мастер-броузер отвечает за сбор информации для создания и поддержания списка просмотра, который включает все серверы в домене или рабочей группе мастер-броузера, а также все домены в сети. Сервер будет делать объявление сервера для мастер-броузера домена или рабочей группы, посылая направленную дейтаграмму. Это объявление сервера перечисляет все доступные на компьютере службы, и поэтому, помимо серверов NT, такие серверные объявления будут также делаться рабочими станциями NT, машинами Windows 9.x и компьютерами Windows for Workgroup, которые предоставляют какую-либо форму совместного использования файлов и печати. Мастер-броузер получает это объявление и добавляет компьютер в список просмотра. Если домен включает более одной подсети TCP, то мастер-броузер будет отвечать только за свой сегмент, но будет поддерживать также список резервных броузеров локальной подсети.
3. Резервный броузер. Резервный броузер получает копию списка просмотра от мастер-броузера и передает список по запросу компьютерам в домене. Все контроллеры домена автоматически конфигурируются либо как мастер-броузер, либо как резервный броузер. Рабочие станции Windows NT, компьютеры Windows 9.x и Windows for Workgroup могут быть резервными броузерами, если в домене существует меньше трех серверов NT, выполняющих функции резервного броузера. Резервные броузеры вызывают мастер-броузер каждые 15 минут, чтобы получить самую последнюю копию списка просмотра, а также текущий список доменов в сети. Если мастерброузер недоступен, то резервный броузер будет инициировать выборы.
4. Потенциальный броузер. Потенциальным броузером является компьютер, который может поддерживать список просмотра сетевых ресурсов, но еще не имеет списка. Он будет поддерживать список просмотра только в том случае, если мастер-броузер прикажет это делать. В этом случае потенциальный броузер становится резервным.
5. Не-броузер. He-броузер может быть специально сконфигурирован так, чтобы не поддерживать список просмотра. Не будучи сконфигурирован как не-броузер, компьютер будет потенциальным броузером, если он имеет активные серверные компоненты.
Рассмотрим теперь некоторые трассировки, показывающие, как работает почта SMTP в реальной жизни. Для создания соединения SMTP с Exchange требуется пять кадров и 420 байтов. Это включает трехходовое квитирование, кадр готовности службы SMTP и еще один кадр подтверждения (АСК). Посмотрим на кадр готовности службы на распечатке ниже. Код ответа 220, как мы знаем из таблицы, означает, что служба готова. Этот кадр поступает из порта 25, который используется для службы SMTP. Код 220 посылается как стандартный код ASCII и показан в шестнадцатеричной панели как 32 32 30. Символ ASCII для 20 равен 50 и преобразуется в шестнадцатеричное 32. Символ ASCII для 0 равен 48 и преобразуется в шестнадцатеричное 30.
Хотя TCP является дуплексным протоколом, SMTP действует только в полудуплексном режиме. Это означает, что посылаемый символ должен быть подтвержден перед посылкой следующего символа. Это требование создает большой объем трафика подтверждения (АСК). Например, просто отправка команды HELO требует 11 кадров и 695 байтов. Когда посылается и подтверждается HELO, следующий кадр с клиентской машины посылает 0D OA (ASCII 13, возврат каретки, и ASCII 10, перевод строки), как видно на распечатке ниже.
Протокол РОРЗ используется как упрощенный протокол почты, который хранит сообщения на сервере, пока клиентская машина не соединится и не выгрузит их по запросу. Он делает не слишком много по обработке сообщения на сервере; служба РОРЗ просто слушает порт TCP 110, пока почта не будет извлечена, и удаляет ее из почтового хранилища. Это не очень развитый протокол, но он достаточно эффективен.
Когда клиент РОРЗ хочет создать соединение, он следует схеме одиночных рабочих команд. Подобно протоколу SMTP, который был рассмотрен ранее, команды состоят из символов ASCII, разделенных пробелами. Эти команды имеют длину в три или четыре символа. Модификаторы для команд РОРЗ могут быть до 40 символов длиной.
Сервер РОРЗ дает два типа ответов. Первый ответ является положительным. Отрицательным ответом является -ERR. Оба эти ответа должны быть представлены заглавными буквами и содержать либо знак -, либо знак +.
Некоторые команды будут создавать многострочный ответ с сервера (например, команда list), и каждая строка будет заканчиваться комбинацией возврата каретки и перевода строки (та же самая комбинация ASCII 13 и ASCII 10 использовалась в протоколе SMTP). Когда все строки будут посланы, сервер пошлет . (ASCII 46) и дополнительный перевод строки. Это та же комбинация <RLF>.[T04Ka]<RLF>, которую мы видели в протоколе SMTP.
Четыре состояния РОРЗ Во время процесса соединения клиента и получения почты РОРЗ проходит через четыре состояния. После начального соединения TCP и последующего приветствия сервер входит в состояние авторизации, в котором клиент идентифицирует себя. Вслед за состоянием авторизации РОРЗ входит в состояние транзакции и получает команды с клиентской машины для обработки почты. После успешной обработки почты и отправки клиентом команды завершения quit сеанс входит в фазу обновления и освобождает ресурсы, использованные во время состояния транзакции. Затем соединение TCP закрывается. Эта последовательность событий для успешного сеанса подробно описана в следующем списке.
1. Клиентская машина запрашивает у DNS адрес.
2. Когда адрес получен, машина инициирует трехходовое квитирование на порте 110.
3. Вслед за трехходовым квитированием сервер посылает приветствие.
4. Клиент отвечает именем пользователя.
5. Сервер проверяет, существует ли пользователь в системе, и отвечает с помощью +ОК.
6. Клиент отвечает паролем.
7. Сервер отвечает +ОК.
8. Клиент запрашивает состояние почтового ящика.
9. Сервер отвечает, посылая число и размер сообщений в почтовом ящике.
10. Клиент запрашивает список сообщений.
11. Сервер отвечает.
12. Клиент пересылает себе сообщения.
13. Клиент стирает сообщения на сервере.
14. Когда все сделано, он посылает команду завершения quit.
15. Сервер отвечает с помощью+ОК
Таблица 8.2 суммирует команды РОРЗ, которые обычно встречаются в трассировках сетевого мониторинга.
