总结一下今天tcp服务器的一个rst问题

         X项目即将封存，最近闲来无事，最后自己做了一次集成测试，发现了一个不算小的问题，虽然不是什么难题，处理的过程还是温故了不少知识，就记录一下。处理短连接的时候，tcp服务器端收到请求时，通过多路复用建立一个连接。这里采用边接收边解析的结构以处理客户端的多次发送，直到收到一次请求的结束符时开始进行业务处理。这样没有收到结束符的连接就一直处在连接状态，如果有人用来进行tcp攻击，服务器很快就将崩溃。处理办法自然是用定时器，建立的连接如果一段时间没有解析完毕自然删除。加入定时器代码时又引入了另一个问题，开始怀疑是子线程中处理问题，后来定位定时器中关闭连接竟然（int iRes = close(pCon->fd);）竟然无效,查看返回值是正确。

        于是换用shutdown(pPcon->fd,SHUT_RDWR);虽然可以关闭，但是关闭后服务器端又被触发一次读操作产生关闭事件。虽然很久没做这块的开发了，这种现象应该确认是没遇到过的吧，抓包吧

         

        这个RST是怎么来的,不是两个Fin吗？复习一下tcp的知识

         在TCP层，有个FLAGS字段，这个字段有以下几个标识：SYN, FIN, ACK, PSH, RST, URG. SYN表示建立连接，  FIN表示关闭连接，    ACK表示响应， PSH表示有 DATA数据传输，RST表示连接重置。只要TCP栈的读缓冲里还有未读取（read）数据，则调用close时会直接向对端发送RST。找到了线索，再看代码，原来在子线程处理连接socket的没有设置非阻塞。

   if ((iFlags = fcntl(sFd, F_GETFL, 0)) < 0 ||
            fcntl(sFd, F_SETFL, iFlags | O_NONBLOCK) < 0)
    {
        perror("setting O_NONBLOCK");
        close(sFd);
        return -1;
    }

        晕，这么大的问题以前都没发现，看来测试部的果然靠不住啊，老提那些应该这么做那么做这些产品经理们干的事

     

       参考：1. shutdown 与close  http://blog.csdn.net/helpxs/article/details/6661951

                   2. tcp连接的建立与关闭 http://hi.baidu.com/psorqkxcsfbbghd/item/70f3bd91943b9248f14215cd 

      Faq:   a.打开同时关闭就不是三次握手四次挥手了

                 b. netstat -apt|grep 7777

                     tcp        0      0 *:7777                  *:*                     LISTEN      25439/PC_*******
                     tcp        0      0 linux:7777              10.46.48.167:apc-3506   ESTABLISHED -       这个是建立的子连接

                c. strace看系统调用