Если для разных узлов на них самих заданы разные рабочие группы, то в Windows XP по адресу Сетевое окружение | Вся сеть | Microsoft Windows Networkпросто появятся две или более рабочих групп (рис. 5.2). В Windows Vista и 7 все еще проще – щелкнув в окне Компьютерпо папке Сеть, вы вообще не увидите распределения по рабочим группам, – компьютеры и другие узлы будут показываться в едином списке. Для описанных в этой книге случаев совершенно неважно, какая именно рабочая группа задана для данного компьютера, через сеть он все равно будет доступен на равных основаниях с другими. Точнее будет сказать, что в природе, несомненно, встречаются случаи, когда рабочая группа критична, но я просто с ними не сталкивался – специальные попытки найти разницу при работе с разными названиями групп для всех вариантов сетей, описанных в этой книге, у меня не увенчались успехом.
Рис. 5.2. Разные рабочие группы в одной локальной сети (Windows XP)
А для чего тогда это придумано – только для того, чтобы еще больше запутать бедного пользователя? Наоборот, создатели Windows искренне хотели облегчить ему жизнь – если у вас десяток компьютеров в одной сети, то объединение их в группу позволяет единым махом для членов этой группы задать всякие настройки (прежде всего настройки общего доступа). Если вы администратор офисной сети, то это действительно проще, чем бегать и настраивать каждый компьютер по отдельности. В небольшой же домашней сети все это можно просто игнорировать.
И чтобы еще больше усложнить жизнь пользователю (но упростить ее администратору), в Windows 7 придумали новую концепцию «домашней группы», которую можно использовать параллельно обычной рабочей. Поскольку домашние группы в сети могут быть созданы лишь для компьютеров, работающих под управлением Windows 7 (а это пока еще довольно редкий случай – обычно различные версии встречаются вперемешку), то мы постараемся к этому вопросу в дальнейшем не возвращаться, чтобы не усложнять себе и без того непростую сетевую жизнь.
5.4. Как заставить сетевые ресурсы определяться быстрее?
Интересно, что прямого ответа на этот вопрос я не встретил ни в литературе, ни на интернет-ресурсах, пришлось обращаться к специалистам и экспериментировать. Механизм определения сетевых ресурсов в Windows надежно и быстро работает лишь тогда, когда локальная сеть построена на основе домена. На практике это чаще всего делается в относительно крупных сетях масштаба офиса и выше (в том числе и в Интернете). Домашняя локальная сеть обычно строится на основе компонента NetBIOS, придуманного специально для Windows. Он включает упрощенную в сравнении с DNS службу NetBIOS-имен WINS (Windows Internet Name Service) и простой транспортный протокол UDP (вместо характерного для сетей с доменами протокола TCP).
Каждый узел в такой сети непрерывно рассылает UDP-запросы по широковещательному IP-адресу, заканчивающемуся на.255. В ответ все получившие запрос узлы должны отвечать, сообщая соответствие своего имени и IP-адреса. UDP – простой, но ненадежный протокол, который не гарантирует доставку отправленного пакета, тем более в сети, где связывается каждый с каждым. Поэтому установление соответствия имен и адресов в такой сети может затянуться на неопределенное время. При этом надо учесть, что при автоматическом распределении IP-адресов узел может ответить только тогда, когда он уже «узнает» собственный IP-адрес, о чем ему должен отдельно сообщить DHCP-сервер. Это еще больше затягивает процесс.
5.4.1. Оптимизация доступа
Отсюда вытекают целых четыре пути оптимизации локальной сети. Первый путь – отказаться от всех этих архаизмов в виде протокола UDP и создать свой собственный домен. По этому пути мы не пойдем ввиду повышенных требований к квалификации пользователя. Второй путь – раздавать IP-адреса статически. Тогда соответствие имени и IP-адреса извлекается из локальных ресурсов (файла hosts, см. далее), и задержки должны снижаться. Но этот путь неудобен, т. к. мы не знаем заранее всю конфигурацию сети, и для каждого гостя, пришедшего со своим ноутбуком, нам бы пришлось вручную его конфигурировать.
Потому мы пойдем по третьему пути – компромиссному. Для ресурсов, заведомо находящихся в сети, мы будем раздавать IP-адреса принудительно (что, как мы уже знаем, DHCP-протокол не исключает), но оставим возможность и автоматического присвоения для всех остальных.
Читать дальше
Конец ознакомительного отрывка
Купить книгу