Спецификация Windows Sockets: API для работы с TCP/IP

Введение

Техническая спецификация, определяющая поведение программного обеспечения Windows при работе по протоколу TCP/IP.

В вычислительной технике Windows Sockets API (WSA), впоследствии сокращенный до Winsock, — это интерфейс программирования приложений (API), который определяет, как программное обеспечение сетевых приложений Windows должно обращаться к сетевым службам, в частности, к TCP/IP. Он определяет стандартный интерфейс между клиентским приложением Windows, использующим TCP/IP (например, FTP-клиентом или веб-браузером), и базовым стеком протоколов TCP/IP. Терминология основана на API Berkeley sockets, используемом в BSD для организации взаимодействия между программами.

Предыстория

Ранние операционные системы Microsoft, как MS-DOS, так и Microsoft Windows, предлагали ограниченные сетевые возможности, главным образом основанные на NetBIOS. В частности, Microsoft не предоставляла поддержку стека протоколов TCP/IP в то время. Ряд университетских групп и коммерческих поставщиков, включая группу PC/IP в MIT, FTP Software, Sun Microsystems, Ungermann Bass и Excelan, представили продукты TCP/IP для MS-DOS, часто в составе аппаратного и программного комплекта. Когда была выпущена Windows 2.0, к этим поставщикам присоединились другие, такие как Distinct и NetManage, предлагающие TCP/IP для Windows. Недостатком всех этих поставщиков было то, что каждый из них использовал свой собственный API (интерфейс программирования приложений). Без единой стандартной модели программирования было сложно убедить независимых разработчиков программного обеспечения создавать сетевые приложения, которые работали бы с базовой реализацией TCP/IP любого поставщика. К этому добавьте опасения конечных пользователей оказаться привязанными к одному поставщику, и стало ясно, что необходима некоторая стандартизация. Проект Windows Sockets берет свое начало в сессии "Birds Of A Feather", прошедшей на Interop '91 в Сан-Хосе 10 октября 1991 года. Он основан на спецификациях сокетов, созданных NetManage, которые были переданы в общественное достояние на этой встрече. В то время сокет NetManage был единственным 100% DLL-ориентированным, многопоточным продуктом для Windows 3.0. Первое издание спецификации было разработано Мартином Холлом, Марком Товфиком из Microdyne (позже Sun Microsystems), Джеффом Арнольдом из Sun Microsystems, Генри Сандерсом и Дж. Аллардом из Microsoft, при участии многих других. Обсуждались вопросы авторского права, интеллектуальной собственности и потенциальных антимонопольных проблем, а также рассматривалась возможность работы через IETF или создания некоммерческого фонда. В итоге было решено, что спецификация будет просто защищена авторским правом пятью авторами как частными лицами (не связанными между собой). Все участвующие разработчики долгое время сопротивлялись сокращению названия до простого Winsock, поскольку это вызывало путаницу среди пользователей между API и файлом библиотеки DLL (winsock.dll), который предоставлял приложениям только общие интерфейсы WSA. Пользователи часто полагали, что простое наличие файла DLL в системе обеспечит полную поддержку протокола TCP/IP.

Early Microsoft operating systems, both MS DOS and Microsoft Windows, offered limited networking capability, chiefly based on NetBIOS. In particular, Microsoft did not offer support for the TCP/IP protocol stack at that time. A number of university groups and commercial vendors, including the PC/IP group at MIT, FTP Software, Sun Microsystems, Ungermann Bass, and Excelan, introduced TCP/IP products for MS DOS, often as part of a hardware/software bundle. When Windows 2.0 was released, these vendors were joined by others such as Distinct and NetManage in offering TCP/IP for Windows. The drawback faced by all of these vendors was that each of them used their own API (Application Programming Interface). Without a single standard programming model, it was difficult to persuade independent software developers to create networking applications which would work with any vendor's underlying TCP/IP implementation. Add to this the fact that end users were wary of getting locked into a single vendor and it became clear that some standardization was needed. The Windows Sockets project had its origins in a Birds Of A Feather session held at Interop '91 in San Jose on October 10, 1991. It is based on socket specifications created by NetManage and which it put into public domain at this meeting. At the time the NetManage socket was the only 100% DLL based, multi threaded product for Windows 3.0 available. The first edition of the specification was authored by Martin Hall, Mark Towfiq of Microdyne (later Sun Microsystems), Geoff Arnold of Sun Microsystems, and Henry Sanders and J Allard of Microsoft, with assistance from many others. There was some discussion about how best to address the copyright, intellectual property, and potential anti trust issues, and consideration was given to working through the IETF or establishing a non profit foundation. In the end, it was decided that the specification would simply be copyrighted by the five authors as (unaffiliated) individuals. All the participating developers resisted the shortening of the name to simple Winsock for a long time, since there was much confusion among users between the API and the DLL library file (winsock. dll) which only exposed the common WSA interfaces to applications above it. Users would commonly believe that only making sure the DLL file was present on a system would provide full TCP/IP protocol support.

