Before I upload the capture I need to anonymize it. But let me post the question first, perhaps someone knows a quick answer.
I've been having problems where clients in China are experiencing performance issues when browsing to a sharepoint website. It redirects, and uses single sign on, then tries to load the page. This last page may stay completely blank (except for the titlebar) for about 90 - 120 seconds, then the entire page loads. Other webpages do not show this symptom.
When analyzing a packet capture I can see that all foreign TCP sessions (towards the internet, not local) have a FIN,ACK packet which is received 90 - 120 seconds after the previous packet ... Then, after the sessions is closed, the client starts a new sessions towards the same external server and then everything looks normal again.
In other words, the delay in FIN,ACK matches exactly the delay in showing the webpage. The re-initiation of the TCP sessions looks like it's trying again to load the webpage.
Could this be caused by a session timeout? Does anyone know if this is 'expected' behavior for some phenomenon I haven't found yet?
asked 24 Oct '14, 04:08
I think I figured it out. I thought the answer was a network phenomenon, but you got me thinking it was a client thing. While loading this website, it also loads all kinds of other stuff in the background (like office356.com, microsoftonline.com, sharepoint.com just to name a few).
One of these websites is maps.google.com (don't ask me why, web designers >.<) I saw a recurring pattern that reaching this website (in all captures) failed dramatically with lots of retransmissions and RST packets. The delay on these transmissions went from 3 sec, 6 sec, 12, 3, 6 etc. Adding all these up results in the exact time the website 'chokes' in loading.
So as a test I put all traffic in trough a proxy. This solved the problem, then I manually excluded maps.google.com and the problem returned.
Thanks again for your help.
answered 27 Oct '14, 02:56
It's quite difficult to understand the capture from your description. Where was the capture taken? I assume adjacent to the web server. You really need to trace from the PC as well but I'll have a crack at it.
One reason the above can happen is through the following scenario:
This is similar to a scenario I have in the RPR course I teach and that was based on an eCommerce use case.
The network RTT for China will probably be about 300 ms and so the initial timeout will be 600 ms. The timeout will double with each retry. So the delay will be .6 + 1.2 + 2.4 + 4.8 + 9.6 + 19.2 = 28.8, unfortunately not enough to explain your problem but maybe there are some variations to my theory above.
The trace at the PC is key.
answered 25 Oct '14, 02:31