My company uses a 3rd party cloud-application. When performing a function using the web interface browser, the application server doesnt seem to respond, but it really does. It takes over a minute for it to give any visual indication that it's working, but it does complete.
The 3rd party vendor doesn't have any idea why it's running like this.
I used Wireshark to capture the browser<->server request/response. There's some things about not being able to re-assemble the packets, but I'm not able to fully figure out what is really happening.
There are no errors. The web application actually completes the request. but it should be happening in < 1 to 2 seconds, not 50-75 seconds.
The third party vendor says their server is running fine. I used Wireshark to capture a brief session. In looking at it, there's some re-assembly errors. But I honestly can't figure this out.
I'm trying to understand if there's something on our end (our internal network), or if there's something at issue with their web server/network. I'm trying to not finger point, but simply root cause.
Would anyone be willing to look at this capture and see if anything obvious stands out? I see a reassembly issue, but outside of that, I don't see anything obvious. Then again, I'm hardly an expert here.
THe web appliation never gives an error. It always completes. But in looking at the capture it almost seems like sockets between client and server are started then closed, then started on a different client ephemeral port.
The destination server in the PCAP is 220.127.116.11, port 80. My client is 192.168.1.117.
I'm not trying to prove that there's a fault on their end or an application issue. I'm just trying to see if there's some fundamental networking issue / problem first. THe web application is an IIS app on port 80.
I've uploaded the PCAP to the url in the body of this post. ANyways, I honestly can't understand what is happening. Looks like there's a re-assembly error (at #1934), an RST (#1051). But by the end of the capture, the web page finally finishes the request without error.
I could really use some help. Like I said, not trying to point fingers. Just trying to root cause.
If there's anyone who'd be willing to look at the capture and let me know what you think, I'd be so grateful.
asked 27 Jul '16, 17:18
edited 28 Jul '16, 02:55
The answer to this problem lies in the http.data field which identifies the GMT timestamp when the web server was sending the HTTP OK messages. The client's clock doesn't seem too far away from the time-stamp at the server by looking at these packets, approximately 200 ms. For non-delayed responses, the answer from the server http.time arrives between 50 - 80 ms.
The timestamps in the http.date indicate that the server was already late sending those. For me clearly a slow HTTP server ( or Application server or backend systems)
answered 31 Jul '16, 13:12