get - 蚂蚁网-多维人生，三实而立！

欢迎关注: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) 浏览(111071)

别具匠心的HTTP应用层行为设计

作者：易隐者发布于：2012-12-26 16:09 Wednesday 分类：网络分析

今年的年初，有位兄弟在QQ跟我讨论一个较为少见的报文交互情况，我当时在看了具体的报文交互之后，对他说是某种HTTP探测机制，他则对我说有人认为是某种SACK的重传机制，记得我曾说过我会找时间好好研究一下这个交互的行为，后来的确也写了一些分析、画了一些图示，但是在未完成的情况下被耽搁了，直至最近才把这个翻出来，闲话少说，我们还是直奔主题，一起来看一下这个有意思的应用交互行为吧。

这个报文交互过程如下：

其交互的数据流图如下：

我们再来看一下其中几个重要报文的详细解码，首先看服务器的HTTP 200 OK响应报文的解码，如下图所示：

服务器响应报文解码（No128报文解码）

这个服务器的响应报文，其应用字段长度为585字节，序列号为101871，最后两字节应用字段为Hex 0d0a，我们再来看一下客户端对这个服务器响应报文的确认报文的解码，如下图所示：

从上图解码来看，这是一个最为常见的确认报文，确认号为102456（101871+585）。我们再看看服务器的重传报文解码，如下：

服务器后续重传报文解码（No132报文解码）

我们能够清楚的看到，这个来自服务器的重传报文其应用字段为1字节，序列号为102454，应用字段为Hex 0d，通过序列号我们可以看出这个重传报文并不是No130应用响应报文的重传，而仅仅是重传了No130报文中倒数第二个字节的应用字段！我们再看看客户端对服务器这个重传报文（No132报文）进行确认的报文解码：

客户端对服务器这个重传报文（No132报文）进行确认的报文解码

客户端确认号为102456，但是其SACK却显示为102454-102455！确认号大于块左边界、块右边界值，这是不符合SACK的相关规范的！

我把这个交互过程制作一个更为清晰明了的图示如下：

点击查看原图

现在大家应该清楚这个交互的具体情况了，那么疑问来了：

1，服务器端为何重传倒数第二个字节的应用字段？
2，客户端在确认服务器的重传报文时，为何使用不规范的SACK？

带着这两个疑问，我用自己的机器访问163网站，重现了这个交互过程如下：

这个过程跟上面的交互过程几乎是一致的，我们就不再做详细的分析了，但是我们来仔细的查看一下客户端对服务器一字节应用字段重传的确认报文的解码：

客户端对服务器重传报文进行确认的报文解码

在这个解码中，我们看到，我的机器在对服务器的一字节重传报文进行确认时，并未使用SACK，而是正常的重传了对服务器应用响应报文的确认，这是一般情况下的正常处理。这也说明了服务器的这个“重传一字节应用字段”的行为并不会导致客户端的确认出现异常。只有系统处理差异才能够解释这种情况的发生：我使用的客户端是XP操作系统，而那位与我讨论的兄弟使用的是其他操作系统。不同的操作系统在遇到这种重传部分应用字段的报文时处理机制不一样导致了疑问2的出现，这种不合SACK规范的确认报文虽然不会对服务器造成交互的影响，但足以让我们产生困惑，因此，严格来说，那位与我讨论的兄弟所使用的端系统如此处理是异常的。

如此我们解决了第二个疑问。

而针对第一个疑问，问遍了google和baidu无果后，让我们一起来分析一下这种行为可能带来的好处和坏处。

服务器在作出应用响应之后，在200ms左右未收到来自客户端的确认报文，则将倒数第二个字节的应用字段封装重传给客户端。

这样做的好处是在如下几种情况下会提高服务器与客户端的交互效率：

1，服务器发往客户端的应用响应报文在网络传输过程中被丢弃
服务器的响应报文被丢弃，未到达客户端，在这种情况下，服务器的这个“200ms内未收到客户端ACK报文则重传一字节应用字段”的行为，避免了服务器端被动等待客户端确认报文到达直至重传定时器清零，服务器才可以重传报文，服务器通过这种行为主动探测客户端对服务器报文接收的情况，提高了交互的效率。

服务器应用响应报文被丢弃时的交互过程图示

2，客户端对服务器应用响应报文的确认在网络传输过程中被丢弃
如果客户端对服务器应用响应报文的确认报文在到达服务器之前被丢弃了，那么，会出现服务器端等待客户端确认报文到达的情况，这是一个超时重传的等待时间，一般至少在数秒之间，而服务器的这个“200ms内未收到客户端ACK报文则重传一字节应用字段”的行为，可以在200ms左右主动发送“封装最后倒数第二个字节应用字段的重传报文”，这个报文到达客户端之后，客户端将重新发送确认报文，这减少了超时重传的等待时间，从而提高了交互的效率；

客户端对服务器响应报文的确认被丢弃时交互过程的图示

坏处就是：与一般正常交互过程相比，可能会给网络多带来两个64字节的小包。

如果客户端正常收到了服务器的应用响应报文，只是客户端的ACK报文较慢（网络传输延时或者客户端的delay ack机制等）到达服务器，则服务器会发送这种带有一个应用字段的重传报文，而客户端在收到这个报文后，会对这个报文进行确认。

而这个坏处相对于其带来的好处而言，实在不值一提，因此不得不说，这个HTTP应用行为的设计是别具匠心的！

那么为什么是倒数第二个字节而不是倒数第一个字节、倒数第三个字节或者其他字节？理论上来说重传任何一个字节达到的效果都是一样的，只重传部分应用字段（一个字节）是为了节约网络带宽资源，或许程序设计者如此设计有一些特别的用处，但是这只能去问程序设计者本人了。

