关于服务器端发送FIN报文之前的数秒等待时间行为的分析

2012-08-21 · 网络分析 · 网络分析 · 21315 次阅读

前两天，在科来的群里有兄弟咨询一个服务器FIN之前等待13S的事情，我把当时群里以及我跟这位兄弟私下QQ讨论的主要内容先贴在这里（在这里为安全起见，我隐去我自己之外的其他兄弟的QQ信息）：

龙软-<xxx@hotmail.com> 14:55:37

请问下每次都在ACK，FIN这点服务器响应都要13s，一般是服务器系统的问题还是应用系统的问题呢？
龙软-<xxx@hotmail.com> 14:56:25

安徽-科来-王超<networkanalyzer@qq.com> 14:58:52
一般而言都是应用
北京科来(59xxx2) 14:59:14
服务器的会话空闲超时吧，服务器程序在发完数据后没有立刻关闭发送窗口，等待一段时间客户端没有发送新的应用层请求再关闭会话。
龙软-<xxx@hotmail.com> 15:00:15
服务器的资源利用都不算高，CPU 2%，内存66%
龙软-<xxx@hotmail.com> 15:02:09
会不会出现 访问应用系统变慢？
安徽-科来-王超<networkanalyzer@qq.com> 15:02:16
一般而言，TCP连接氛围长连接和短连接，短连接一般是有应用数据交互则建立TCP连接，交互完毕则释放连接
安徽-科来-王超<networkanalyzer@qq.com> 15:02:36
长连接则建立TCP连接后，连接一直保持
安徽-科来-王超<networkanalyzer@qq.com> 15:02:52
因此，这个控制的部分主要在应用系统
安徽-科来-王超<networkanalyzer@qq.com> 15:02:56
而不在操作系统

胡 15:03:38
会不会引起访问应用系统很慢的情况
易隐者 16:06:44
这个都结束啦
易隐者 16:07:05
这个13秒的延时一般不影响应用效率
胡 16:08:59
如果建立而不断的连接多了，应该会影响新的会话响应吧
易隐者 16:09:18
短连接一般都能及时释放
易隐者 16:09:37
长连接就可能存在很多半开连接的
易隐者 16:09:49
如果过多的话，肯定影响服务器性能
胡 16:09:46

胡 16:10:08
很多这样持续时间为２分钟的
易隐者 16:10:50
你要分析这些连接是否正常释放掉了
胡 16:11:55
都是我刚才在群里发的那种情况，到最后关闭连接的前一步时间间隔为１３ｓ到１分多钟不等
易隐者 16:12:05
这个是正常释放
易隐者 16:12:16
不会对服务器产生大的影响
胡 16:12:36
一般造成这样的情况　会有哪些原因呢　？
易隐者 16:12:59
应用程序问题的可能性大
易隐者 16:14:12
这个对性能什么的影响不大
易隐者 16:14:21
不要过多关注

就这个问题，我来简单分析一下基于TCP的应用，正常释放TCP连接的行为：

在实际环境下，我们可以抓到各种FIN正常释放连接的报文，大部分交互完毕应用数据之后立即发送FIN报文释放连接，如下图所示：

有些交互完毕应用数据后，服务器端立即发送FIN报文，客户端在确认FIN报文之后，发送RST报文，释放TCP连接，这样做主要视为了提高交互的效率，省去了服务器确认客户端FIN报文和客户端等等服务器端确认的过程和时间，如下图所示：

有些则如上面兄弟遇到的那个情况，双方在建立TCP连接后，进行应用数据的交互，应用数据交互完毕之后，服务器端并不是立即发送FIN报文，正常释放该TCP连接，而是等待一段时间，看客户端是否有新的应用数据需要交互，如果有，则不需要再建立一个新的TCP连接，直接使用已有连接进行交互，如果超出时间客户端无应用数据交互，则服务器端主动发送FIN报文，正常释放该TCP连接。

这个过程，是由应用程序控制的，跟操作系统无关。另这种机制一般情况下能够提高应用交互的效率，这个服务器端等待客户端是否有应用数据交互的时间不能算作是应用响应时间。