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 oder Windows Sockets ist eine Windows-Programmierschnittstelle (API) zum Zugriff auf Rechnernetze über Sockets.