另：我已将相关报文文件作为附件上传至此，有兴趣的兄弟姐妹可下载学习探讨，下载后解压即可使用wireshark直接打开查看。

阅读全文>>

附件下载：
别具匠心的HTTP应用行为设计-兄弟提供的原报文.zip 203.32KB
别具匠心的HTTP应用行为设计-我重现的报文1.zip 2.1KB
别具匠心的HTTP应用行为设计-我重现的报文2.zip 4.21KB

标签: sack 解码重传 get delay ack HTTP 应用行为

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

可能的URL超长导致丢包案例

作者：易隐者发布于：2012-12-10 14:03 Monday 分类：案例讨论

上周五，有网友兄弟给我发了一个报文，让我帮忙查看是否存在什么异常问题。我查看其TCP会话交互过程，如下图所示：

点击查看原图

单从这个报文交互来看，客户端与服务器的TCP连接建立正常，客户端已经向服务器发送过get请求，并得到了服务器的确认，问题出在客户端向服务器发送的第二个get请求：“
http://192.168.0.12/Default_Login.aspxusercode=x6x9&password=81xx9xxx52x04xx20036xxx8313xx055&

MyCurrentCompany=&rdnum=0.5966797953405811”。

客户端发出这个get请求之后，在37秒的时间内重传了5次，服务器端无应用数据需要主动的发给客户端，因此在这个时间段内我们未见来自于服务器的报文，而如果客户端的发送的这个get请求到达了服务器端，则服务器会根据其请求内容作出应用响应，最起码服务器端会对客户端的TCP报文发送ACK确认。但是这些都没有出现，这能够说明客户端的get请求报文根本未到达服务器端，即客户端的这个get请求报文被中间设备丢弃了，我们查看客户端的发送的第二个get请求报文的解码：

点击查看原图

我们发现这个报文除了其请求的URL长度较长（420字节）外，其他似乎也没什么特别的，因此，个人推测其被中间设备丢弃的原因可能是其URL超出了防火墙/负载均衡/WAF/IPS等设备的限制，或者是URL中包含“uesr”、“password”等敏感字段而被中间设备丢弃了。

阅读全文>>

标签: TCP 负载均衡解码 ACK确认防火墙 IPS get URL超长 get请求

评论(3) 引用(0) 浏览(7382)

应用响应时间（ART）

作者：易隐者发布于：2012-9-13 18:38 Thursday 分类：网络分析

在实际的业务应用操作中，客户端向服务器的操作主要分为两类，一类为客户端向服务器上传数据，如HTTP应用中的“post”操作，另一类为客户端从服务器取数据，如HTTP应用中的“get”操作。应用程序对这两个操作的处理机制不同，因此有必要把应用响应时间按照客户端的这两类操作进行划分，下面分别针对服务器端的这两种响应时间进行阐述。

“get ”操作应用响应时间

“Get”操作主要是指客户端向服务器端发送取数据的请求。应用程序对“Get”操作的响应时间主要是指服务器收到get请求数据包至服务器响应第一个带有应用层数据的数据包的时间间隔。其响应时间的计算如下图所示：

Get操作应用响应时间计算示意图（一）

应用程序在处理客户端请求的时候会消耗一定的时间，并不一定能够及时响应请求的数据，为了不让客户端等待过长的时间（时间过长，很可能导致客户端重传数据），服务器很可能首先对客户端的TCP数据段进行响应（Delay ACK）。在上面的图示中，第二个包是TCP层的响应，其应用层的数据的长度len=0，第三个包包含有应用层数据，其数据长度len=n，因此，该应用响应时间就是T3-T1。而下图中，应用程序很快的响应了客户端的请求，第二个包中就已经包含有应用层数据，其长度为len=n，其应用响应时间的计算就是从第二个数据包开始，为T2-T1。

Get操作应用响应时间计算示意图（二）

我们再看一下实际应用中的get操作应用响应时间的计算。下图为web应用中某“get”操作的数据交互过程：

web应用中GET 操作的交互过程

在上图中，我们可以看到，当客户端向服务器发送取数据的get请求后，服务器的传输层首先针对客户端的TCP数据段进行了响应，其应用层数据长度为0，接下来第三个数据报是服务器应用程序对客户端get请求的响应，其包含应用数据。在这个过程中，“get”操作应用响应时间就是第三个数据包与第一个数据包的时间间隔，在该例子中为0.08149秒。

“Post”操作应用响应时间

“post”操作主要是指客户端向服务器上传数据的操作。“Post”操作应用响应时间主要指服务器端接收到客户的post操作数据包与服务端处理完这些数据后对客户端做出相应响应的时间。关于这种应用响应时间计算的方法请参见本博客《关于client push操作应用响应时间的计算方式的讨论》一文。这篇文章较为详细的描述了客户端向服务器递交数据时的服务器应用响应时间测量的方法。

在实际的应用中，存在两种常见的应用场景，一种是服务器端在收到客户端的数据，应用进程处理完毕后，需要向客户端发送响应数据；另外一种情况是服务器端接收并处理来自客户端的数据，但是应用进程并不会发送响应数据给客户端。下面我们分别针对这两种类型的应用进行描述。

1，有应用层响应数据的

当客户端向服务器发送“post”操作数据后，应用层如果有应用数据的响应，那么计算应用响应时间的方法与计算“get”操作应用响应时间的方法一致。就是指服务器收到post请求数据包至服务器响应第一个带有应用层数据的数据包的时间间隔。下图展现的就是一个针对客户端的 “post”操作，应用进程产生应用层响应数据的交互过程：