tcp connect 在高负载下随机失败答案

【问题标题】：tcp connect fails randomly under high loadtcp connect 在高负载下随机失败
【发布时间】：2012-07-06 00:51:07
【问题描述】：

我们的应用程序使用非阻塞套接字使用连接和选择操作（c 代码）。 pusdo代码如下：

unsigned int ConnectToServer(struct sockaddr_in *pSelfAddr,struct sockaddr_in *pDestAddr)
    {
         int sktConnect = -1;
         sktConnect = socket(AF_INET,SOCK_STREAM,0);
         if(sktConnect == INVALID_SOCKET)
             return -1;
         fcntl(sktConnect,F_SETFL,fcntl(sktConnect,F_GETFL) | O_NONBLOCK);
         if(pSelfAddr != 0)
         {
             if(bind(sktConnect,(const struct sockaddr*)(void *)pSelfAddr,sizeof(*pSelfAddr)) != 0)
             {
                 closesocket(sktConnect);
                 return -1;
             }
         }
         errno = 0;
         int nRc = connect(sktConnect,(const struct sockaddr*)(void *)pDestAddr, sizeof(*pDestAddr));
         if(nrC != -1)
         {
             return sktConnect;
         }
         if(errno != EINPROGRESS)
         {
             int savedError = errno;
             closesocket(sktConnect);
             return -1;
         }
         fd_set scanSet;
         FD_ZERO(&scanSet);
         FD_SET(sktConnect,&scanSet);
         struct timeval waitTime;
         waitTime.tv_sec = 2;
         waitTime.tv_usec = 0;
         int tmp;
         tmp = select(sktConnect +1, (fd_set*)0, &scanSet, (fd_set*)0,&waitTime);
         if(tmp == -1 || !FD_ISSET(sktConnect,&scanSet))
         {
             int savedErrorNo = errno;
             writeLog("Connect %s failed after select, cause %d, error %s",inet_ntoa(pDestAddr->sin_addr),savedErrorNo,strerror(savedErrorNo));
             closesocket(sktConnect);
             return -1;
         } 
    .        .        .     .     .}

有 80 个这样的节点，应用程序以循环方式连接到它的所有对等节点。在此阶段，部分节点无法连接（api – connect + select），错误号为 115。

在下面的（tcpdump 输出的）日志中，我们可以看到 (SYN, SYN+ACK, ACK) 但失败时甚至没有 SYN 条目 tcpdump 日志中的节点。

tcpdump 日志是：

