home | login | register | DMCA | contacts | help | donate |      

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
А Б В Г Д Е Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я


my bookshelf | genres | recommend | rating of books | rating of authors | reviews | new | форум | collections | читалки | авторам | add

реклама - advertisement



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-протокол не исключает), но оставим возможность и автоматического присвоения для всех остальных.

А что такое четвертый путь? А это вообще отказ от символьных имен узлов и обращение к ним по IP-адресу. Например, если вы знаете, что папка под названием backup находится на файловом хранилище c IP-адресом 192.168.1.2, то вы можете к ней обратиться, не дожидаясь, пока она соизволит появиться в папке Сеть (Сетевое окружение ). Для этого в Проводнике (именно в Проводнике, Windows Explorer, вызванном, например, через значок Мой компьютер в Windows XP) следует набрать \192.168.1.2(без указания протокола). В Windows Vista или в Windows 7 то же самое можно сделать прямо в адресной строке папки Сеть , доступной через пункт Компьютер меню кнопки Пуск . Точно так же это будет работать и в Internet Explorer (точнее, Windows Explorer все равно автоматически переключится в режим Internet Explorer). В альтернативных браузерах, вроде Mozilla Firefox, все это может работать несколько иначе, но обычно браузера для доступа к ресурсам локальной сети не требуется. Конкретные рецепты преодоления ситуации с неопределяющимися ресурсами рассмотрены в разд. 6.2 «Доступ к локальной сети в Windows».

Доступ к интернет-ресурсам по IP-адресу

Способ прямого доступа по IP-адресу прекрасно работает и в Интернете – он, в частности, позволяет обойти нарушения в системе DNS. Даже если США, контролирующие систему доменных имен, зачем-то захотят ее разрушить, то прямая адресация все равно будет работать. Все зарегистрированные сайты имеют статические адреса, и обращение по ним вместо символьного адреса даже сокращает время – браузеру не приходится обращаться по иерархии DNS-серверов. Кроме того, вы можете точно так же записать в файл hosts соответствия IP-адресов и символьных имен серверов, находящихся где-нибудь в Австралии, и ваш компьютер будет послушно к ним обращаться (некоторые интернет-вирусы так и поступают для подмены IP-адресов популярных ресурсов на свои собственные).

Понятно, что способ обращения непосредственно по IP-адресу неудобен, а при динамическом присвоении адресов он вовсе не работает – придется гадать, какой там сегодня адрес у файлового хранилища по имени I-Stor? Или надо будет вручную перебирать все возможные адреса в соответствии с маской локальной сети (программы-сканеры, описанные далее, нам не помогут, потому что они дожидаются, пока все имена определятся). Именно поэтому использование символьных имен ресурсов при обращении к ним предпочтительнее – они-то не меняются произвольным образом.

5.4.2. Дождемся протокола IPv6

Положение может измениться при всеобщем и обязательном внедрении протокола IPv6, когда за каждым устройством в глобальной сети можно будет закрепить однозначный статический IP-адрес – так, как сейчас за каждой сетевой картой закреплен свой MAC-адрес. Но такая идиллия очень далека от воплощения в реальность, и как минимум адресация в локальных сетях в обозримом будущем будет соответствовать описанным здесь правилам. Microsoft еще в Windows XP пыталась избавиться от наследия NetBIOS, в виде всех этих WINS и hosts, но оно сохранилось и широко используется даже в Windows 7. Начиная с Windows Vista, реализация всех этих заморочек действительно была упрощена, но принцип остался тот же, а количество других настроек, если уж они потребуются, даже возросло.


5.3. Адресация в локальных сетях | 1001 совет по обустройству компьютера | 5.5. Мониторинг локальной сети