欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

PSH|RST同置位,系统应用共沉寂!

作者:易隐者 发布于:2014-2-7 14:34 Friday 分类:案例讨论

       年前一位技术兄弟维护的站点遇到异常流量,导致无法正常访问站点。其将捕获到的报文发给我,让我帮其分析一下大致是什么情况。年前杂事较多,未来得及写分析文档,年后将未完成的部分补充完全,放在此供各位兄弟讨论。

       我首先查看其TCP会话数较多(8500多个),而且大部分的TCP会话是219.140.167.122与X.X.254.18之间产生的,并且这些会话具有较为明显的流量特征,如下图所示: 

点击查看原图

       我们在报文 中任意查看其中一个TCP会话的交互报文,如下图: 

点击查看原图

       我们可以发现,其在完成三次握手之后,219.140.167.122主机与X.X.254.18发起了一个PSH、RST同时置一的报文,如下图:

点击查看原图

       这个报文的解码和follow TCP Stream显示其为一个http  get请求报文,如下: 

点击查看原图

       将其解码,如下: 

点击查看原图

        可见这是一个针对站点某个pdf文档进行访问的操作。

点击查看原图

        在这个TCP交互过程中,我们可发现服务器在收到这个PSH、RST位同时置一的get请求之后,并没有立即RST释放这个TCP连接,而是在72秒之后,服务器才向客户端发送RST报文释放该TCP连接。

        一般情况下,在收到RST报文之后,系统传输层会立即释放对应的TCP连接,为什么要等到72秒之后才发送RST报文呢?TCP协议栈在收到PSH,RST位同时置一的报文时,应该如何处理??

       Google百度均未找到相关的说明资料。

       我们不妨自己先大胆推测一下服务器在收到PSH、RST位同时置一的报文时时如何处理。
三种假设:
1,如果服务器先处理RST位,则服务器端会立即释放相关的TCP连接表信息。PSH位置一应该会失去应有的意义,传输层不会将客户端的应用字段递交给应用层处理。
2,如果服务器先处理PSH位,后处理RST位,则服务器将get请求提交应用层之后,释放TCP连接。服务器及时向应用层在处理完客户端的get请求之后,应用层向传输层提交应用层响应数据,这时,会发现在服务器传输层已有的TCP连接表信息中找不到对应的TCP连接,传输层向应用层报错,应用层放弃。
3,如果服务器先处理PSH位,忽略RST位,则服务器会将应用层的响应字段正常发送给客户端。

       我们再来仔细的看看上述报文交互的情况:

点击查看原图

       我们可以发现,服务器在72秒之后向客户端发送的RST报文其ACK位是置一的,ACK相对确认号是1,这说明这个RST报文发送出来的时候,服务器端的TCP连接表信息是正常的,并且传输层并未处理PSH、RST位置一的报文,否则ACK相对确认号应该是805而不是我们看到的1。

        我们再来看一下这个服务器发送的RST报文的解码,如下图所示: 

点击查看原图


        该报文TTL=64,可说明两点:

1,这个报文的确是服务器发送的,不会是第三方进行TCP会话劫持伪造发送的;

2,这个服务器可能是linux的服务器。

       上面的这些说明了什么呢?

       我个人认为,造成上述情况出现的原因是服务器过滤了RST位置一的报文!

       服务器要做到对TCP标识位进行过滤并不是一件难事,iptables就可以。iptables如下命令即可实现对RST位置一报文的过滤:
  iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP

       服务器过滤了PSH/RST位置一的报文,它不管PSH是否置一,因此那个客户端发送给服务器的PSH/RST位置一的http get报文并未被服务器传输层收到,服务器传输层在等待了72秒未收到客户端的任何请求之后,主动RST释放了这个TCP连接。

       这些流量特征一致的TCP会话基本都是一样的,在三次握手建立TCP连接之后,向服务器发送PSH、RST位同时置一的http get请求报文,如下图所示:  

点击查看原图

       客户端短时间内大量的这种报文,导致服务器的连接表骤增而在一定时间内难以释放,从而给服务器造成了DOS攻击的效果。

阅读全文>>

标签: TCP RST TTL get push DOS攻击 连接表 异常流量 HTTP PSH RST过滤 iptables PSH/RST位同时置一

评论(4) 引用(0) 浏览(108416)

TCP 的PUSH标志位

作者:易隐者 发布于:2012-8-31 15:32 Friday 分类:网络分析

       发送方使用该标志通知接收方将所收到的数据全部提交给接收进程。这里的数据包括接收方已经接收放在接收缓存的数据和刚刚收到的PUSH位置一的TCP报文中封装的应用数据。
还是看一个简单明了的图示吧:

点击查看原图

关于PUSH位的一些讨论和分析

       Long_323(龙的传人)兄弟曾跟我讨论:在无法解码应用层报文时,能否根据TCP  PUSH位来分析应用响应时间?

       我的回答是:不可以,我个人不会这么做,因为不够科学。

       所谓应用响应时间,是指客户端有发出请求,服务器端会针对该请求作出相应的响应,我们才可以分析计算其响应时间。如果我们无法解码应用层,那么我们就无法确定其到底是不是一个请求报文,如果不是请求报文(例如,我的《TCP交互交互式应用》一文中提到的互动游戏的报文、TCP keepalive保活的报文等)但是其TCP PUSH位是置一的,那么我们怎么能根据这一点就计算出应用的响应时间呢?

       也许有经常关注我的兄弟会问:你说不可以,那怎么在你写的文章《关于“client push”应用响应时间测量方法的讨论》中,建议说“从客户端带有PUSH标志位的数据包开始计算,至服务器端响应应用层数据停止计算”呢?如果真有这么问的兄弟,我会非常欣慰,因为能问出这个问题的人,说明他有认真仔细的研读过我的文章,那么他肯定会从中获得一些帮助和成长,我会为此而心生满足。言归正传,在我的《关于“client push”应用响应时间测量方法的讨论》一文里,全文的基础和基调都已经定在为“client push”的应用场景了,看标题你就会明白,不需要我多说了吧。

       言已至此,我想大家也会明白,我说的不可以并不是绝对不可以,而只是站在我个人的角度而说的,仅代表我的个人主观选择。

       在有些情况下,可以作为一个参考分析思路。那么到底在哪些情况下能这么做呢?我个人认为主要有以下几点:
