| 계층별 OSI 모형 |
|---|
넷바이오스(NetBIOS, Network Basic Input/Output System)는 OSI 모형의 세션 계층과 관련된 서비스를 제공하여 개별 컴퓨터의 응용 프로그램이 근거리 통신망을 통해 통신할 수 있도록 한다. 엄밀히 말해 API인 넷바이오스는 네트워킹 프로토콜이 아니다. 1980년대의 운영체제 (주로 DOS 및 노벨 넷웨어)는 넷바이오스 프레임 (NBF) 및 IPX/SPX 상의 넷바이오스 (NBX) 프로토콜을 사용하여 IEEE 802.2 및 IPX/SPX 위에서 넷바이오스를 실행했다. 현대 네트워크에서 넷바이오스는 일반적으로 TCP/IP 상의 넷바이오스 (NBT) 프로토콜을 통해 TCP/IP 위에서 실행된다. 넷바이오스는 TCP/IP (윈도우)에서 시스템 이름을 식별하는 데에도 사용된다.
넷바이오스 프레임 프로토콜은 1990년대 마이크로소프트 윈도우 네트워킹의 계층 중 하나로 가장 일반적으로 사용된다. NBF 또는 IEEE 802.2 LLC 상의 넷바이오스는 1990년대에 출시된 여러 네트워크 운영체제 (예: LAN Manager, LAN Server, Windows for Workgroups, 윈도우 95, 윈도우 NT)에서 사용된다. TCP/IP 상의 넷바이오스 (NBT) 및 NBX (IPX/SPX 상의 넷바이오스)와 같은 다른 프로토콜도 다른 프로토콜 스위트 위에서 넷바이오스/넷BEUI 서비스를 구현한다.
넷바이오스는 컴퓨터의 응용 프로그램이 근거리 통신망 (LAN)을 통해 서로 통신할 수 있도록 하는 운영체제 수준의 API이다. 이 API는 1983년 사이텍 (Sytek Inc.)에서 IBM PC 네트워크 LAN 기술을 통한 소프트웨어 통신을 위해 개발했다.: 1-1 IBM PC 네트워크에서 넷바이오스는 API 자체로만 존재했으며, 통신을 위해 독점적인 사이텍 네트워킹 프로토콜에 의존했다.: 1-1
1985년 IBM은 토큰링 네트워크 구성을 진행하여 PC 네트워크 시대의 넷바이오스 인식 응용 프로그램이 IBM의 새로운 토큰링 하드웨어에서 작동할 수 있도록 사이텍의 넷바이오스 API 에뮬레이터를 만들었다.: 1-1 넷바이오스 확장 사용자 인터페이스 (NetBEUI)라고 명명된 이 IBM 에뮬레이터: 2-2 는 사이텍이 만든 기본 넷바이오스 API를 확장했으며, 특히 토큰링의 더 큰 노드 용량을 처리할 수 있는 기능을 포함했다.: 2-17 새로운 네트워킹 프로토콜인 넷바이오스 프레임 (NBF)은 IBM에 의해 동시에 개발되어 넷BEUI API가 토큰링 위에서 서비스를 제공할 수 있도록 했다. 특히 IEEE 802.2 논리적 링크 제어 계층에서 작동하며, 802.2 유형 1 모드를 사용하여 넷바이오스/넷BEUI 이름 서비스 및 데이터그램 서비스를 제공하고, 802.2 유형 2 모드를 사용하여 넷바이오스/넷BEUI 세션 서비스 (가상 회선)를 제공한다.: 3-8–3-10
1985년 마이크로소프트는 MS-Net 네트워킹 기술을 위한 자체 넷바이오스 API 구현을 만들었다. IBM의 토큰링의 경우와 마찬가지로, 마이크로소프트의 넷바이오스 구현 서비스는 NBF 프로토콜을 통해 IEEE 802.2 논리적 링크 제어 계층 위에서 제공되었다. 그러나 MS-Net은 OEM에게만 제공되었으며, 실제로는 완전한 제품이 아니었고 배포된 형태로 네트워크에서 통신할 준비가 되어 있지 않았다. OSI 모형의 1계층부터 4계층 (물리 계층, 데이터 링크 계층, 네트워크 계층, 전송 계층) 구현이 전혀 없었고, OEM은 MS-Net의 자체 버전을 완전하고 사용 준비가 된 제품으로 만들기 위해 이러한 구현 (넷바이오스 부품 형태)을 제공해야 했다. MS-Net은 마이크로소프트 자체 넷바이오스 변형을 통해 네트워크에 접근했으며, 이는 두 부분으로 나뉘었다. OEM이 제공해야 했던 하위 수준 부분은 1-4계층에 의존하는 넷바이오스 호출을 구현했고, 마이크로소프트가 제공한 상위 수준 부분은 하드웨어 및 프로토콜 독립적이었다. 이 넷바이오스 구현은 전체 넷바이오스 API를 지원했지만, IBM의 표준 인터럽트 0x5C 대신 X86 인터럽트 0x2A를 호출하여 사용되었다. 넷바이오스 부품 구현에 OEM에 의존하는 것은 불행히도 다른 OEM 버전의 MS-Net과 넷바이오스가 일반적으로 서로 통신할 수 없다는 부작용을 낳았다.
1986년 노벨은 자체 넷바이오스 API 에뮬레이션을 특징으로 하는 고급 노벨 넷웨어 2.0을 출시했다. 이 서비스는 IPX/SPX 상의 넷바이오스 (NBX) 프로토콜을 사용하여 넷웨어의 IPX/SPX 프로토콜 내에 캡슐화되었다.
1987년, TCP 및 UDP 패킷 위에 넷바이오스 서비스를 제공하는 방법인 TCP/IP 상의 넷바이오스 (NBT)가 발표되었다. 이는 RFC 1001 ("TCP/UDP 전송상의 넷바이오스 서비스에 대한 프로토콜 표준: 개념 및 방법") 및 RFC 1002 ("TCP/UDP 전송상의 넷바이오스 서비스에 대한 프로토콜 표준: 상세 사양")에 설명되어 있다. NBT 프로토콜은 "TCP/IP 프로토콜 스위트를 사용할 수 있는 거의 모든 유형의 시스템에 [넷바이오스 응용 프로그램] 구현을 구축할 수 있도록" 하고 "인터넷에서 넷바이오스 상호 운용을 허용"하기 위해 개발되었다.
1987년 PS/2 컴퓨터가 출시된 후, IBM은 넷바이오스 API를 제공하는 드라이버를 포함한 PC LAN 지원 프로그램을 출시했다. NBF 프로토콜은 윈도우 2000까지 거의 모든 윈도우 버전에서 마이크로소프트에 의해 공식적으로 지원되었지만, NBT 개발 이후 사용이 빠르게 감소했다. 마이크로소프트는 윈도우 XP부터 공식적으로 지원을 중단했지만, 윈도우 XP CD-ROM에 포함되어 있어 수동으로 설치할 수 있다. 윈도우 비스타는 넷BEUI (NBF를 의미) 지원을 전혀 포함하지 않지만, 윈도우 XP 넷BEUI 지원 드라이버를 사용할 수 있다.
넷바이오스와 넷BEUI 이름 사이에는 혼란이 있다. 넷BEUI는 원래 IBM의 1985년 토큰링용 향상된 넷바이오스 에뮬레이터의 명칭으로 엄밀하게 사용되었다. 당시 다른 회사들의 넷바이오스 구현은 토큰링 에뮬레이터에 있는 API 확장 기능을 포함했는지 여부와 관계없이 단순히 넷바이오스로 알려졌다는 점을 고려할 때, 넷BEUI라는 이름은 거기서 사라졌어야 했다. 그러나 MS-Net의 경우 마이크로소프트는 NBF 프로토콜의 자체 구현을 "넷BEUI"라고 명명했는데, 이는 전송 프로토콜의 구현 이름을 IBM의 향상된 API 버전의 이름을 따서 지은 것이다. 결과적으로 이더넷을 통한 마이크로소프트 파일 및 프린터 공유는 종종 넷BEUI로 계속 불리며, 넷바이오스라는 이름은 일반적으로 TCP/IP를 통한 파일 및 프린터 공유를 언급할 때만 사용된다. 더 정확하게 말하면, 전자는 넷바이오스 프레임 (NBF)이고 후자는 TCP/IP 상의 넷바이오스 (NBT)이다.
NBF 프로토콜은 라우팅 불가능하므로 동일한 브로드캐스트 도메인 내의 장치와만 통신할 수 있지만, 브리징 가능하므로 브리지를 통해 서로 연결된 네트워크 세그먼트와도 통신할 수 있다. 라우팅 가능한 네트워크를 지원하지 않는다는 것은 NBF가 소규모에서 중규모 네트워크에만 적합하며, TCP/IP보다 구성이 거의 필요 없는 장점이 있다는 것을 의미한다. 넷바이오스/넷BEUI 서비스는 인터넷워크에서 사용되려면 IPX 및 TCP/IP와 같은 다른 프로토콜 위에 구현되어야 한다.
IBM의 기술 참조서에 처음 발표된 이후, 넷바이오스 API 사양은 원래 LAN에서 최대 80대의 PC만 지원했음에도 불구하고 업계에서 사실상 표준이 되었다. 이 제한은 일반적으로 NBF에서 NBT로의 전환을 통해 업계 전반에 걸쳐 극복되었는데, 예를 들어 마이크로소프트는 이전에 윈도우 클라이언트-서버 네트워크에서 해당 이름을 확인하기 위해 LAN 세그먼트 분할 NBF 프로토콜 자체를 사용했었지만, NBT에서는 넷바이오스 호스트명 확인을 위해 도메인 네임 시스템 (DNS)으로 전환할 수 있었다.
넷바이오스는 세 가지 고유한 서비스를 제공한다.
(참고: 상위 계층인 SMB는 세션 서비스 및 데이터그램 서비스 위에 실행되는 서비스이며, 넷바이오스 자체의 필수적이고 통합된 부분으로 혼동해서는 안 된다. 이제 각 SMB 메시지에 길이 필드를 추가하는 작은 적응 계층을 사용하여 TCP 위에서 실행될 수 있다. 이는 TCP가 메시지 경계에 대한 개념 없이 바이트 스트림 서비스만 제공하기 때문에 필요하다.)
세션을 시작하거나 데이터그램을 배포하려면 응용 프로그램은 이름 서비스를 사용하여 넷바이오스 이름을 등록해야 한다. 넷바이오스 이름은 길이가 16옥텟이며 특정 구현에 따라 달라진다. 일반적으로 16번째 옥텟은 넷바이오스 접미사라고 불리며 리소스 유형을 지정하고 시스템이 제공하는 서비스 유형을 다른 응용 프로그램에 알리는 데 사용될 수 있다. NBT에서 이름 서비스는 UDP 포트 137에서 작동한다 (TCP 포트 137도 사용될 수 있지만 드물다).
넷바이오스에서 제공하는 이름 서비스 기본 요소는 다음과 같다.
인터넷 프로토콜 버전 6 (IPv6)는 넷바이오스 이름 확인 프로토콜에서 지원되지 않는다.
데이터그램 모드는 비연결 방식이다. 응용 프로그램은 오류 감지 및 복구를 담당한다. NBT에서 데이터그램 서비스는 UDP 포트 138에서 실행된다.
넷바이오스에서 제공하는 데이터그램 서비스 기본 요소는 다음과 같다.
세션 모드를 사용하면 두 컴퓨터가 연결을 설정하고, 메시지가 여러 패킷에 걸쳐 전송될 수 있으며, 오류 감지 및 복구를 제공한다. NBT에서 세션 서비스는 TCP 포트 139에서 실행된다.
넷바이오스에서 제공하는 세션 서비스 기본 요소는 다음과 같다.
PC 네트워크에서 넷바이오스 서비스를 구현하는 데 사용된 원래 프로토콜에서 세션을 설정하기 위해 시작 컴퓨터는 열기 요청을 보내고, 이는 열기 승인으로 응답된다. 세션을 시작한 컴퓨터는 세션 요청 패킷을 보내고, 이는 세션 수락 또는 세션 거부 패킷을 유도한다.
설정된 세션 중에 전송된 각 패킷은 긍정 응답 (ACK) 또는 부정 응답 (NAK)으로 응답된다. NAK는 데이터의 재전송을 유도한다. 세션은 시작하지 않은 컴퓨터가 닫기 요청을 보내 닫는다. 세션을 시작한 컴퓨터는 닫기 응답으로 회신하고, 이는 최종 세션 닫힘 패킷을 유도한다.
넷바이오스가 인터넷 프로토콜 (예: NBT)과 함께 실행될 때, 각 컴퓨터는 여러 이름을 가질 수 있다. 하나 이상의 넷바이오스 이름 서비스 이름과 하나 이상의 인터넷 호스트 이름이다.
넷바이오스 이름은 16개의 ASCII 문자이지만, 마이크로소프트는 호스트 이름을 15자로 제한하고 16번째 문자를 넷바이오스 접미사로 예약한다. 이 접미사는 호스트 레코드, 마스터 브라우저 레코드 또는 도메인 컨트롤러 레코드와 같은 서비스 또는 이름 레코드 유형을 설명한다. 호스트 이름 (또는 짧은 호스트 이름)은 윈도우 네트워킹을 설치/구성할 때 지정되며, 등록된 접미사는 호스트가 제공하는 개별 서비스에 의해 결정된다. 넷바이오스 이름을 통해 TCP/IP를 실행하는 컴퓨터에 연결하려면 이름이 네트워크 주소로 확인되어야 한다. 오늘날 이것은 일반적으로 IP 주소이다 (넷바이오스 이름을 IP 주소로 확인하는 것은 종종 브로드캐스트 또는 WINS 서버 – 넷바이오스 이름 서버 –에 의해 수행된다). 컴퓨터의 넷바이오스 이름은 종종 해당 컴퓨터의 호스트 이름 (아래 참조)과 같지만, 15자로 잘리며, 완전히 다를 수도 있다.
넷바이오스 이름은 영숫자 문자 시퀀스이다. 다음 문자는 명시적으로 허용되지 않는다. \/:*?"<>|. 윈도우 2000 이후 넷바이오스 이름은 DNS 이름에 대한 제한도 준수해야 했다. 즉, 모두 숫자로만 구성될 수 없으며, 하이픈 ("-") 또는 마침표 (".") 문자는 첫 글자 또는 마지막 글자로 나타날 수 없다. 윈도우 2000 이후 마이크로소프트는 넷바이오스 이름에 마침표 (".") 문자를 포함하지 않도록 권고했는데, 이는 응용 프로그램이 마침표의 존재를 사용하여 도메인 이름과 넷바이오스 이름을 구별할 수 있도록 하기 위함이다.
윈도우 LMHOSTS 파일은 WINS 서버를 사용하지 않는 소규모 네트워크에 사용할 수 있는 넷바이오스 이름 확인 방법을 제공한다.
윈도우 기기의 넷바이오스 이름은 컴퓨터의 인터넷 호스트 이름과 혼동해서는 안 된다 (이 컴퓨터가 넷바이오스 노드 외에 인터넷 호스트이기도 하다는 가정 하에, 반드시 그럴 필요는 없지만). 일반적으로 인터넷 프로토콜을 실행하는 컴퓨터 (윈도우 기기이든 아니든)는 일반적으로 호스트 이름 (때로는 기기 이름이라고도 함)을 갖는다. 원래 이러한 이름은 호스트 파일에 저장되고 제공되었지만, 오늘날 대부분의 이름은 계층적 도메인 네임 시스템 (DNS)의 일부이다.
일반적으로 윈도우 컴퓨터의 호스트 이름은 넷바이오스 이름과 주 DNS 접미사를 기반으로 하며, 이 둘은 시스템 속성 대화 상자에서 설정된다. 또한 제어판 → 네트워크 → TCP/IP → 고급 속성의 DNS 탭에서 보거나 변경할 수 있는 연결별 접미사가 있을 수 있다. 호스트 이름은 응용 프로그램 (예: 텔넷, FTP, 웹 브라우저 등)에서 사용된다. 이름을 사용하여 TCP/IP 프로토콜을 실행하는 컴퓨터에 연결하려면 호스트 이름이 IP 주소로 확인되어야 하며, 일반적으로 DNS 서버에서 수행된다. (위에서 나열된 세 가지를 포함하여 많은 TCP/IP 기반 응용 프로그램을 IP 주소만 사용하여 작동하는 것도 가능하지만, 이는 일반적이지 않다.)
윈도우에서 네트워크로 연결된 컴퓨터의 노드 유형은 넷바이오스 이름을 IP 주소로 확인하는 방식과 관련이 있다. 이는 넷바이오스 노드에 IP 주소가 있다는 것을 전제로 하며, 이는 넷바이오스가 NBT를 통해 작동할 때만 보장된다. 따라서 노드 유형은 넷바이오스 자체의 속성이 아니라 윈도우 OS 환경에서 넷바이오스와 TCP/IP 간의 상호 작용 속성이다. 네 가지 노드 유형이 있다.
사용 중인 노드 유형은 명령줄을 열고 ipconfig /all을 입력하면 표시된다. 윈도우 컴퓨터 레지스트리는 노드 유형에 "알 수 없음"이 표시되도록 구성될 수도 있다.
넷바이오스 접미사(NetBIOS Suffix), 또는 넷바이오스 끝 문자(endchar)라고도 불리는 이 접미사는 넷바이오스 이름의 16번째 문자로, 등록된 이름의 서비스 유형을 나타낸다. 레코드 유형의 수는 255개로 제한된다. 일반적으로 사용되는 일부 값은 다음과 같다.
고유 이름의 경우:
그룹 이름의 경우:
다음 표는 넷바이오스와 관련 프로토콜의 간략한 역사를 보여준다. SMB는 넷바이오스를 사용하는 주요 프로토콜이었다. SMB는 윈도우 파일 및 프린터 공유를 가능하게 한다.
| 7 | 응용 계층 | Windows Chat, 클립북 뷰어, 하트 (윈도우) | SMB | SMB | SMB | SMB | SMB | |
| 6 | 표현 계층 | NetDDE | ||||||
| 5 | 세션 계층 | 넷바이오스 (원래 "네트워크 기본 입출력 시스템") | 넷바이오스 프레임 (윈도우에서 "NetBEUI"로 잘못 표기됨) | IPX/SPX 상의 넷바이오스 | TCP/IP 상의 넷바이오스 | |||
| 4 | 전송 계층 | IPX/SPX | TCP/UDP | TCP/UDP | QUIC (over UDP) | |||
| 3 | 네트워크 계층 | IPX | IP | IP | IP | |||
| 2 | 데이터 링크 계층 | 이더넷, 토큰링 상의 IEEE 802.2 | IPX를 전달하는 모든 링크 | IP를 전달하는 모든 링크 | IP를 전달하는 모든 링크 | IP를 전달하는 모든 링크 | ||
| 1 | 물리 계층 | IBM PC 네트워크 | 이더넷, 토큰링 | |||||
| 최초 지원 | Windows for Workgroups 3.1 | Windows for Workgroups 3.1 | 윈도우 NT 3.5 | 윈도우 2000 | Windows 11 (서버 측은 Windows Server 2022 Datacenter: Azure Edition 필요) | |||
| 마지막 지원 | 윈도우 XP (수동 설치 필요) | 윈도우 XP | ||||||
Because the NetBIOS protocol, defined in [RFC1002], does not support the mapping between NetBIOS names and IPv6 addresses, the Remote Administrative Interface: WINS protocol applies only to IPv4 addresses. It does not apply to IPv6 addresses.
