윈속

3. 기술

윈속 API 사양은 API와 SPI 두 가지 인터페이스를 정의한다. API는 응용 프로그램 개발자가 사용하며, SPI는 네트워크 소프트웨어 개발자가 새로운 프로토콜 모듈을 시스템에 추가할 수 있도록 한다. API는 적합한 응용 프로그램이 모든 네트워크 소프트웨어 공급업체의 적합한 프로토콜 구현과 함께 올바르게 작동하도록 보장한다. SPI는 적합한 프로토콜 모듈이 Windows에 추가되어 API 호환 응용 프로그램에서 사용될 수 있도록 보장한다. 이러한 계약은 Windows Sockets 초기 출시 당시 다중 프로토콜 지원이 필요했기 때문에 중요했지만, 현재는 학문적인 관심사일 뿐이다.^[1]

Windows Sockets 코드는 BSD 소켓을 기반으로 하지만, API가 일반적인 Windows 프로그래밍 모델을 준수하도록 추가 기능을 제공한다. Windows Sockets API는 BSD 소켓 API의 거의 모든 기능을 다루었지만, Windows와 Unix 간의 근본적인 차이로 인해 몇 가지 피할 수 없는 차이점이 존재한다.

Windows Sockets의 설계 목표 중 하나는 개발자가 소켓 기반 응용 프로그램을 Unix에서 Windows로 비교적 쉽게 이식할 수 있도록 하는 것이었다. 이를 위해 Windows Sockets에는 이식을 용이하게 하기 위한 여러 요소가 포함되었다. 예를 들어, Unix 응용 프로그램은 동일한 `errno` 변수를 사용하여 네트워킹 오류와 표준 C 라이브러리 함수 내에서 감지된 오류를 기록할 수 있었다. Windows에서는 이것이 불가능했기 때문에, Windows Sockets는 오류 정보를 검색하는 전용 함수 `WSAGetLastError()`를 도입했다.

초기 마이크로소프트의 운영 체제(MS-DOS와 Windows 모두)는 네트워크 기능이 빈약하여, NetBIOS/NetBEUI를 주로 사용했다. 이는 계층화되지 않은, 라우팅 불가능한 네트워크 기능으로, IBM의 NetBIOS를 마이크로소프트가 구현한 것이었다. 특히 당시, 마이크로소프트는 TCP/IP를 완전히 무시했다. 여러 대학 그룹(MIT)과 상용 벤더(썬 마이크로시스템즈 등)가 MS-DOS용 TCP/IP를 개발하여 하드웨어에 함께 제공하는 방식으로 판매했다. Windows가 출시되면서, Windows용 TCP/IP를 제공하는 벤더가 더욱 늘어났다. 그러나, 마이크로소프트는 여전히 기능이 빈약한 제품을 제공했다.

이들 벤더 제품의 약점은 각자 독자적인 API를 채택했다는 점이다. 또한, 메모리 사용량(당시, 640KB도 대용량으로 여겨졌다)과, 여러 프로토콜을 병행하여 지원하는 방법이 없다는 점도 문제였다. 특히 마지막 문제점이 중요했다. 당시의 네트워크 환경은 벤더마다 달랐고(예를 들어, DEC의 DECnet, 노벨의 Netware, Banyan Vines, IBM Lan Manager 등), 각자 다른 프로토콜을 사용했다(예를 들어, 노벨은 IPX/SPX, IBM은 NetBIOS API 기반 프로토콜, 마이크로소프트는 NetBEUI Frames Protocol). 따라서, 사용자가 여러 네트워크 서비스에 접속하려면, 여러 부팅 구성을 준비하고, 사용하려는 서비스에 맞춰 재시작하여, 해당 프로토콜을 사용할 수 있도록 해야 했다. 게다가 프로그래밍 모델이 통일되지 않아, 임의의 벤더의 TCP/IP 구현에서 작동하는 네트워크 애플리케이션 개발은 매우 어려웠다. 어떤 종류의 "표준화"가 필요하다는 것은 분명했다.

