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

2012-12-10 · 网络分析 · 案例讨论 · 8558 次阅读

上周五，有网友兄弟给我发了一个报文，让我帮忙查看是否存在什么异常问题。我查看其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”等敏感字段而被中间设备丢弃了。