WINS서버를 사용하지 않고 라우트된 도메인 환경에서 서로간에 자원공유가 가능하도록 할 수 있을까? RFC 표준만 그대로 지원한다면 방법은 없다. 하지만 마이크로소프트는 추가로 Lmhosts 파일을 통해서 NetBIOS 이름풀이를 지원하고 있다.

<그림6-16>을 예제로 설명하도록 한다. 회사의 도메인 이름은 Color 이다. 이 회사는 서울과 대전으로 지역이 나뉘어 있고 서울에는 Red 라는 이름의 도메인 컨트롤러가 위치해 있다. 서울과 대전에는 각각 Blue와 White 라는 파일서버가 있고, 서울과 대전의 클라이언트들은 도메인으로 로그온을 하고 Blue와 White 2대의 자원을 공유해서 사용하고 있다. 지역별로 구분을 한 예제이지만 서울과 대전이라는 WAN 구간의 경우에 한정된 것은 아니다. 한 지역에서도 라우터로써 네트워크가 나뉘어 있는 상황이라면 <그림6-16>의 예제와 같은 형태로 볼 수 있다. 서울과 대전이라는 지역적인 측면보다는 2개의 서로 다른 네트워크라고 이해하도록 하겠다. WINS서버가 없더라도 같은 네트워크 안에서 클라이언트들은 서버를 찾는데 어려움이 없다. 브로드캐스트라는 차선의 방법이 제공되기 때문이다. 하지만, 문제는 자신과 다른 네트워크 즉 라우터 건너편에 존재하는 서버에게 접근하려면 그때는 문제가 생긴다. 브로드캐스트가 라우터를 넘지 못하므로 서버를 찾을 방법이 없는 것이다.

이것을 해결하기 위해서 클라이언트 컴퓨터에서 lmhosts 파일을 이용할 수 있다. lmhosts 파일은 %systemroot%\system32\drivers\etc 폴더에 위치해 있다. (%systemroot%는 NT기반의 컴퓨터에서는 winnt 폴더를 의미한다.) <그림6-17> 해당폴더에는 몇가지 파일이 더 보인다. 다른 파일들 역시 TCP/IP 환경에서 각각 필요에 따라 사용된다. lmhosts 파일을 자세히 보면 다른 파일과 다른 것을 알 수 있다. hosts, protocol 등의 파일과 비교해서 '종류'를 살펴보면 'SAM 파일'로 되어 있는 것을 알 수 있다. 다른 파일들은 확장자가 없지만 lmhosts 파일은 실제로는 lmhosts.sam 이라는 파일명을 가지고 있다. 윈도우탐색기에서 도구à폴더옵션à보기 메뉴에서 '알려진 파일 형식의 파일 확장명 숨김'옵션을 지워주면 확장자까지를 확인할 수 있다.

lmhosts 파일을 사용하기 위해서는 확장자를 지워줘야 한다. <그림6-17>을 보면 예제의 PC에서는 기본적으로 lmhosts 파일을 사용하지 않고 있음을 알 수 있다. 메모장을 사용해서 lmhosts.sam파일을 열어본다. 이 파일은 텍스트 파일이므로 텍스트를 읽을 수 있는 프로그램이면 뭐든 상관없다. 아래의 <그림6-18>은 메모장을 사용해서 열어본 파일을 보여준다.

파일에 대한 설명이 있고, 텍스트의 맨 앞에는 한결같이 '#'이 붙어 있다. 이것은 주석처리됨을 의미한다. 끝까지 읽어봐도 #이 붙어 있음을 알 수 있다. 기본적으로는 아무런 내용이 존재하지 않는 빈 파일과 같다. <그림6-11>의 파란박스부분을 보면 #PRE, #DOM 등의 문자들이 보인다. 여기서의 #은 의미를 가진다. 이러한 것들은 특별한 의미가 있는 '태그(tag)'들이다. 사용법은 파일에 기록된 설명을 참고하겠다. 그렇다면 이 파일을 어떻게 사용할까? 예제를 들어서 작성을 해 보자.

<그림6-16>의 예제에서 Green 이라는 컴퓨터의 사용자는 color 도메인으로 로그온 하기 위해서 도메인 컨트롤러인 Red를 찾아야 하고, Blue 라는 서버에 연결하여 자원에 접근도 해야 한다. 이것을 가능하게 하기 위한 방법은 Green 컴퓨터의 lmhosts 파일을 편집함으로써 해결할 수 있다. lmhosts 파일을 열고 <그림6-19>와 같이 기록을 하면 된다.

