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

作者：易隐者 发布于：2012-8-21 22:40 Tuesday 分类：网络分析

        前两天，在科来的群里有兄弟咨询一个服务器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连接。

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

标签: TCP RST 延时 响应时间 应用响应时间 FIN 正常释放 TCP行为 长连接 短连接


您对本文的评分:
当前平均分: 9.7(22 次打分)

版权所有：《蚂蚁网-多维人生，三实而立！》 => 《关于服务器端发送FIN报文之前的数秒等待时间行为的分析》
本文地址：http://www.vants.org/?post=95
除非注明，文章均为 《蚂蚁网-多维人生，三实而立！》 原创，欢迎转载！转载请注明本文地址，谢谢。

« 从《复仇者联盟》看可视的重要性 | 带有应用层字段的TCP RST报文»

评论：

NetworkProgram
2012-08-22 11:43
Server fin不发送，并非全是在等待Client payload，
Fin跟应用性能紧密关联。
回复
易隐者
2012-08-22 11:56
@NetworkProgram："Server fin不发送，并非全是在等待Client payload",兄弟，能否列举一下服务器等待一段时间才发送FIN报文的原因呢？
“Fin跟应用性能紧密关联”，如果长时间不发送FIN报文，释放连接，服务器端的连接数多了，肯定会影响服务器性能，我这里说的是就这个实际案例，等待时间13秒，也不是很长，对服务器性能影响不大
回复

发表评论：

Powered by 易隐者 基于emlog 皖ICP备12002343号-1