Winsock

title: 历史.
content: MS-DOS与早期版本的Microsoft Windows使用的网络协议是NetBIOS. 因此,各方提供了各自的MS-DOS上的TCP/IP实现。由于各种解决方案的API函数名并不统一,使得软件开发者难以下决心转到TCP/IP协议上。  1991年10月,以Martin Hall, Mark Towfiq, Geoff Arnold, Henry Sanders为首在CompuServe BBS上讨论形成了Windows Sockets API规范(specification)并且版权属于这五人。
title: 规范版本.
content: Windows 95 OSR2以后版本的Windows操作系统均支持Windows Sockets version 2.2。此外,Windows 95 with the Windows Socket 2 Update也支持WinSock 2.2。  Windows 95、Windows NT 3.51及更早版本的Windows操作系统,最高支持Windows Sockets version 1.1。
title: 技术.
content: WinSock编程时,可选择下述编程模型之一:  Windows Sockets API规范包含两种接口:  Windows Sockets的代码与设计是基于Berkeley sockets,此外还提供了额外的功能使得API遵从Windows编程模式(如重叠I/O). API函数名字都以前缀WSA开始, 例如WSASend().  为了便于从Unix向Windows移植网络程序的源代码,Winsock提供了很多便利. 例如,Unix应用程序能使用errno码记录网络错误与C运行时错误。Windows Sockets引入了专门的函数WSAGetLastError()以获取错误信息. 但很多TCP/IP应用程序使用了Unix的特性, 如伪终端与fork系统调用。这使得源代码移植非常困难。
title: 回复Ack的延时.
content: 当Microsoft TCP栈接收到一个数据包时,会启动一个200毫秒的计时器。当ACK确认数据包发出之后,计时器会复位。接收到下一个数据包时,会再次启动200毫秒的计时器。这称为TCP确认延迟机制(TCP Delayed acknowledge),作用是接收到数据后延迟ACK的发送,使得TCP协议栈有机会合并多个ACK以提高性能。Microsoft TCP栈使用了下面的策略来决定在接收到数据包后什么时候发送ACK确认数据包:
title: 发送小尺寸数据时默认采用Nagle算法拼接为大数据包.
content: 为了避免小数据包拥塞网络,Microsoft TCP栈默认启用了纳格算法,这个算法能够将应用程序多次调用Send发送的小尺寸的数据拼接起来,一块封包发送。Nagle算法规定的特殊情况:
title: Winsock的内核发送缓冲区与send函数的实现.
content: 为了在应用层优化性能,Winsock把应用程序调用Send发送的数据从应用程序的缓冲区复制到Winsock内核缓冲区。Microsoft TCP栈利用类似Nagle算法的方法,决定什么时候才实际地把数据投递到网络。内核缓冲区的默认大小是8K,使用SO_SNDBUF选项,可以改变Winsock内核缓冲区的大小。如果有必要的话,Winsock能缓冲大于SO_SNDBUF缓冲区大小的数据。在绝大多数情况下,应用程序完成Send调用仅仅表明数据 被复制到了Winsock内核缓冲区,并不能说明数据就实际地被投递到了网络上。例外情况:通过设置SO_SNDBUT为0禁用了Winsock内核缓冲区。  Winsock使用下面的规则来向应用程序表明一个Send调用的完成:
title: 实现.
title: Microsoft实现.
content: Winsock1.1 API,需要声明#include <winsock.h>并链接wsock32.lib,使用wsock32.dll。  Winsock2 API,需要声明#include <winsock2.h>,链接ws2_32.lib,在Winsock2_32.dll中实现。 其下是两种服务提供者接口(Service Provider Interface): 可通过ws2spi.h中的两对API函数来安装/卸载服务提供者接口:WSCInstallProvider、WSCDeinstallProvider、WSCInstallNameSpace、WSCUnInstallNameSpace。  SPOrder.dll中提供了重排序服务提供者:WSCWriteNameSpaceOrder、WSCWriteProviderOrder。  大部分Winsock2 API函数被映射到SPI函数,由当前安装的服务提供者实现其功能。一条简单规则是根据提供者链顺序从WSA*函数名映射为WSP*函数名(Winsock Service Provider, 用于传输服务提供者函数)。下述函数不在SPI中实现:  WSP前缀(Winsock Service Provider)的函数是传输服务提供者函数。例如WSPStartup函数用于初始化分层服务提供者。  WPU前缀(Winsock Provider Upcall)的函数是被服务提供者调用的ws2_32.dll中的函数,  WSC前缀(WinSock Configuration)的函数名是LSP安装程序调用的ws2_32.dll中的函数,如:WSCInstallProvider, WSCWriteProviderOrder。  NSP前缀(NameSpace Provider)的函数名用于命名空间提供者。 service provider interface (SPI)是各种功能的具体实施者。允许插入第三方厂商写的 service providers 而无需改变Winsock 2 的API与DLL(ws2_32.dll);从而应用程序开发人员写的基于Winsock的代码也无需改变 。  Winsock 2 SPI 有两种类型的 service providers —— transport 和 namespace。Transport providers(通常称之为协议栈)提供建立连接、传输数据、进行流控制和差错控制等功能。Namespace providers 提供网络协议的寻址属性、协议无关的名字解析。  SPI transport service providers细分为两类 —— base service providers 和 layered service providers。Base service providers 实现了传输协议的实际细节:建立连接、传送数据、流控制和差错控制。Layered service providers 仅实现了高层的自定义的通讯功能,而且依赖于已有的下层的 base provider 来与远程端进行实际的数据交换。也就是说,LSP是做什么的,就是做一些附件的高端的可选的功能。如在 base TCP/IP 栈的顶端实现一个带宽管理器。 而base service providers提供必需的基础的功能。  Winsock 2不允许 namespace providers 的LSP。虽然可以使用 Winsock 2 SPI 来实现一个新的 namespace provider,但是不能改变或扩展已有 namespace provider 的命名、注册和查询行为。  layered transport service provider一般由高层应用开发;而 base transport providers 和 namespace providers 一般由操作系统厂商和协议栈厂商开发。  编写 service provider的就是标准的DLL,其导出函数只有运输服务的WSPStartup 或名字服务的 NSPStartup。WSPStartup 和 NSPStartup通过输出参数lpProcTable作为LSP的dispatch table,提供了约30个可用的函数的地址,这些函数原型在WS2spi.h中声明。WSPStartup的另外一个参数UpcallTable为LSP提供了ws2_32.dll中的15个函数的地址表,这些函数原型也在WS2spi.h中声明。如果ws2_32.dll提供了额外的函数,就需要在WSPStartup通过GetProcAddress获取函数地址,目前仅有一个例子WPUCompleteOverlappedResult。  LSP可以形成一个链,通过调用下层LSP的WSPStartup函数,下层LSP由上层LSP装入。最上层的LSP被ws2_32.dll装入。WSPStartup函数参数lpProtocolInfo指向一个WSAPROTOCOL_INFOW结构组成的链表。链表最底层是base provider。 WSPStartup与WSPCleanup使用引用计数来加载/清除。
title: 其他实现.
content: 遵从Winsock规范的TCP/IP与UDP/IP协议栈有:3Com, Beame & Whiteside, DEC, Distinct, FTP Software, Frontier, IBM, Microdyne, NetManage, Novell, Sun Microsystems, Trumpet Software International.
title: 例子.
title: 优雅关闭.
content: TCP连接的关闭过程有两种:  调用 close()/closesocket() 函数意味着完全断开连接,即不能发送数据也不能接收数据,这种“生硬”的方式有时候会显得不太“优雅”。使用 shutdown() 函数和WSASendDisconnect函数可以优雅关闭连接,其函数原型为 howto 在 Windows 下有以下取值: 确切地说,close() / closesocket() 用来关闭套接字,将套接字描述符(或句柄)从内存清除,之后再也不能使用该套接字。应用程序关闭套接字后,与该套接字相关的连接和缓存也失去了意义,TCP协议会自动触发关闭连接的操作。shutdown() 用来关闭连接,而不是套接字;套接字依然存在,直到调用 close() / closesocket() 将套接字从内存清除。调用 close()/closesocket() 关闭套接字时,或调用 shutdown() 关闭输出流时,都会向对方发送 FIN 包。FIN 包表示数据传输完毕,对端收到 FIN 包就知道不会再有数据传送过来了。默认情况下,close()/closesocket() 会立即向网络中发送FIN包,不管输出缓冲区中是否还有数据,而shutdown() 会等输出缓冲区中的数据传输完毕再发送FIN包。也就意味着,调用 close()/closesocket() 将丢失输出缓冲区中的数据,而调用 shutdown() 不会。  shutdown()并不实际关闭socket,而是仅仅改变其可用性。shutdown是一种优雅地单方向或者双方向关闭socket的方法。 如果有多个进程共享一个socket,shutdown影响所有进程,而close只影响本进程。shutdown本身并不影响底层,也即此前发出的异步send/recv不会返回。在所有已发送的包被对端确认后,本方会发送FIN包给client,开始TCP四次挥手过程。 对端收到FIN报文后,并不知道server端以何种方式shutdown,甚至不知道server端是shutdown还是close。  若本方发送FIN报文后没有收到对端的FIN-ACK,会两次重传FIN报文,若一直收不到对端的FIN-ACK,则会给对端发送RST信号,关闭socket并释放资源。对端收到FIN信号后,再调用read函数会返回0;因为接收了FIN,表明以后再无数据可以接收。  对端收到RST报文后,行为如下: 收到RST报文的情况下,再做任何read write都是毫无意义。  调用调用close(),根据参数设置不同,会出现如下两种情况:  当l_onoff值设置为0时,closesocket会立即返回,并关闭用户socket句柄。如果此时缓冲区中有未发送数据,则系统会在后台将这些数据发送完毕后关闭TCP连接,是一个优雅关闭过程,但是这里有一个副作用就是socket的底层资源会被保留直到TCP连接关闭,这个时间用户应用程序是无法控制的。  当l_onoff值设置为非0值,而l_linger也设置为0,那么closesocket也会立即返回并关闭用户socket句柄,但是如果此时缓冲区中有未发送数据,TCP会发送RST包重置连接,所有未发数据都将丢失,这是一个强制关闭过程。  当l_onoff值设置为非0值,而l_linger也设置为非0值时,同时如果socket是阻塞式的,此时如果缓冲区中有未发送数据,如果TCP在l_linger表明的时间内将所有数据发出,则发完后关闭TCP连接,这时是优雅关闭过程;如果如果TCP在l_linger表明的时间内没有将所有数据发出,则会丢弃所有未发数据然后TCP发送RST包重置连接,此时就是一个强制关闭过程了。  另外还有一个socket选项SO_DONTLINGER,它的参数值是一个bool类型的,如果设置为true,则等价于SO_LINGER中将l_onoff设置为0。  注意SO_LINGER和SO_DONTLINGER选项只影响closesocket的行为,而与shutdown函数无关,shutdown总是会立即返回的。

Summary: Windows Sockets API (WSA), 简短记为Winsock, 是Windows的TCP/IP网络编程接口(API)。兼容于Berkeley socketsAPI在函数名字。实际上,Winsock的实现库(winsock.dll)使用的是长名字。

Winsock: Winsock ("WIN"dows "SOCK"et) est une bibliothèque logicielle pour Windows dont le but est d'implémenter une interface de programmation inspirée de Berkeley sockets. Elle prend notamment en charge l'envoi et la réception des paquets de données sur des réseaux TCP/IP.