Windows 소켓은 버클리의 소켓을 기반으로 하지만, Windows의 표준 프로그래밍 모델에 대응하기 위해 기능을 추가했다. Winsock은 소켓의 대부분의 기능을 커버하고 있지만, Windows와 UNIX의 근본적인 차이로 인해 어쩔 수 없이 생기는 차이도 존재한다 (그렇다고 해도, STREAMS와의 차이에 비하면 훨씬 소켓에 가깝다). API에 포함된 모든 함수명 앞에는 `WSA`가 붙는다. 예를 들어, 호스트명 참조의 `WSAGetHostByName()` 등이다. BSD 소켓으로부터의 확장으로 특기할 만한 것은, "비동기 소켓" 및 오버랩 I/O를 이용한 "오버랩 소켓"이다. 비동기 버전의 함수는, 접두사로 `WSAAsync`를 붙여, `WSAAsyncGetHostByName()` 등과 같은 이름으로 되어 있으며, Windows의 윈도우 메시지를 통해 결과를 통지한다. 비동기 처리의 취소는 `WSACancelAsyncRequest()`로 실행한다. 오버랩 소켓은 완료 통지에 `WSAEVENT` 객체와 `WSAOVERLAPPED` 구조체를 사용한다. 또한, Winsock의 비동기 소켓이나 오버랩 소켓은, BSD의 논블로킹 소켓과는 다른 개념이다. 블로킹 모드의 `send()` 및 `recv()`의 타임아웃 시간을 설정하는 소켓 옵션 `SO_SNDTIMEO` 및 `SO_RCVTIMEO`를 사용하려면, 소켓 생성 시에 `WSA_FLAG_OVERLAPPED` 속성이 설정되어 있어야 한다^[6]。Winsock2에서는, 소켓은 기본적으로 블로킹 모드로 생성된다^[7]。또한 BSD 호환의 `socket()` 함수를 사용하여 생성된 소켓은, 기본적으로 `WSA_FLAG_OVERLAPPED` 속성을 가진다^[8]。

4. 사양

윈속의 주요 버전별 특징과 변경 사항은 다음과 같다.

Windows 2000용 IPv6 기술 미리 보기 (2000년 12월)에서 이름 확인을 위한 프로토콜 독립적인 API인 RFC 2553 (1999년 3월, 나중에 RFC 3493에 의해 대체됨)의 첫 번째 구현이 이루어졌으며, 이는 Windows XP에서 윈속의 일부가 되었다.

5. 윈도우 8의 업데이트

윈도우 8은 윈속에 "RIO"(Registered IO) 확장 기능을 추가했다.^[2] 이 기능은 네트워크 데이터 경로 및 알림 경로에서 사용자 모드와 커널 모드 간 전환 오버헤드를 줄이도록 설계되었다. 다만, 기존 네트워크 카드를 사용하는 일반적인 Windows TCP 및 UDP 스택은 그대로 사용한다. 설정 경로(예: "connect" 함수)는 일반적인 윈속 경로와 동일하게 유지된다.

6. 구현

MS-DOS 및 초기 마이크로소프트 윈도우 운영 체제는 NetBIOS를 기반으로 제한적인 네트워킹 기능을 제공했으며, 당시 TCP/IP 프로토콜 스택을 지원하지 않았다. 여러 대학 그룹과 상용 벤더들이 MS-DOS용 TCP/IP 제품을 출시했고, 윈도우 2.0 출시 이후 Windows용 TCP/IP를 제공하는 벤더들이 늘어났다. 그러나 각 벤더들은 고유한 API를 사용했기 때문에, 표준화된 프로그래밍 모델의 필요성이 제기되었다.

1991년 10월, Windows Sockets 프로젝트가 시작되었고, NetManage의 소켓 사양을 기반으로 했다.^[1] 첫 번째 사양은 Martin Hall, Mark Towfiq, Geoff Arnold, Henry Sanders, J Allard 등이 작성했다. 저작권 문제는 개인 저작권으로 결정되었다. 초기에는 Winsock이라는 이름을 사용하는 것을 꺼렸는데, 이는 사용자들이 DLL 파일(winsock.dll)의 존재만으로 완전한 TCP/IP 지원을 제공한다고 오해할 수 있었기 때문이다.

초기 마이크로소프트 운영 체제는 네트워크 기능이 빈약하여 NetBIOS/NetBEUI를 주로 사용했고, TCP/IP는 지원하지 않았다. 여러 대학 및 상용 벤더들이 MS-DOS 및 Windows용 TCP/IP 제품을 개발했지만, 여전히 마이크로소프트는 기능이 부족한 제품을 제공했다.