<그림6-19>화면에서는 blue 서버가 192.168.10.200 IP Address를 사용하고 있음을 기록했고, #PRE #DOM 태그를 이용하여 Color 도메인의 도메인 컨트롤러가 Red 이고 Red는 192.168.10.2 IP Address를 사용하고 있음을 나타내고 있다. 여기서 #DOM 은 도메인명을 지정해 주는 것이고, #PRE는 시스템 시작과 동시에 PreLoad 시키는 것을 의미한다. #PRE 태그를 이용하면 시스템이 시작될 때 #PRE 태그가 붙어 있는 라인의 내용을 메모리에 로딩을 하게 되고 이것은 시스템을 끌 때까지는 계속 메모리에 올라와 있게 된다. 또는 명령프롬프트에서 'nbtstat -R'을 이용해서 로딩 시킬 수도 있다. Green 컴퓨터에서 nbtstat 유틸리티를 이용해서 잠시 들여다 보자.

Lmhosts파일에 원하는 정보를 입력했다면 파일을 저장한다. 저장할 때 ‘다른 이름으로 저장’을 선택하여 lmhosts파일을 큰 따옴표로 묶어서 확장자 없이 저장한다. 그렇지 않으면 lmhosts.txt 파일로 저장되어 이 파일은 동작하지 않는다. Lmhosts.sam 파일에서 확장자만 제거해도 무방하다.

예제에서 서울에 있는 Black 컴퓨터가 대전의 White를 찾을 수 있도록 하기 위해서는 역시 Black 컴퓨터의 lmhosts 파일에 White 의 정보를 추가해 주어야 한다. WINS 서버를 사용하지 못할 때 해결할 수 있는 차선책이긴 하지만, 어디까지나 차선책일 뿐이다. 사실상 번거롭다. 수많은 클라이언트들을 관리해야 하는 관리자라면 이러한 작업들이 보통 귀찮은 작업이 아니다. lmhosts를 WINS 서버의 오류시 사용하게 될 백업 측면에서 접근을 하는 것 정도라면 고려해 볼만 하지만, lmhosts 파일보다는 WINS서버의 오류시 그것을 대체하게 될 WINS서버를 추가로 구현하는 방법으로 접근하는 것이 바람직한다고 생각한다. 

이러한 WINS서버 역시 장기적으로는 사용되지 않을 서비스이다. 현재 시점에서 만일 회사의 네트워크 환경이 Windows2000이상의 환경으로 완전히 전환되고(이것은 서버뿐이 아니라 클라이언트 시스템까지 Windows 2000, Windows XP등으로 바뀌는 것을 의미한다.) 도메인 환경이 구축되었다면, 더 이상 WINS 설정을 하지 않아도 좋다. 이들은 DNS 쿼리를 통하여 자원에 접근하는 것이 가능하기 때문이다. 또한 컴퓨터들의 TCP/IP설정에서 “TCP/IP에서 NetBIOS 사용안함”옵션을 활성화시키는 바람직하다. 이것은 불필요한 네트워크 트래픽을 상당부분 감소시켜 줄 수 있다. 하지만 지금은 분명히 이러한 점에 있어서는 과도기이다. 당분간은 여전히 이전 버전의 클라이언트들을 지원해야 하기 때문에 WINS의 존재는 분명히 필요하다. 제대로 WINS서비스를 잘 구성해 놓는것만으로도 여러분은 네트워크상에서 문제점이 상당히 줄어들었다는 실감할 수 있을 것이다.

