越努力越幸运--2018年7月22日周记

Posted 2020-12-24 ashen

本周过的很快，记录下本周。

1. 上一家公司，听前同事说方哥也跑路了，感触颇多，程序员这一行，到了后面，路越来越窄，方哥，山哥能力没得说，都是大神级别的，却找不到自己的安乐之地。

2. 本周遇到有趣。

　　问题 ：TCP协议，SOCKET其的短连接，c端被动断掉，出现了CLOSE_WAIT状态。

　　环境: ： C ->  性能F5 -> S

　　现象： 1. 调用write,errno 返回104，错误说明connection reset by peer.连接被重置　　

　　　　    2. 程序直接退出，啥现象看不到

　　　　   以上2个现象不是同时发生，必有其一发生

　　定位错误：

　　　　第一直觉感觉tcp协议使得的坏，因为对协议不了解，怀疑协议栈的哪个参数设置了，如果没报文上来，过了一段时间，协议栈主动断掉短链接，查TCP相关的资料，改了内核参数

　　　　sysctl -w net.ipv4.tcp_keepalive_time=30   --存活时间s
　　　　sysctl -w net.ipv4.tcp_keepalive_probes=2 --过了存活时间，发送探测的次数
　　　　sysctl -w net.ipv4.tcp_keepalive_intvl=2　  -- 发送探测的间隔

　　　　没用。。。哈哈，TCP的3次握手，4次再见是明白了

             推荐参考的

　　　　http://ahuaxuan.iteye.com/blog/657511

　　　　协议的图还是有必要贴的，S端主动断

　　　　?

　　　　C端主动断的状态图：

 

　　　　?

 

　　　　继续说问题，google呗，104，google上的一个哥们说发送的数据长度小于实际发送的长度会出现这样的状态，把我的方向带偏了，我在那纠结一会是不是我们发的长度不对，就差抓包了。后来边看协议便改了一部分测试代码，当时也怀疑时序问题，因为我们的c端代码，s端主动断连接，c也cloese了，然后c又继续connect了一个新的sockid，不明白为什么我们的c端会出现CLOSE_WAIT状态，按照上图来说，肯定是不会出现这样的状态的。

我把我们的代码修改了一部分，原先是先建立连接，做部分业务处理，发送，我改成了先做业务处理，发送前建立连接，然后问题过了。。。运气好，哈哈。

分析原因，我们的业务处理大概10分钟，因为建立的短链，协议栈肯定不会来端我们的，因为google一大把，没找到这块说tcp协议会做这样的事，那么只有可能是性能F5，去问了性能F5组，果然他们有这样的一个设置，防止攻击，占着厕所不便便，他们主动给我们断了，大概在6分钟左右，断了之后，当我们本地业务处理完，在write时候，收到一个RST响应，系统产生SIGPIPE(被IGN了)，直接write失败，返回104，异常返回，解释的通。

另外现象2，GDB跟了一把，发现还是收到了SIGPIPE，但是设置了signal(SIGPIPE, SIG_IGN),没生效，这就没明白，google说SIG_IGN设置了之后，会一直生效，其他部分信号是一次性的生效，建议用sigaction，试了sigaction，果然没再复现，这里参考http://guangming008.blog.163.com/blog/static/12039682012527258171/