Технология

Спецификация Windows Sockets API определяет два интерфейса: API, используемый разработчиками приложений, и SPI, который предоставляет разработчикам сетевого программного обеспечения возможность добавлять новые модули протоколов в систему. Каждый интерфейс представляет собой соглашение. API гарантирует, что соответствующее приложение будет корректно работать с соответствующей реализацией протокола от любого поставщика сетевого программного обеспечения. Соглашение SPI гарантирует, что соответствующий модуль протокола может быть добавлен в Windows и, таким образом, станет доступен для приложений, совместимых с API. Хотя эти соглашения были важны при первом выпуске Windows Sockets, поскольку сетевые среды требовали поддержки нескольких протоколов (см. выше), теперь они представляют лишь академический интерес. В Windows Sockets API версии 2.0 включены функции для использования IPX/SPX, хотя протокол уже практически устарел к моменту выпуска WSA 2.0. Microsoft поставляет стек протоколов TCP/IP со всеми последними версиями Windows, и существенных независимых альтернатив не существует. Также не было значительного интереса к реализации протоколов, отличных от TCP/IP. Код и архитектура Windows Sockets основаны на BSD-сокетах, но предоставляют дополнительную функциональность, позволяющую API соответствовать стандартной модели программирования Windows. API Windows Sockets охватывал почти все возможности API BSD-сокетов, но существовали некоторые неизбежные препятствия, в основном связанные с фундаментальными различиями между Windows и Unix (хотя Windows Sockets отличался от BSD-сокетов меньше, чем последние от STREAMS). Все вызовы функций в API начинаются с префикса, например, для отправки данных через подключенный сокет. Однако одной из целей разработки Windows Sockets было обеспечение относительной простоты переноса сокетных приложений из Unix в Windows. Создание API, полезного только для новых программ Windows, считалось недостаточным. Поэтому Windows Sockets включал ряд элементов, предназначенных для облегчения переноса. Например, приложения Unix могли использовать одну и ту же переменную для регистрации как сетевых ошибок, так и ошибок, обнаруженных в стандартных функциях библиотеки C. Поскольку это было невозможно в Windows, Windows Sockets представил специальную функцию для получения информации об ошибках. Такие механизмы были полезны, но перенос приложений оставался чрезвычайно сложным. Многие оригинальные приложения TCP/IP были реализованы с использованием системных функций, специфичных для Unix, таких как псевдотерминалы и системный вызов fork, и воспроизведение такой функциональности в Windows было проблематичным. В относительно короткий срок перенос уступил место разработке специализированных приложений для Windows.