벤더 제품들은 독자적인 API를 사용했고, 메모리 사용량과 여러 프로토콜 동시 지원 문제도 있었다. 당시 네트워크 환경은 벤더마다 달랐고, 각자 다른 프로토콜을 사용했기 때문에, 사용자는 여러 네트워크 서비스에 접속하기 위해 복잡한 설정을 해야 했다. 프로그래밍 모델도 통일되지 않아 네트워크 애플리케이션 개발이 어려웠다.

PC 네트워크 분야에서는 이미 여러 표준화가 진행되었다. 과 는 TCP/IP 상의 NetBIOS 구현인 '''NBT'''(NetBIOS over TCP/IP)를 정의했다. [http://crynwr.com/ Crynwr packet driver]는 어셈블리 언어로 구현되어 메모리 사용량 문제를 해결하고 여러 프로토콜 동시 지원을 가능하게 했다. 노벨의 ODI, 마이크로소프트의 NDIS와 같은 API도 있었지만, 이들은 완전한 TCP/IP 구현이 아니었다.

Windows Sockets API는 JSB Software의 Martin Hall이 제안했고, 1991년 10월 CompuServe의 전자 게시판에서 논의가 시작되었다. 저작권 및 지적 재산권에 대한 논의 끝에, 저작권은 5명이 각각 소유하는 것으로 결정되었다.

윈속의 구체적인 구현 사례들은 다음과 같다.

6. 1. 마이크로소프트 구현

• 마이크로소프트는 윈속 1.0의 구현을 제공하지 않았다.
• 윈속 버전 1.1은 코드명 '''Snowball'''로 불린 Windows for Workgroups의 애드온 패키지(Wolverine)로 제공되었다. 이는 윈도우 95와 버전 3.5 이후의 윈도우 NT의 필수 구성 요소였다.
• 윈속 버전 2.1은 윈도우 95용 애드온 패키지로 제공되었다^[9]. 이는 윈도우 98, 윈도우 NT 4.0 및 모든 후속 Windows 릴리스의 필수 구성 요소였다. 마이크로소프트는 윈도우 3.x 또는 윈도우 NT 3.x용 윈속 2의 구현을 제공하지 않았다.
• 최신 버전의 윈속 2.x는 새로운 Windows 릴리스와 함께 또는 서비스 팩의 일부로 제공되었다.
• 윈속 2는 계층화된 서비스 공급자(LSP)라는 메커니즘을 통해 확장 가능하다. 윈속 LSP는 인터넷 자녀 보호, 웹 콘텐츠 필터링, QoS 등 광범위한 유용한 목적으로 사용할 수 있다. 모든 공급자의 계층 순서는 윈속 카탈로그에 보관된다. 이전 버전의 Windows에서는 버그가 있는 LSP를 제거하면 레지스트리의 윈속 카탈로그가 손상되어 ''모든 네트워크 연결''이 손실될 수 있었다. 윈도우 XP 서비스 팩 2, 윈도우 서버 2003 서비스 팩 1 및 모든 이후 Windows 운영 체제의 윈속은 사용자가 그러한 LSP를 제거한 후 자체 복구할 수 있는 기능을 갖추고 있다.

6. 2. 기타 구현

7. 같이 보기

• (NDIS)
• 윈속 커널
• 윈도우 필터링 플랫폼

참조

_[1] 웹사이트 Winsock Version 1.0 Rev.A https://www-user.tu-[...] 2020-10-08
_[2] 웹사이트 New techniques to develop low-latency network apps http://channel9.msdn[...]
_[3] 웹사이트 Mosaic turns 20: Let's fire up the old girl, show her the web today https://www.theregis[...]
_[4] 웹사이트 What It Was Like To Build A World Wide Web Site In 1995 https://www.fastcomp[...] 2015-11-18
_[5] 웹사이트 Downloads http://www.trumpet.c[...]
_[6] 문서 SOL_SOCKET Socket Options (Winsock2.h) - Win32 apps | Microsoft Docs https://docs.microso[...]
_[7] 문서 Blocking Input/Output - Win32 apps | Microsoft Docs https://docs.microso[...]
_[8] 문서 Default State for a Socket's Overlapped Attribute - Win32 apps | Microsoft Docs https://docs.microso[...]
_[9] 웹사이트 Windows 95 用の Windows Sockets 2.0 について https://support.micr[...] 2007-05-28
_[10] 문서 Tattam Software Enterprises 公式サイト http://www.trumpet.c[...]