我写过简单的C/S应用来测试非阻塞套接字的特性，这里简单介绍一下服务端和客户端:

//On linux The server thread will send 
//a file to the client using non-blocking socket       
void *SendFileThread(void *param){
    CFile* theFile = (CFile*) param;
    int sockfd = theFile->GetSocket();
    set_non_blocking(sockfd);
    set_sock_sndbuf(sockfd, 1024 * 64); //set the send buffer to 64K

    //get the total packets count of target file
    int PacketCOunt = theFile->GetFilePacketsCount();
    int CurrPacket = 0;
    while (CurrPacket < PacketCount){
        char buffer[512];
        int len = 0;

        //get packet data by packet no.
        GetPacketData(currPacket, buffer, len); 

        //send_non_blocking_sock_data will loop and send
        //data into buffer of sockfd until there is error
        int ret = send_non_blocking_sock_data(sockfd, buffer, len);
        if (ret < 0 && errno == EAGAIN){
            continue；
          } else if (ret < 0 || ret == 0 ){
             break;
         } else {
             currPacket++;
         }


         ......
     }
 }

//On windows, the client thread will do something like below
//to receive the file data sent by the server via block socket
void *RecvFileThread(void *param){
    int sockfd = (int) param; //blocking socket
    set_sock_rcvbuf(sockfd, 1024 * 256); //set the send buffer to 256

    while (1){
        struct timeval timeout;
        timeout.tv_sec = 1;
        timeout.tv_usec = 0;

        fd_set rds;
        FD_ZERO(&rds);
        FD_SET(sockfd, &rds)'

        //actually, the first parameter of select() is 
        //ignored on windows, though on linux this parameter
        //should be (maximum socket value + 1)
        int ret = select(sockfd + 1, &rds, NULL, NULL, &timeout );
        if (ret == 0){
            // log that timer expires
            CLogger::log("RecvFileThread---Calling select() timeouts\n");
        } else if (ret) { 
            //log the number of data it received
            int ret = 0;
            char buffer[1024 * 256];
            int len = recv(sockfd, buffer, sizeof(buffer), 0);
            // handle error
            process_tcp_data(buffer, len);
        } else {
            //handle and break;
            break;
        }

    }
}

令我吃惊的是，由于套接字缓冲区已满，服务器线程经常失败，例如要发送 14M 大小的文件，它会报告 50000 次失败，errno = EAGAIN。但是，通过日志我观察到传输过程中有数十次超时，流程如下:

1. 第N次循环，select()成功，成功读取256K的数据。
2. 在第 (N+1) 次循环中，select() 因超时而失败。
3. 第(N+2)次循环，select()成功，成功读取256K的数据。

为什么在接收过程中会出现超时？谁能解释一下这个现象？

[更新]
1.上传一个14M的文件到服务器只需要8秒
2. 使用与1)相同的文件，服务器将所有数据发送到客户端需要将近30秒。
3.客户端使用的所有套接字都是阻塞的。服务器使用的所有套接字都是非阻塞的。

关于#2，我认为超时是#2 比#1 花费更多时间的原因，我想知道为什么当客户端忙于接收数据时会有这么多超时。

[更新2]
感谢@Duck、@ebrob、@EJP、@ja_mesa 的评论，我今天会做更多调查 然后更新这篇文章。
关于为什么我在服务器线程中每个循环发送 512 个字节，这是因为我发现服务器线程发送数据比客户端线程接收数据快得多。我很困惑为什么客户端线程会发生超时。

最佳答案

将此视为一个长评论而不是一个答案，但正如一些人指出的那样，网络比您的处理器慢几个数量级。非阻塞 i/o 的要点在于差异如此之大，以至于您实际上可以使用它来完成真正的工作而不是阻塞。在这里，您只是在敲电梯按钮，希望能有所作为。

我不确定你的代码有多少是真实的，有多少是为了发布而被切碎的，但在你没有考虑的服务器中(ret == 0)，即同行正常关闭。

客户端的select错误。同样，不确定那是否是草率的编辑，但如果不是，那么参数的数量是错误的，但更重要的是，第一个参数——即应该是 select 要查看的最高文件描述符加一——为零。根据 select 的实现，我想知道这是否实际上只是将 select 变成了一个奇特的 sleep 语句。

关于c++ - 为什么客户端忙于接收数据时select()有时会超时，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17406155/