앞에서 WINS서버를 설치하고 클라이언트를 설정하는 방법을 설명하였다. 지극히 쉬운 방법이지만 이렇게 설정해 놓은 WINS서버가 실패했을 경우 즉 서비스가 멈추는 상황이 발생한다면 큰일이 아닐 수 없다. 회사에서 WINS서버의 활용도가 크면 클수록 문제발생시의 불편함은 커지기 마련일 것이다. 네트워크 상에서 서비스가 구현이 될 때 관리자가 반드시 고려해 봐야 할 부분이 이러한 것이다. 서비스를 하던 서버가 멈췄더라도 여전히 클라이언트는 원하는 작업을 계속할 수 있어야 한다는 것이다. 바로 가용성(Availability)을 고려해야 한다는 것을 의미한다. 또 한가지는 회사에 하나의 서버가 있는데 서버가 수용하기 어려울 정도로 많은 사용자가 서비스를 요청한다면? 당연히 결과는 너무나 느린 응답시간 때문에 사용자들의 불만은 커질 것이고 심한 경우는 서버의 다운으로 까지 이어져서 네트워크가 마비되는 결과를 초래할 수도 있을 것이다. 가용성과 더불어 추가로 고려해야 할 사항이 바로 성능(Performance)이다. 이 두가지 사항을 감안하여 기업 네트워크 상에 어떻게 하는 것이 WINS서버를 구현하는 최선의 방법이 될 것인지 알아보도록 하자.

아래의 <그림6-11>를 보면서 접근해 보자. 예제그림은 서울에 본사가 있고, 부산에 지사가 있는 회사이다. 서울과 부산간에는 상대적으로 느린 WAN 링크를 이용하고 있고, 두 지역간에는 서로간에 자원을 공유해야 할 필요성이 있다. WINS서버를 구현하고자 하는데 가용성과 성능을 고려해서 최적화된 WINS 서비스를 구현하기를 원한다. WINS서버는 몇대를 두고 어디에 배치를 하고, 클라이언트는 어떻게 설정을 해 줘야 할까?

WINS 서비스의 가용성과 성능을 높일 수 있는 방법중 가장 일반적인 것은 서버를 여러대 배치하는 것이다. 하나의 서버가 서비스를 하지 못하더라도 다른 서버가 계속 서비스를 제공할 수 있기 때문이다. 두 대를 배치한다고 가정하면 서울에만 2대의 WINS서버를 두는 것보다는 지역마다 하나씩 두는 것이 바람직할 것이다. 그렇지 않으면 부산에 있는 WINS클라이언트가 자신의 NetBIOS 이름을 등록할 경우, 또는 다른 서버의 NetBIOS 이름해석을 요청할 때마다 상대적으로 느린 WAN 구간을 거쳐야 할 것이다. 여기서 우리가 고려해 보아야 할 점은 두 대의 서버가 각각 정상적으로 동작하고 있는 경우라면 가급적이면 WAN 트래픽이 발생하지 않도록 해야 한다는 것이다.

이를 해결하기 위해서 일단 서울에 WINS-A를 설치하였다. 그리고 서울에 있는 모든 컴퓨터를 WINS-A의 클라이언트로 설정하였다. 다음에 부산에 WINS-B를 설치하고 부산의 모든 컴퓨터를 WINS-B의 WINS클라이언트로 설정하였다. 이렇게 하면 서울에서의 WINS 트래픽은 서울지역에만 국한되고, 부산에서의 WINS 트래픽은 부산지역에서만 발생될 것이다.

여기까지만 구성하면 문제가 발생한다. <그림6-11>에서 부산의 WINS 클라이언트인 RED가 서울에 있는 BLUE 라는 이름의 서버를 찾고자 한다면 어떻게 될 것인지 생각해 보자. RED는 WINS-B에게 BLUE 라는 NetBIOS 이름을 쿼리할 것이다. 하지만 WINS-B는 BLUE의 IP Address를 알 수가 없다. 왜냐하면 BLUE는 자신의 클라이언트가 아니기 때문이다. BLUE의 레코드는 서울의 WINS서버인 WINS-A가 가지고 있을 뿐이다. 서울의 WINS서버와 부산의 WINS서버의 WINS Database는 서로 다르다. WINS-A는 서울의 WINS 클라이언트의 레코드를 가지고 있고, WINS-B는 부산의 WINS 클라이언트의 레코드를 가지고 있다. 서울과 부산간에 자원의 공유가 가능해 지려면 이 두 WINS서버들의 WINS Database가 교환될 필요성이 생긴다. 이 과정을 WINS Database 복제를 설정함으로써 가능하게 만든다.

