Обсуждали тут с коллегами про пользу и вред NetBIOS.

У многих коллег и заказчиков возникает переодически вопрос, да и у меня в свое время подобного рода вопрос возникал. А вопрос – нужен ли NetBIOS в сети, где все машины с ОС Microsoft это Windows XP, 2003 или новее… Вопрос не праздный. Так вот что на эту тему удалось осознать в ходе дискуссии.

 

Большинство проблем от несовсем аккуратных формулировок, которые употребляют авторы статей KB и MSDN (они тоже частенько заблуждаются и ошибаются). Так вот, истинный корень проблемы использования или неиспользования NetBIOS кроется в том, что существует два подмножества API-функций в MS Windows, разрешающих сетевые имена: подмножество WinSock и подмножество NetBIOS. Это РАЗНЫЕ функции Windows API и разные технологии. NetBIOS изобрела и реализовала первой IBM (http://www.ehsco.com/reading/19960915ncw1.html), а идеалогия сокетов впервые появилась в Unix системах (BSD). Потом, когда TCP/IP, под который были успешно адаптированы библиоткеи сокетов, получил широкое признание и распространение как масштабируемое решение (NetBIOS был изначально сильно ограничен по числу узлов в сети и т.п.) были написаны RFC 1001 и 1002, в которых дана концепция адаптации протокола NetBIOS к новой сетевой среде на базе TCP/IP. Собственно именно эти RFC и описывают технологию NetBIOS over TCP/IP (или еще ее называют NetBT). В реализации Microsoft сетевой стек совмещающий в себе решения BSD Sokets и NetBIOS стал выглядеть так: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cnbb_tcp_jeps.mspx. Хотя изначально реализация NetBIOS не предусматривала вообще прослойки TCP/IP под ней, а функции NetBIOS (в том числе и разрешения имен) работали непосредственно с драйверами сетевых карт и т.п. Т.е. в сетевом стеке функции NetBIOS ранее стояли ниже. Про уровень протокола детальнее см. то как работает NetBIOS в реализации NetBEUI и IPX/SPX. 

 

Другое дело, что в реализации от Microsoft функции библиотеки WinSock (gethostbyname, getaddresinfo, getnameinfo, и другие) при разрешении имен пользуются известной всем нам из всех курсов последовательностью: http://technet2.microsoft.com/windowsserver/en/library/80419507-775f-4274-b300-5b3f76cfb46e1033.mspx (own host name, hosts, DNS, NetBIOS (broadcast и(или) WINS), lmhosts). Сделано это для совместимости протоколов и приложений. При этом в ходе вызова gethostbyname для FQDN имен и IP-адресов попытки разрешения имен через функции NetBIOS вообще не производиться (отсюда и возникает путаница между NetBIOS именами, которые всегда состоят из 16 ASCII символов, последний из которых служебный и определяет тип имени, и просто короткими DNS именами не содержащими точки). Понятно, что поскольку DNS метка (часть имени DNS между точками) может достигать по RFC длины до 64 символов, а FQDN имя и того больше (до 254 символов), то даже для коротких DNS имен (не FQDN), но длиной более 15 символов разрешение NetBIOS тоже не производится. Функция gethostbyname и ее аналоги просто не вызывают в своем алгоритме функции разрешения имени NetBIOS API для таких имен. В случае же если разрешаемое имя с помошью функции gethostbyname короче 16 символов (от 1 до 15-и) оно дополняется пробелами передается для разрешения в NetBIOS API.

 

Но все это не отменяет возможности программ использовать для разрешения имен API именно NetBIOS (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cnbb_tcp_ejis.mspx) а не функции WinSock. Вот цитата: 

NetBIOS defines a software interface and a naming convention, not a protocol. Early versions of Microsoft networking products provided only the NetBIOS Extended User Interface (NetBEUI) protocol with a NetBIOS application-programming interface. NetBEUI is a small, fast protocol with no networking layer; thus, it is not routable and is not suitable for internetworks. NetBEUI relies on multicasts for name resolution and location of services. NetBIOS over TCP/IP provides the NetBIOS programming interface over the TCP/IP protocol, extending the reach of NetBIOS client and server programs to the WAN, and providing interoperability with various other operating systems. The Workstation, Server, Browser, Messenger, and NetLogon services are all (direct) NetBT clients. They use TDI (described earlier in this article) to communicate with NetBT. Windows Server 2003 also includes a NetBIOS emulator. The emulator takes standard NetBIOS requests from NetBIOS applications and translates them to equivalent TDI primitives.

Windows Server 2003 still uses NetBIOS over TCP/IP to communicate with prior versions of Windows NT and other clients, such as Windows 98. However, the Windows Server 2003 redirector and server components also support direct hosting to communicate with other computers capable of direct hosting. Direct hosting uses DNS for name resolution. No NetBIOS name resolution (WINS or broadcast) is used, and the protocol is simpler. Direct hosting uses TCP port 445, instead of the NetBIOS TCP port 139.

См. еще тут: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cnad_arc_khqp.mspx

 

Так вот, в этом и есть корень всех проблем с NetBIOS-ом и причина путаницы коротких имен вообще и имен NetBIOS.

Что касается конкретно Exchange 2003 – даже разработчики вряд ли быстро ответят на вопрос, есть ли в коде Exchange 2003 или его установщика вызов именно функций NetBT API или обращение к зависимым от NetBIOS функциям служб прямых клиентов NetBT (Workstation, Server, Browser, Messenger, and NetLogon), так что вероятность того, что не все сетевые задачи в наших приложениях (в частности Exchange 2003 сделаны с использованием WinSock очень высока. 🙂 Но вспоминая как работает разрешение имен в интерфейсе NetBT (а оно тоже обращается в определенных ситуациях к DNS резолвингу [т.е. DNS резолвинг на самом деле происходит при полной последовательности разрешении имене два раза – в начале и почти в самом конце]) мы зачастую не замечаем потенциальных проблем с работой NetBIOS и думаем, что все дело в обычном разрешении коротких имен. 

Вот по поводу самого разрешения имен NetBIOS: http://support.microsoft.com/kb/142309/en-us 

Так же внимательно посмотрите на Flow-charts алгоритмов разрешения имен – вас это позабавит (не наблюдаете ли рекурсии):

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/prork/prcc_tcp_gclb.mspx?mfr=true

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/prork/prcc_tcp_gclb.mspx?mfr=true

О том как разработчики боряться с "зацикливанием" этого алгоритма можно только догадываться… 😉

Да, если интересно, то описание API NetBIOS (не важно на базе какого протокола они работают TCP/IP, NetBEUI, IPX/SPX) можно посмотреть тут: http://msdn.microsoft.com/archive/en-us/netbios/netbios_20bp.asp?frame=true. В частности за разрешение имен отвечает команда NCBFINDNAME, значение которой помещается в специальную структуру NCB (Network Control Block) и затем передается функции netbios. Эта единственная функция NetBIOS API реализована в библиотеке Netapi32.dll.

 

Как краткое резюме всего потока сознания, что написан выше скажу:

1) NetBIOS может использоваться напрямую и его отключение приводит иногда к нежелательным последствиям. Например, в оснастке Computer Management->Shared Folders->Sessions вместо имен хостов будут отображаться только IP-адреса.

2) В среде, где иерархия доменов и AD вырожденная в один домен в одном лесу, вы скорее всего не испытаете вообще никаких проблем при отключении NetBIOS.

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

4) Для ситуации описаной в п.3 этого списка в Windows Server 2008 предусмотрены зоны DNS специального типа – GlobalNames Zone (GNZ). Вот их описание:  http://www.microsoft.com/downloads/details.aspx?FamilyID=1c6b31cd-3dd9-4c3f-8acd-3201a57194f1&DisplayLang=en