返回信息流关于win32 sock的send函数，之前了解过send只负责将数据拷贝到系统的内核缓冲区，然后有系统内核负责将数据发出去，今天我想测试一下send方法是否阻塞，比如内核缓冲区8kb，使用send发送一个大于8kb的数据，观察send是否阻塞以及返回值的情况，但是测试时发现一个比较怪异的情况： 当我使用send发送一个100MB的数据，send只用了不到100ms就返回了（猜测耗时主要在内存拷贝），而且返回的数值刚好是100×1024×1024（100MB），观察网卡流量，在send返回的很长一段时间数据还在发送，也就是说系统的内核缓冲区有100MB之大？还是说有其他的解释？
```C
char* buff = new char[1024*1024*100+1];
memset(buff, 69, 1024*1024*100);
SYSTEMTIME start, start1;
timeBeginPeriod(1);
GetLocalTime(&start);
iRet = send(m_socket, buff, 1024*1024*100, 0);
GetLocalTime(&start1);
timeEndPeriod(1);
cout<<"start:"<<start.wSecond<<"."<<start.wMilliseconds<<endl;
cout<<"end:"<<start1.wSecond<<"."<<start1.wMilliseconds<<endl;
printf("send:%d\n", iRet);
```
输出：
start:42.996
end:43.81
send:104857600
这是一条镜像帖。来源：北邮人论坛 / cpp / #92574同步于 2016/7/15
该镜像源已超过 30 天没有更新，可能在源站已被删除。
CPP机器人发帖
win32 socket的一个问题
asm
2016/7/15镜像同步3 回复
订阅后，新回复会通过你的通知中心匿名送达。
3 条回复
send返回之后的很长一段时间指的是多久。。
彩笔斗胆猜想一下：如果能显示修改内核缓冲区，不如用同一段程序测试一下，在内核缓冲区被手动指定为100m和8k的情况下，发送100m数据的send返回时间，以及返回之后数据实际发完的时间
大概几十秒吧，跟带宽有关系
其实我的意思是内核缓冲区不可能有100MB这么大啊，肯定是我忽略了什么
【 在 cyf333333 的大作中提到: 】
: send返回之后的很长一段时间指的是多久。。
: 彩笔斗胆猜想一下：如果能显示修改内核缓冲区，不如用同一段程序测试一下，在内核缓冲区被手动指定为100m和8k的情况下，发送100m数据的send返回时间，以及返回之后数据实际发完的时间
The successful completion of a send function does not indicate that the data was successfully delivered and received to the recipient. This function only indicates the data was successfully sent.
If no buffer space is available within the transport system to hold the data to be transmitted, send will block unless the socket has been placed in nonblocking mode. On nonblocking stream oriented sockets, the number of bytes written can be between 1 and the requested length, depending on buffer availability on both the client and server computers. The select, WSAAsyncSelect or WSAEventSelect functions can be used to determine when it is possible to send more data.
Calling send with a len parameter of zero is permissible and will be treated by implementations as successful. In such cases, send will return zero as a valid value. For message-oriented sockets, a zero-length transport datagram is sent.
The flags parameter can be used to influence the behavior of the function beyond the options specified for the associated socket. The semantics of the send function are determined by any options previously set on the socket specified in the s parameter and the flags parameter passed to the send function.
Note When issuing a blocking Winsock call such as send, Winsock may need to wait for a network event before the call can complete. Winsock performs an alertable wait in this situation, which can be interrupted by an asynchronous procedure call (APC) scheduled on the same thread. Issuing another blocking Winsock call inside an APC that interrupted an ongoing blocking Winsock call on the same thread will lead to undefined behavior, and must never be attempted by Winsock clients.