이들 두 대의 WINS서버는 서로를 WINS Database 복제파트너로 설정하여 자신의 DB를 밀어주고(push partner), 상대방의 DB를 끌어오는(Pull Partner) 형태로 서로 다른 WINS Database를 하나로 통합할 수가 있게 된다. 이렇게 하면 부산에 있는 WINS Client가 자신의 WINS서버에게 서울의 레코드를 요청하더라도 올바른 응답을 받을 수 있게 된다. WINS 데이터베이스 복제파트너는 WINS 관리콘솔에서 '복제파트너'를 통해서 추가할 수 있다. <그림6-12>에서는 redapple이라는 이름의 WINS서버를 복제파트너로 추가하고 등록정보를 열어서 Pull / Push 복제 일정을 확인한 것을 볼 수 있다. 

 <그림6-13. WINS 복제 파트너 추가 >

복제파트너로 구성할 상대방 WINS서버의 이름이나 IP주소를 입력해야 한다. IP주소를 입력하는 것이 좋다.

이번엔 다른 측면을 고려해 보자. 만일 부산에 있는 WINS 서버가 멈춘다면 어떻게 될까? 당연한 얘기지만 부산지역의 WINS 클라이언트는 더 이상 WINS서버를 이용할 수가 없다. 그러면 그 클라이언트들은 부산지역의 서버를 찾을 때는 WINS서버를 이용할 수 없으므로 다음 방법인 브로드캐스트를 이용해서 검색을 할 수도 있겠지만 서울지역에 위치한 컴퓨터들을 찾고자 할 때는 실패할 수밖에 없게 된다. 그렇다면 이러면 되겠다. 부산에 있는 WINS서버가 동작하고 있을 때는 해당 서버를 통해서 서비스를 받고, 만일 부산의 WINS 서버가 문제가 있다면 서울의 WINS 서버를 사용하면 될 것이다. 그렇게 동작하도록 하기 위해서 부산의 WINS 클라이언트들에게 두 번째 WINS서버를 추가로 설정을 해 줄 수 있다. <그림6-15>의 빨간색 표기부분을 보면 2개의 IP Address가 설정되어 있다. [추가]버튼을 이용하여 WINS서버를 추가할 수 있고 오른편의 [화살표]버튼을 이용하여 쿼리순서를 결정할 수 있다. 물론 서울의 WINS 클라이언트들은 두 번째 WINS Server로서 부산의 WINS서버를 이용할 수 있도록 설정해 줘야 한다.

만일 네트워크에 비 WINS 클라이언트가 있다면 그들을 지원해야 할 필요가 있다. 비 WINS 클라이언트는 자신의 NetBIOS이름을 WINS 서버에 등록하지 않는다. 또, 다른 서버의 자원에 접근하기 위해서 NetBIOS이름풀이(name resolution)를 할 때도 역시 WINS서버에게 쿼리하지 않고 브로드캐스트를 이용한다. 아래의 <그림6-7>을 보면서 설명한다.

<그림6-7>의 예제에서는 라우터로서 분리된 2개의 브로드캐스트 도메인을 보여준다. 왼쪽의 세그먼트에는 WINS서버가 있고, WINS 클라이언트인 'Blue'라는 이름의 컴퓨터도 존재한다. 오른쪽의 세그먼트에는 왼쪽의 WINS Server의 클라이언트로 설정된 WINS 클라이언트도 있고, 'Red'라는 이름의 Non-WINS 클라이언트도 존재한다.

첫 번째 상황을 가정해 보자. 예제와 같은 환경에서 Blue가 Red의 자원에 접근을 하고자 한다(①). Blue의 사용자는 \\red\public 이라는 UNC 경로를 사용하여 red에 접근을 시도했다. red 라는 NetBIOS Name은 TCP/IP 통신을 위해서 당연히 IP Address로 매핑 (resolution)되어야 한다. blue는 WINS 클라이언트이므로 NetBIOS 이름풀이 방법으로써 WINS서버에게 요청을 하게 된다(②). 이 요청을 받은 WINS Server는 WINS Database에서 "Red <20>"이라는 NetBIOS 이름을 검색한다. 하지만 red의 레코드를 찾지 못한다. 이유는 Red가 Non-WINS 클라이언트이므로 자신의 NetBIOS Name을 WINS Server에 등록하지 않았기 때문이다. 결국 WINS 서버는 Blue에게 NetBIOS Name Resolution을 하지 못했다는 응답을 하게 되고, Blue는 그 다음 Resolution방법으로 브로드캐스트를 시도하게 된다. 그렇지만, 라우터로 네트워크가 분리되어 있고 Red 는 원격지의 네트워크에 위치해 있으므로 검색에 실패하게 된다. 결과적으로 Blue에서는 "네트워크 경로를 찾지 못했다."라는 에러 메시지를 확인하게 된다. 통신실패를 의미한다.

