标签为 "9s" 的存档

三次握手的第三个ACK包丢了,TCP的处理方式

三次握手的第三个ACK包丢了——客户端认为连接建立,写数据时,会触发RST
当Client端收到Server的SYN+ACK应答后,其状态变为ESTABLISHED,并发送ACK包给Server;
如果此时ACK在网络中丢失,那么Server端该TCP连接的状态为SYN_RECV,并且依次等待3秒、6秒、12秒后重新发送SYN+ACK包,以便Client重新发送ACK包。
Server重发SYN+ACK包的次数,可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改,默认值为5。 如果重发指定次数后,仍然未收到ACK应答,那么一段时间后,Server自动关闭这个连接。
但是Client认为这个连接已经建立,如果Client端向Server写数据,Server端将以RST包响应,方能感知到Server的错误.

前端机超时3s ,9s

这几天遇到一个很奇怪的问题,搜索的前端机经常会有一些超时的请求,以为是业务哪块效率不行导致的。后来就写了一个php,只做 echo 1 操作,结果在大量curl时,还是会出先超时的情况,而且仔细分析后,出现的超时要么是比正常时间多3秒整,要么是比正常时间多9s整,只有这两种可能,没有其它的超时时间,这就更奇怪了,。查了一下资料,3s和9s的超时,是网络问题引起的。
Mysterious 3 and 9 second delays calling connect()

If a client tries to
establish a TCP connection to a server but the server does not
respond, then the client tries again after 3 seconds, then once again
after 6 more seconds. The number of retry attempts is configurable by
changing tcp_syn_retries ("sysctl net.ipv4.tcp_syn_retries," "man 7
tcp" for description).

20131126174519-backlog-3s-nginx

nginx php 3s 9s timeout delay

nginx php 3s 9s timeout delay

再底层的东西也咱现在也不了解啊。。还得慢慢学啊,可是问题还得解决啊。。
于是把问题抛给了op的同事,,最后解决了。。
解决办法:
修改 /usr/local/nginx/conf.d/default.conf 的 backlog=8192 后,超时3秒、9秒的问题得到验证解决。
修改了nginx的默认的backlog参数。
具体原因是啥,现在也不懂,记录下来,以后慢慢参悟吧。