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

在集成测试中,发现TCP服务器处理短连接时,若未及时关闭可能导致资源耗尽。设置定时器关闭未解析完毕的连接,但close()操作在某些情况下无效,而shutdown()虽能关闭连接,却触发了服务器的读操作产生关闭事件。经过分析,问题出在子线程处理连接的socket未设置为非阻塞模式。复习TCP知识,理解RST标志的含义和连接关闭流程,最终找到解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

         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.youkuaiyun.com/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看系统调用

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值