해결방법은 있다. 기본적으로 WINS 서버는 동적으로 동작하지만 관리자가 수동으로 레코드를 추가할 수도 있다. 정적매핑을 통하여 Red를 WINS 서버에 추가해 주면 된다. WINS 관리콘솔의 왼쪽 패널의 서버이름 아래에 있는 '활성등록'을 선택한 다음 마우스 오른쪽 클릭하여 '새 정적 매핑'을 선택한다. Red 의 IP Address를 할당해 주면 된다. <그림6-8>

<그림6-9>을 보면 정적 매핑으로 추가한 Red 의 레코드를 확인할 수 있다. 이제 WINS 클라이언트인 Blue는 WINS 서버를 통하여 Red 의 IP Address를 쿼리할 수 있게 되었다.

두 번째 상황도 고려해 보도록 하겠다. 이번에는 Non-WINS 클라이언트인 Red가 WINS 클라이언트인 Blue를 찾고자 할 때의 상황을 생각한다. Red의 사용자는 Blue의 Public 공유폴더에 연결하기 위하여 \\blue\public 이라는 UNC를 통해서 접근을 시도했다(③). Red 는 Non-WINS 클라이언트이므로 Blue의 NetBIOS 이름을 찾기 위해 WINS서버에게 쿼리하지 않는다. 브로드캐스트를 이용해서 이름풀이를 시도할 것이다(④). 당연히 라우터의 건너편 네트워크에 존재하는 Blue로부터 응답이 올 수가 없다. 역시 에러 메시지를 받게 될 것이다. 이것을 해결할 방법은 있다. 다행히 오른쪽 편의 네트워크에 WINS 클라이언트가 존재한다. 이 WINS 클라이언트가 Non-WINS 클라이언트를 대신해서 WINS 서버에 요청을 전달해 주게 구성할 수 있다. 이때 이러한 WINS 클라이언트를 가리켜서 'WINS Proxy Agent'라고 부른다. WINS Proxy Agent를 구성하기 위해서는 레지스트리를 직접 편집해 주어야 한다. WINS Proxy Agent로 구성할 시스템에서 레지스트리 편집기(regedt32.exe 혹은 regedit.exe)를 통해서 레지스트리를 열고 \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\ 키를 찾은후 'EnabledProxy' 값을 '1'로 설정하면 된다.<그림6-10>

뭔가 되긴 된 듯해 보이지만 석연찮은 구석이 있다. 이거 WINS 클라이언트가 아닌 녀석이 하나 끼어있으니까 이래저래 번거로운걸? 하는 생각이 들었다면 지금까지 내용을 잘 이해한 독자라는 생각이 든다. 방법은 있다. 아주 간단한 방법. Non-WINS Client를 두지 않고 전체 모든 시스템을 WINS 클라이언트로 만들면 모든 것이 해결된다. WINS솔루션을 구현하자. 하지 못할 이유가 없다.

위에서 WINS서버를 구현하는 방법이 가장 바람직한다는 말을 했다. 그렇다면 이제 WINS서버를 설치하고 구성을 해 보도록 하겠다. WINS서비스를 먼저 추가해 주어야 한다. 제어판àWindows구성요소 추가à네트워킹서비스àWINS를 통해서 추가할 수 있다.<그림6-4>

<그림6-4. WINS 서비스 설치 >

설치가 완료되면 그것으로 WINS서버의 준비는 끝났다. 다음엔 WINS서버에게 자신의 NetBIOS이름을 등록하고 다른 서버의 NetBIOS 이름을 쿼리할 수 있도록 클라이언트 셋팅을 해야 한다. ‘제어판à네트워크 연결’을 통해서 TCP/IP 등록정보를 연 다음, [고급]버튼을 클릭하면 WINS 탭을 볼 수 있다. [추가]를 이용하여 앞에서 WINS서비스를 설치한 서버의 IP Address를 입력한다. 예제에서는 192.168.0.16을 입력했다.<그림6-5>