The Windows Sockets API specification defines two interfaces: the API used by application developers, and the SPI, which provides a means for network software developers to add new protocol modules to the system. Each interface represents a contract. The API guarantees that a conforming application will function correctly with a conforming protocol implementation from any network software vendor. The SPI contract guarantees that a conforming protocol module may be added to Windows and will thereby be usable by an API compliant application. Although these contracts were important when Windows Sockets was first released, since network environments required multi protocol support (see above) they are now of only academic interest. Included in the Windows Sockets API version 2.0 are functions to use IPX/SPX, although the protocol was all but obsolete already at the time WSA 2.0 shipped. Microsoft has shipped the TCP/IP protocol stack with all recent versions of Windows, and there are no significant independent alternatives. Nor has there been significant interest in implementing protocols other than TCP/IP. Windows Sockets code and design are based on BSD sockets, but provides additional functionality to allow the API to comply with the regular Windows programming model. The Windows Sockets API covered almost all the features of the BSD sockets API, but there were some unavoidable obstacles which mostly arose out of fundamental differences between Windows and Unix (though Windows Sockets differed less from BSD sockets than the latter did from STREAMS). All function calls in the API begin with the moniker , e. g. for sending data on a connected socket. However it was a design goal of Windows Sockets that it should be relatively easy for developers to port socket based applications from Unix to Windows. It was not considered sufficient to create an API which was only useful for newly written Windows programs. For this reason, Windows Sockets included a number of elements which were designed to facilitate porting. For example, Unix applications were able to use the same variable to record both networking errors and errors detected within standard C library functions. Since this was not possible in Windows, Windows Sockets introduced a dedicated function, , to retrieve error information. Such mechanisms were helpful, but application porting remained extremely complex. Many original TCP/IP applications had been implemented by using system features specific to Unix, such as pseudo terminals and the fork system call, and reproducing such functionality in Windows was problematic. Within a relatively short time, porting gave way to the development of dedicated Windows applications.

Технические характеристики

Версия 1.0 (июнь 1992) определила базовую работу Winsock. Она была максимально приближена к существующему интерфейсу сокетов Berkeley для упрощения переноса существующих приложений. Было добавлено несколько расширений, специфичных для Windows, в основном для асинхронных операций с уведомлениями, основанными на сообщениях. Хотя документ не ограничивал поддержку TCP/IP, только TCP и UDP были явно упомянуты как поддерживаемые протоколы. Большинство поставщиков предоставляли только поддержку TCP/IP, хотя Winsock от DEC также включал поддержку DECNet. Версия 1.1 (январь 1993) содержала множество незначительных исправлений и уточнений спецификации. Наиболее значительным изменением было включение функции. Winsock 2 являлся расширением Winsock 1.1 с обратной совместимостью. Он добавил поддержку независимого от протокола разрешения имен, асинхронных операций с уведомлениями, основанными на событиях, и процедурами завершения, многоуровневых реализаций протоколов, многоадресной рассылки (multicasting) и качества обслуживания (QoS). Также была формализована поддержка нескольких протоколов, включая IPX/SPX и DECnet. Новая спецификация позволяла сокетам опционально использоваться совместно между процессами, условно принимать входящие запросы на соединение, а также выполнять определенные операции над группами сокетов, а не над отдельными сокетами. Несмотря на существенные отличия от Winsock 1, новая спецификация обеспечивала совместимость на уровне исходного кода и бинарного кода с API Winsock 1.1. Одним из менее известных дополнений был API интерфейса поставщика услуг (SPI) и поставщики услуг на уровне слоев. Версии 2.0.x (с мая 1994 года) имели статус внутреннего проекта и не были объявлены как публичные стандарты. Версия 2.1.0 (январь 1996) стала первым публичным выпуском спецификации Winsock 2. Версия 2.2.0 (май 1996) включала множество незначительных исправлений, уточнений и рекомендаций по использованию. Она также стала первой версией, отказавшейся от поддержки 16-битных приложений Windows. Версии 2.2.1 (май 1997) и 2.2.2 (август 1997) внесли незначительные улучшения в функциональность. Были добавлены механизмы для запроса и получения уведомлений об изменениях в конфигурации сети и системы. В техническом превью IPv6 для Windows 2000 (декабрь 2000) была впервые реализована RFC 2553 (март 1999, позже заменена RFC 3493), API для разрешения имен, независимый от протокола, который впоследствии стал частью Winsock в Windows XP.

