Winsock中connect()和recv()方法中的延时

欢迎转载，请注明出处:

http://blog.youkuaiyun.com/leano/archive/2010/09/05/5864650.aspx

Connect中的21秒延时：

当使用blocking方式进行Socket连接时

当网络处于断开的状态或者向不存在的地址发送连接请求的时候会有一个21秒的延时，也就是说要等到21秒以后客户端才会得到连接失败的返回值。

那么这21秒是如何来的呢？

当每次连接开始的时候客户端以广播的形式broadcast向外发送SYN-ACK请求，第一次请求在3秒后超时。

然后会再次发送一个重试SYN-ACK请求，第一次重试会在6秒以后超时。

然后再次发送第二个重试SYN-ACK请求，第二次重试会在12秒以后超时。

返回连接失败结果。这样3＋6+12 = 21秒。

实际上在tcpip中定义了一个connect的重试次数参数并且默认值为2(xp中在注册表中没有这个键值，可以通过手动添加并修改默认值)，超时为每次都为上次超时时间的2倍。

基本的超时时间也就是第一次连接请求的时间为3秒。

当使用nonblocking方式进行Socket连接时

由于使用的是nonblocking方式connect方法可以马上返回SOCKET_ERROR错误并且可以通过WSAGetLastError方法取得错误ID当错误ID为WSAEWOULDBLOCK时，调用select方法。通过给select方法设定一个超时时间(有效值范围0~21秒)，如果超时时间内socket还不能写数据也就是发送数据，返回超时，也就是连接失败。虽然我们通过select的超时判断出了连接失败，但是底层的connect重试并没有停止。也就是说真正的connect连接失败还是要21秒以后。这就是为什么select方法在判断连接超时的时候有效值范围在0到21秒之间，因为超出这个值的范围的时，在21秒的时候会返回连接失败异常。

 

recv()中的500ms延时：

当使用recv()方法接收数据时，虽然设定了接收超时，但是实际上超时花费的时间要比定义的时间多出500ms。要解决这个问题可以使用select方法，在接受之前使用select定义超时时间，当时间内不能接收数据时直接返回超时。

 

以上内容为在windows Xp sp3测试下得到的结果，不代表所有OS，因为本人对windows以外的系统根本不了解！