클라이언트도 구성을 했다. 이것으로써 WINS서버와 WINS클라이언트 구성을 모두 마쳤다. 사실 설치는 너무나 쉽다. 그것보다는 이러한 서비스들의 필요성을 이해하는 것이 보다 중요한 일이라고 생각한다. 과정을 이해하면 보다 커다란 환경의 네트워크를 만나게 되었을 때도 적절히 대처를 하는 것이 용이할 것이기 때문이다. 이제 WINS서버쪽에서 WINS 관리도구를 열어보면 <그림6-6>에서 보는 것처럼 클라이언트가 등록되어 있음을 알 수 있다. 또 다른 WINS 클라이언트가 BLUEXP라는 NetBIOS 이름에 대한 IP Address를 요청한다면 이 WINS서버는 응답을 할 수가 있게 된다. 이러한 일련의 과정들은 동적으로 동작한다. 관리자는 WINS서비스를 추가해 주고, 네트워크 상의 모든 클라이언트를 WINS 클라이언트로만 구성해 주면 나머지는 WINS서비스가 알아서 처리한다. 말 그대로 ‘서비스’이다.

6-2-1. NetBIOS 이름 등록 및 해제

NetBIOS이름이 사용되기 위해서는 먼저 네트워크에 등록이 되어야 한다. 이름등록을 하는 방법으로는 두가지가 제공된다.

첫 번째 방법은 브로드캐스트를 이용하는 것이다. 시스템이 시작되고 NetBIOS 어플리케이션이 시작되게 되면 이름등록을 진행하게 된다. 이때 브로드캐스트를 통해서 네트워크에 자신의 이름을 등록하게 된다. 만일 사용하고자 하는 이름을 누군가 미리 등록해서 사용하고 있다.면 이름충돌의 에러메시지를 받게 되고, 해당 이름등록은 실패하게 된다.

두 번째 방법은 NetBIOS Name 서버에게 이름등록을 요청하는 방법이다. 네트워크에 브로드캐스트를 발생시키지 않으므로 보다 권장할 만한 방법이라고 하겠다. NetBIOS이름서버에게 이름등록을 요청하기 위해서 해당 시스템은 NetBIOS이름서버의 클라이언트로 설정되어야 한다.  NetBIOS 이름해제는 반대과정이다. 이것은 NetBIOS 어플리케이션이 중지될 때 발생하는 일이다. 결과적으로는 시스템이 셧다운 될 때 생기는 과정이라고 할 수 있다.

6-2-2. NetBIOS 이름 분해 요청 (Name Resolution Request)

이것은 클라이언트가 자원을 가진 서버의 NetBIOS이름에 해당하는 IP Address를 찾고자 할 때 발생한다. 파일서버의 자원에 접근하기 위해 서버를 검색할 때 혹은 도메인으로 로그온을 시도할 때 등등 여러 가지 상황에서 NetBIOS 이름요청이 활성화된다. NetBIOS 이름 요청 방법도 역시 두 가지가 제공된다. 첫 번째 방법은 브로드캐스트를 이용하는 것이고, 두 번째 방법은 NetBIOS 이름 서버를 통해 찾는 것이다.

하나의 시스템이 NetBIOS Name Server의 클라이언트로 셋팅되면 자신의 NetBIOS 이름을 등록할 때도 NetBIOS 이름 서버를 이용하고, 다른 시스템의 NetBIOS Name을 쿼리할 때도 역시 NetBIOS 이름 서버를 이용한다. 그렇지 못한 클라이언트라면 브로드캐스트 통신방법을 사용하여 NetBIOS 이름을 찾으려는 시도를 한다.

아무런 설정이 필요없이 통신을 위한 기본작업인 “이름을 가지고 주소를 찾기”라는 과제를 해결해 줄 수 있다는 측면에서는 브로드캐스드가 편한 방법이라고도 생각될 수 있지만 그렇게 되면 라우터로 분리된 네트워크에서 라우터 건너편 노드의 NetBIOS이름을 찾는 것은 불가능한 일이 된다. 또 노드수가 많아진다면 그만큼 네트워크에 브로드캐스트가 많아지므로 결과적으로 네트워크에 전체적인 성능저하까지 가져올 수 있게 된다. 따라서 기업 네트워크에서 NetBIOS이름을 필요로 하다면 NetBIOS 이름서버를 사용하는 것이 보다 바람직한 방법이다. 마이크로소프트는 NetBIOS 이름서버로서 WINS (Windows Internet Name Service)서버를 제공해 주고 있다.