1, 可以明确我们要分析的应用类型为请求-响应类的应用
2, 虽不能解码,但是我们在做分析时,需要将具体的请求操作和数据报文结合起来分析,以提高分析的科学性和准确性
3, 对分析的结果要求不是非常高、非常严谨的

       还有兄弟认为如果所有带有应用字段的TCP报文PUSH位都置一的话,会对服务器造成较为严重的性能影响。这个所谓的影响如果真的存在的话,我想应该是在服务器的内存、CPU等资源严重不足或应用程序本身处理存在严重性能问题时才会出现,是因为本来就有问题了,导致PUSH位都置一的报文加重了这种影响,而不是因为PUSH位置一的报文导致了服务器的性能问题的出现。

关于PUSH位的应用

        PUSH位就是用来通告接收方立即将收到的报文连同TCP接收缓存里的数据递交应用进程处理。一般会出现在发送方封装最后一个应用字段的TCP报文中,针对TCP交互式应用,则只要封装有应用字段的TCP报文,均会将PUSH位置一,当然,应用程序的开发者,可以根据需要,在某个应用功能模块或某个应用操作时,将所有封装应用字段的TCP报文PUSH位置一,以提高交互双方的处理效率,这在理论上应该也是可行的。

  

阅读全文>>

标签: TCP 应用字段 响应时间 应用响应时间 ART 保活 push 交互式应用 client push 接收缓存 keepalive

评论(4) 引用(0) 浏览(28708)

TCP交互式应用

作者:易隐者 发布于:2012-8-30 21:29 Thursday 分类:网络分析

       TCP交互式应用由于其交互的特性,一般对时延的要求较高,因此一旦有应用数据时便立即向对端发送并要求对端能够及时处理,其交互的报文基本上都是小包(小于MSS),常见的TCP交互式应用主要有telnet、rlogin、互动游戏等,我们先来看一个TCP交互应用的报文分析:

点击查看原图

其具有以下三个明显特点:

1,客户端与服务器端的数据传输是交互式进行的;

2,应用字段长度均较小;

3,带有应用字段的TCP报文PUSH位均置一。

TCP交互式应用的场景(以游戏为例):

       对于实时网络游戏这种交互应用,如果TCP接收方不立即将应用数据提交应用程序处理的话,很可能会导致游戏应用出现卡、客户端与服务器端不同步故障,严重影响游戏应用的正常运行。你想啊,你在玩CS,扮演警察,突然一个悍匪跟你正面冲突,悍匪那边快速操作已经移动位置了,但是悍匪移位这个应用信息却被你的TCP放在接收缓存里,你机器显示器上看到的悍匪还在原来的位置,然后你自然向悍匪原来的位置开枪,结果呢,肯定没伤到悍匪,却被早就移位的悍匪爆头击毙,这时候你会爽吗?肯定骂死这个游戏应用了,呵呵。
        那么交互式应用如何保证应用字段能够被立即处理呢答案就是将带有应用字段的TCP报文(不论应用字段大小)的PUSH位全部置一,虽是小包,但TCP一旦接收到便立即将其交付应用程序处理。

       我在08年做内部《TCPIP详解卷一》培训在讲到第19章《TCP的交互数据流》时,曾今专门捕获了WAR 3的局域网游戏的交互报文,用于讲解TCP交互式应用的特性,现在把这个报文一并放在此供各位参考。

WAR 3的局域网游戏的报文:

点击查看原图

        交互式应用并不是非常常见,因此经常被大家忽略,导致有时在遇到交互应用场景的分析时,将其当作HTTP等常见应用的特性来进行分析,可想而知,如此将走向错误的分析方向,望各位兄弟姐妹引以为鉴。

        这里提到了TCP报文的一个非常重要的标志位——PUSH,我下一篇文章将会针对PUSH位做一个详尽的讨论和分析,望大家关注。

阅读全文>>

标签: 同步 TCP 应用字段 故障 push 交互式应用 交互

评论(0) 引用(0) 浏览(92472)

关于“client push”应用响应时间测量方法的讨论

作者:易隐者 发布于:2012-4-28 9:27 Saturday 分类:网络分析

       在我们分析业务系统故障时,经常会涉及到应用响应时间的测量和分析,有很多网络分析产品都有对应用响应时间的统计测量,比如siniffer,netscout等,不同的产品对应用响应时间测量的方法应用有所差别,前段时间正好看到netscout关于应用响应时间测量的白皮书,里面提到了clinet pull与client push两种常见的基于TCP的应用响应时间测量方法,我在这篇文档中,针对netscout的client push的应用响应时间测量的方法提出了一些改进的建议,这个建议是拿来让大家讨论的,暂且不管这个改进建议在实际统计测量中的可行性,如果能够通过我的这篇文档,能够让大家对应用响应时间测量的方法有跟深入的认识,那么,我的目的就达到了。

阅读全文>>

标签: Netscout 响应时间 应用响应时间 ART get push client push

评论(1) 引用(0) 浏览(19483)

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