387937 2012-07-05 07:45:30.646514 10.18.92.173          10.137.165.136        TCP      33728 > 8441 [SYN] Seq=0 Ack=0 Win=5792 Len=0 MSS=1460 TSV=1414450402 TSER=912308224 WS=8 
387947 2012-07-05 07:45:30.780762 10.137.165.136        10.18.92.173          TCP      8441 > 33728 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=912309754 TSER=1414450402 WS=8 
387948 2012-07-05 07:45:30.780773 10.18.92.173          10.137.165.136        TCP      33728 > 8441 [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=1414450435 TSER=912309754 
All the above three events indicate the success information.
387949 2012-07-05 07:45:30.782652 10.18.92.173          10.137.165.136        TCP      33728 > 8441 [PSH, ACK] Seq=1 Ack=1 Win=5888 Len=320 TSV=1414450436 TSER=912309754 
387967 2012-07-05 07:45:30.915615 10.137.165.136        10.18.92.173          TCP      8441 > 33728 [ACK] Seq=1 Ack=321 Win=6912 Len=0 TSV=912309788 TSER=1414450436 
388011 2012-07-05 07:45:31.362712 10.18.92.173          10.137.165.136        TCP      33728 > 8441 [PSH, ACK] Seq=321 Ack=1 Win=5888 Len=320 TSV=1414450581 TSER=912309788 
388055 2012-07-05 07:45:31.495558 10.137.165.136        10.18.92.173          TCP      8441 > 33728 [ACK] Seq=1 Ack=641 Win=7936 Len=0 TSV=912309933 TSER=1414450581 
388080 2012-07-05 07:45:31.702336 10.137.165.136        10.18.92.173          TCP      8441 > 33728 [PSH, ACK] Seq=1 Ack=641 Win=7936 Len=712 TSV=912309985 TSER=1414450581 
388081 2012-07-05 07:45:31.702350 10.18.92.173          10.137.165.136        TCP      33728 > 8441 [ACK] Seq=641 Ack=713 Win=7424 Len=0 TSV=1414450666 TSER=912309985 
388142 2012-07-05 07:45:32.185612 10.137.165.136        10.18.92.173          TCP      8441 > 33728 [PSH, ACK] Seq=713 Ack=641 Win=7936 Len=320 TSV=912310106 TSER=1414450666 
388143 2012-07-05 07:45:32.185629 10.18.92.173          10.137.165.136        TCP      33728 > 8441 [ACK] Seq=641 Ack=1033 Win=8704 Len=0 TSV=1414450786 TSER=912310106 
388169 2012-07-05 07:45:32.362622 10.18.92.173          10.137.165.136        TCP      33728 > 8441 [PSH, ACK] Seq=641 Ack=1033 Win=8704 Len=320 TSV=1414450831 TSER=912310106 
388212 2012-07-05 07:45:32.494833 10.137.165.136        10.18.92.173          TCP      8441 > 33728 [ACK] Seq=1033 Ack=961 Win=9216 Len=0 TSV=912310183 TSER=1414450831 
388219 2012-07-05 07:45:32.501613 10.137.165.136        10.18.92.173          TCP      8441 > 33728 [PSH, ACK] Seq=1033 Ack=961 Win=9216 Len=356 TSV=912310185 TSER=1414450831 
388220 2012-07-05 07:45:32.501624 10.18.92.173          10.137.165.136        TCP      33728 > 8441 [ACK] Seq=961 Ack=1389 Win=10240 Len=0 TSV=1414450865 TSER=912310185

应用程序日志在连接时通知错误（即 api - 连接 + 选择）

[5258: 2012-07-05 07:45:30]Connect [10.137.165.136 <- 10.18.92.173] success. 
[5258: 2012-07-05 07:45:32]Connect 10.137.165.137 fail after select, cause:115, error Operation now in progress. Check whether remote machine exist and the network is normal or not. 
[5258: 2012-07-05 07:45:32]Connect to server([10.137.165.137 <- 10.18.92.173], port=8441) Failed!

与 tcpdump 的前 3 个条目对应的成功日志。以及 tcpdump 中没有事件的故障日志

我的问题是：当客户端为失败的情况启动“连接”api时，我无法在客户端的 tcpdump 中看到任何事件（甚至初始同步）。这种随机性可能是什么原因。

【问题讨论】：

当您退出tcpdump 时，您是否看到packets dropped by kernel 或packets dropped by interface 的任何非零值？

标签： linux tcp linux-kernel suse

【解决方案1】：

您已点击EINPROGRESS。来自connect 手册页：

套接字是非阻塞的，连接不能立即完成。可以通过选择要写入的套接字来选择（2）或轮询（2）以完成。在 select(2) 指示可写后，使用 getsockopt(2) 读取 SOL_SOCKET 级别的 SO_ERROR 选项，以确定 connect() 是成功完成（SO_ERROR 为零）还是未成功完成（SO_ERROR 是此处列出的常见错误代码之一，解释了失败的原因）。

这表示EINPROGRESS 表明内核现在无法完成连接，即使有可用的本地端口和路由缓存条目。当套接字状态尚未转换为“ESTABLISHED”时，似乎会发生这种情况。只需再次等待select 中的套接字，然后调用getsockopt 以查看您的connect 是否已完成。

至于为什么，在连接过程中，套接字会转换为 SYN_SENT 状态，但数据包可能仍在输出队列中，实际上还没有到达网络设备缓冲区。

【讨论】：

是否有任何内核（即 TCP/IP 堆栈层）参数在调整时可以通过在系统中带来更多的鲁棒性来处理这些不一致。基本上，在这种情况下，我们如何确保稳定性优于性能？
@kumar_m_kiran：如果你想异步连接就不行。每个设备最终都会达到每秒可以执行多少操作的限制。如果你不想处理这种情况，connect在阻塞模式下，成功后让socket非阻塞。

【解决方案2】：

select() 返回后，您实际上并没有获取套接字的当前状态 - 您在errno 中看到了一个陈旧的值（来自connect() 调用）。您的select() 很可能只是在超时后返回。

select()返回后，需要调用getsockopt(sktConnect, SOL_SOCKET, SO_ERROR, &err, ...)获取socket的实际状态。

【讨论】：