Version 1.0 (June 1992) defined the basic operation of Winsock. It was kept very close to the existing interface of Berkeley sockets to simplify porting of existing applications. A few Windows specific extensions were added, mainly for asynchronous operations with message based notifications. Although the document didn't limit support to TCP/IP, TCP and UDP were the only protocols explicitly mentioned. Most vendors only delivered TCP/IP support, although Winsock from DEC included DECNet support as well. Version 1.1 (January 1993) made many minor corrections and clarifications of the specification. The most significant change was the inclusion of the function. Winsock 2 was a backwards compatible extension of Winsock 1.1. It added support for protocol independent name resolution, asynchronous operations with event based notifications and completion routines, layered protocol implementations, multicasting, and quality of service. It also formalized support for multiple protocols, including IPX/SPX and DECnet. The new specification allowed sockets to be optionally shared between processes, incoming connection requests to be conditionally accepted, and certain operations to be performed on socket groups rather than individual sockets. Although the new specification differed substantially from Winsock 1, it provided source and binary level compatibility with the Winsock 1.1 API. One of the lesser known additions was the Service Provider Interface (SPI) API and Layered Service Providers. Versions 2.0. x (May 1994 onwards) had internal draft status, and were not announced as public standards. Version 2.1.0 (January 1996) was the first public release of the Winsock 2 specification. Version 2.2.0 (May 1996) included many minor corrections, clarifications, and usage recommendations. It was also the first version to remove support for 16 bit Windows applications. Version 2.2.1 (May 1997) and Version 2.2.2 (August 1997) introduced minor functionality enhancements. Mechanisms were added for querying and receiving notification of changes in network and system configuration. The IPv6 Technical Preview for Windows 2000 (December 2000) saw the first implementation of RFC 2553 (March 1999, later obsoleted by RFC 3493), a protocol independent API for name resolution, which would become part of Winsock in Windows XP.

Обновления в Windows 8

Windows 8 включает расширения "RIO" (Registered IO) для Winsock. Эти расширения разработаны для снижения накладных расходов, связанных с переходом из пользовательского режима в режим ядра для пути передачи сетевых данных и пути уведомлений, при этом используется остальная часть стандартного стека TCP и UDP Windows (и существующие сетевые карты). Процесс настройки (например, функция "connect") остается без изменений по сравнению со стандартным путем Winsock.

Реализации Microsoft

Microsoft не поставляла реализацию Winsock 1.0. Версия 1.1 Winsock была включена в дополнительный пакет (под названием Wolverine) для Windows для рабочих групп (с кодовым названием Snowball). Она являлась неотъемлемым компонентом Windows 95 и Windows NT, начиная с версии 3.5 (первоначальная коммерчески доступная версия Windows NT, версия 3.1, включала только проприетарную и довольно неполную реализацию TCP/IP на основе API AT&T UNIX System V "STREAMS"). Версия 2.1 Winsock была включена в дополнительный пакет для Windows 95. Она являлась неотъемлемой частью Windows 98, Windows NT 4.0 и всех последующих версий Windows. (Microsoft не поставляла реализации Winsock 2 для Windows 3.x или Windows NT 3.x.) Новейшие версии Winsock 2.x поставлялись с новыми выпусками Windows или в составе пакетов обновлений. Winsock 2 расширяется с помощью механизма, известного как Layered Service Provider (LSP). Winsock LSP доступны для широкого спектра полезных целей, включая родительский контроль в Интернете, фильтрацию веб-контента, QoS и т. д. Порядок слоев всех провайдеров хранится в каталоге Winsock. В предыдущих версиях Windows удаление некорректно работающего LSP могло привести к повреждению каталога Winsock в реестре, что потенциально могло привести к потере всей сетевой связности. Winsock в Windows XP Service Pack 2, Windows Server 2003 Service Pack 1 и всех последующих операционных системах Windows обладает способностью к самовосстановлению после удаления пользователем такого LSP.

Другие варианты реализации

Среди других поставщиков, предлагавших Winsock-совместимые стеки TCP/IP и UDP/IP, были (в алфавитном порядке) 3Com, Beame & Whiteside, DEC, Distinct, Frontier, FTP Software, IBM, Microdyne, NetManage, Novell, Sun Microsystems и Trumpet Software International. Trumpet Winsock, разработанный Питером Таттамом, была одной из немногих реализаций Winsock 1.0, которые можно было установить под Windows 3.0, не имевшей встроенной поддержки Winsock. Trumpet также была самой популярной shareware-реализацией Winsock для Windows 3.x. Trumpet Winsock 5.0 доступна для Windows 95/98 и Windows NT и включает в себя стек IPv6, соответствующий Winsock 1.1, для этих операционных систем. Проект Wine содержит исходную и двоично-совместимую повторную реализацию Winsock на основе BSD API сокетов.