BIOS (Basic Input Output System)는 컴퓨터에서 각종 디바이스들의 입출력을 담당하는 표준시스템이다. 컴퓨터 한 대만 있는 환경이 아닌 네트워크 환경을 고려해보면 이것만으로는 부족한다는 것을 알 수 있다. 하나의 시스템에 국한된 환경이 아니라 컴퓨터 대 컴퓨터간의 입출력을 처리해야 할 필요성이 생겼다. 이에 IBM은 Network에서 구현되는 BIOS를 개발했다. 이것이 NetBIOS이다. 이것은 네트워크에 있는 시스템들간의 통신을 위한 컴퓨터 이름 관리, 그리고 지속적인 통신을 위한 세션유지 등을 처리하고 실제 패킷을 전송할 책임이 있는 프로토콜을 호출하는데 필요한 일련의 방법들을 제공하고 있다. 하나의 어플리케이션이 네트워크 상에 있는 다른 컴퓨터의 어플리케이션에게 데이터를 주고 받는 데 필요한 네트워크 통신 부분과의 연결지점 역할을 담당하는 것이다.

그렇다면 이들 NetBIOS 프로토콜을 사용하는 어플리케이션이 상대방 컴퓨터를 찾을 때는 어떤 이름을 사용할까? 그것 역시NetBIOS 표준이름 구현을 통해서 상대방 시스템을 찾게 된다. 이러한 이름체계 역시 NetBIOS 라는 표준에 맞도록 정의되어 있다.

NetBIOS는 16byte로 구성이 되어 있지만 실제로 컴퓨터 이름으로 할당할 수 있는 바이트수는 15바이트로 제한된다. 마지막 16byte째의 플래그는 특별한 용도로 사용된다.

하나의 서버가 하는 일은 다양하다. 예를 들어 네트워크에 자신의 자원을 제공해 줄 수 있는 역할인 '서버 서비스'를 하고 있고, 자신도 클라이언트로서 다른 자원에 접근할 수 있는 '워크스테이션 서비스'도 하고 있고, 또 도메인 컨트롤러라면 도메인 사용자들의 로그온을 처리해 주는 '로그온 서비스'도 하고 있고, 다른 서버로부터 알림 메시지를 받기 위한 '메신저 서비스'도 하고 있을 것이다. 이러한 각각의 서비스를 구별하기 위하여 16byte째의 플래그가 사용된다. 이 16번째의 플래그는 1byte를 차지하며 2자리수의 Hexadecimal (16진수) 값으로 만들어지고 각각 서비스 타입별로 숫자가 지정되어 있다. 자주 볼 수 있는 플래그를 정리해 보면 다음과 같다.

<표6-1. NetBIOS Name Flag >

아래의 <그림6-2>은 windowsnetwork 도메인에서 도메인 컨트롤러로 셋팅된 blueapple이라는 이름의 서버에서 nbtstat 명령어를 통해서 blueapple 서버가 등록해서 사용하는 NetBIOS 이름들을 살펴 보았다. Blueapple이라는 이름이 여러개 등록되어 있는 것이 보이고 이름의 뒤쪽에는 <00> <20>등의 숫자가 보인다. 이것이 NetBIOS이름의 16번째 byte에 해당하는 플래그이다. 그리고 이것은 blueapple서버가 어떤 서비스를 하고 있는지 서버의 역할을 나타낸다.

실제로 이러한 NetBIOS 이름이 어떤 경우에 사용되는지 예를 들어보자. 클라이언트가 blue라는 이름의 서버의 공유폴더에 접근하고자 한다면 사용자는 '\\blueapple\공유이름' 의 형태로 접근을 하게 된다. 이때 실제로 네트워크 상에 요청을 확인해 보면 'BLUEAPPPLE <20>'을 찾는 것을 확인할 수 있다. 서버로서의 blueapple을 찾는 요청이기 때문이다. 또, Windows98혹은 NT4.0 사용자가 windowsnetwork 도메인으로 로그온을 시도한다면 도메인에서 로그온을 받아주는 서버, 즉 도메인 컨트롤러를 찾아야 한다. 그때의 요청은 실제로는 'WINDOWSNETWORK<1C>'가 된다.

