WINS(Windows Internet Name Service) - NetBIOS Network

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

1.NetBIOS Network

BIOS(Basic Input Output System)는 컴퓨터에서 각종 디바이스들의 입출력을 담당하는 표준시스템이다. 컴퓨터 한 대만 있는 환경이 아닌 네트워크 환경을 고려해보면 이것만으로는 부족하다는 것을 알 수 있다. 하나의 시스템에 국한된 환경이 아니라 컴퓨터대 컴퓨터간의 입출력을 처리해야 할 필요성이 생긴 것이다. 이에 IBM은 Network에서 구현되는 BIOS를 개발했다. 이것이 NetBIOS이다.

이것은 네트워크에 있는 시스템들간의 통신을 위한 컴퓨터 이름 관리, 그리고 지속적인 통신을 위한 세션유지 등을 처리하고 실제 패킷을 전송할 책임이 있는 프로토콜을 호출하는데 필요한 일련의 방법들을 제공하고 있다. 하나의 어플리케이션이 네트워크 상에 있는 다른 컴퓨터의 어플리케이션에게 데이터를 주고 받는 데 필요한 네트워크 통신 부분과의 연결지점 역할을 담당하는 것이라고 이해하면 되겠다.

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

 

NetBIOS Name = 컴퓨터이름 (15byte) + 플래그 (1byte)

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

 

<1C> Domain controller <20> Server service <03> Messenger Service <00> Workstation Service <1D> Master Browser <1B> Domain Master Browser, PDC <1E> Potential Browser

                        <표1. NetBIOS Name Flag>

아래의 <화면1>은 secure라는 도메인에서 도메인 컨트롤러로 셋팅된 blue라는 이름의 서버에서 nbtstat 명령어를 통해서 blue 서버가 등록해서 사용하는 NetBIOS 이름들을 살펴 보았다. Blue 라는 이름이 여러개 등록되어 있는 것이 보이고 이름의 뒤쪽에는 <00> <20>등의 숫자가 보인다. 이것이 NetBIOS이름의 16번째 byte에 해당하는 플래그이다. 그리고 이것은 blue서버가 어떤 서비스로서 등록되었다는 역할을 구별해 준다.

<화면1. nbtstat -n>

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

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

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

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

 

<표2. Windows 2000 TCP/IP 구조>

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