이렇듯 클라이언트가 특정 서버의 NetBIOS 이름을 찾기 위해서는 선행되야 할 일이 있다. 당연히 네트워크에 서버의 NetBIOS이름이 등록되어 있어야 찾을 수가 있을 것이다. 그렇다면 서버는 어떤 방법으로 네트워크에 자신의 NetBIOS 이름을 등록하는 것일까? 또, 클라이언트는 어떤 방법으로 네트워크에 등록된 NetBIOS 이름을 찾을 수가 있는 것일까? 여기서 WINS의 필요성은 출발 할 수 있다.

마이크로소프트는 자사의 네트워크에서 NetBIOS를 채택하고 꾸준히 이를 지원해 왔다. 그리고 NetBEUI (NetBIOS Extended User Interface)프로토콜을 개발하여 NetBIOS를 지원했다. NetBEUI는 NetBIOS를 지원하기 위해서 개발된 프로토콜이므로 NetBIOS를 완전하게 지원할 수 있는 잘 동작하는 프로토콜이다. 하지만 이 프로토콜의 통신방법은 NetBIOS 이름기반의 브로드캐스트에 의존하고 있고, 이것은 라우터로 브로드캐스트 도메인이 분리된 확장된 네트워크 환경에서는 큰 문제점을 안고 있다. 라우팅이 되지 않기 때문에 네트워크의 확장성이 매우 떨어지게 되는 단점이 있는 것이다. 더불어 인터넷 표준 프로토콜로써 TCP/IP프로토콜이 사용이 되고 회사의 네트워크가 더 이상 로컬 LAN에만 국한되어 단순히 파일이나 프린트 공유정도만을 요구하지는 않는다. 대부분의 시스템에서 인터넷에 접근을 하는 것이 기본적인 사항이 되어가고 있으니 NetBEUI를 사용하는 클라이언트라도 추가로 TCP/IP를 설치하여 사용할 필요성이 생기게 되었다. 마이크로소프트 역시 TCP/IP를 지원하고 있다.

여기서 한가지 고려해 봐야 할 것이 있다. NetBIOS 어플리케이션은 브로드캐스트 통신방법에 기초한 NetBIOS이름을 이용해서 통신을 한다. 하지만, TCP/IP환경에서는 IP Address로써 각각의 시스템을 구분하고 IP Address를 근거해서 통신을 한다. 마이크로소프트에서 TCP/IP를 지원한다고 하더라도 여전히 기존의 어플리케이션이 NetBIOS를 필요로 하고 있고, 이것을 TCP/IP에서도 지원해 주어야만 호환성에 문제가 발생하지 않을 것이다. 그래서 TCP/IP 프로토콜의 구조를 살펴보면 'NetBT'라는 프로토콜이 포함되어 있음을 알 수 있다. NetBIOS over TCP/IP를 줄인 표기이다. TCP/IP상에서 NetBIOS를 구현하기 위한 인터페이스를 제공하고 있다.

위에서 보듯이 NetBIOS 어플리케이션들은 NetBT 인터페이스를 통해서 TCP/IP의 TCP나 UDP를 호출하는 것이 가능해진다. 그렇지만 통신상에서 구별하는 이름에는 여전히 차이가 있다. NetBIOS 어플리케이션에서는 NetBIOS이름을 통해서 상대방 시스템을 찾으려 시도할 것이고, TCP/IP 프로토콜에서는 그러한 이름을 알 수가 없다. 누군가가 이 문제점을 해결해 주어야 한다. 이것을 해결하기 위한 인터넷 표준이 두 가지 마련되어 있다. 하나씩 알아보도록 하자.

마이크로소프트의 네트워크 환경에서 여러 가지 서비스를 하는 서버들이 있지만, 역시 빼 놓을 수 없는 서비스가 하나 있다. Windows NT4.0 에 비하면 Windows 2000 환경에서는 그 역할이 많이 줄어들었지만 여전히 기업네트워크에서는 중요한 서비스중 하나임에는 틀림없다. WINS서버가 왜 필요하고, 네트워크에서 수행하는 역할은 무엇인지, 최적화된 관리방법은 무엇인지 차근차근 접근해 보도록 하겠다.