Hi, We have one application which uses wininet.dll to communicate to server(192.168.0.155).Client (172.16.20.5) requesting some data from http/tcp service from linux server (192.168.0.155). Client is installed on winXP OS. Why client sends FIN ACK after 40s? Why so slow? He should send FIN ACK immediately. Client is using wininet.dll to communicate to server . I tried may options while editing reg_keys also, but no success . also tried on win 7 machine but found same logs. How to debug this? What could it be? I traced some of the secure websites ,they also show delay but not so much delay. asked 04 Mar '14, 23:40  Abhi |
One Answer:
What you have there is completely normal behavior when using HTTP keep-alives. Your client (e.g in frame 136) says "Connection: Keep-Alive" and the server accepts that (e.g in Frame 138), which means that the server allows the client to request multiple documents in one single TCP session. This is useful to avoid opening many connections for many documents. After the server sends the requested document in frame 138 it waits another 20 seconds (in case the client needs anything else) and then says "okay, I'm done" by sending a fin in frame 211, because obviously there is no further request. The client accepts that but holds back its own FIN for another 40 seconds in case there are packets coming in out of order. All of this is pretty normal behavior when using FIN to close a connection, because it does not mean that both have to close the connection synchronously. They can do it quite indepentently. If you want to avoid this behavior you could try to set the server to disallow keeping connections open, but that will cost performance when the server is requested a lot of documents from a couple of nodes. Or you could try a different web browser, because there are some (like Microsoft IE) that use RST instead of FIN, which is closing the session instantly. answered 05 Mar '14, 00:20  Jasper ♦♦ |
thanks for ur answer Jasper and clearing the things...
here we are not using any browser .Installed agent communicate server through 8080 port.
Can u pls suggest some other options for immediate response rather than 40s delay.
Let me ask you one thing first: is it a problem that the connection takes 40s to close the connection? Yes, it is a long time, but it is not really a "delay" when it comes to the actual data transfer. All data is exchanged already, only the session shutdown takes a long time. That usually does not delay the application at all because it is a TCP stack topic.
The only two reasons to fight the 40s shutdown are 1. you don't like it because it is unnecessary 2. you're opening tons of connections and the client gets into trouble by having too many open connections simultaneously
If both reasons do not apply you could just ignore the delay for the time being.
we have tried turning off "Connection: Keep-Alive" at server . And now there is NO delay while closing connection. We are testing this option at another level .
Allow me to add to Jasper response. In general case, the delay in closure of a HTTP session should not be a problem as Jasper has pointed out. In fact, the reason why HTTP keepalive is added in HTTP/1.1 is to improve the performance of the HTTP performance so that each and every HTTP request doesn't have to go through the normal TCP handshake and resulting in more round trips needed and the TCP keepalive allows the clients to reuse the existing session keep the session alive for a little longer.
BUT, there is a cost to that and this could be a problem (I am not sure if this is the case that you are trying to solve. If not, i'll just leave the settings to default). If you have a very very busy server where you ran out of memory or TCP connections and new connections are having problems to be created due to too many existing connections not being closed fast enough.
In some cases, I've troubleshooted whereby you want to close the connection immediately when you are doing IPSLA measurements from a device such as routers so that the correct readings are being measured/taken and the correct way to do that is to force the client IPSLA to run HTTP/1.0 rather than requesting it via HTTP/1.1 and that will force the connection to be close immediately.
Hope that helps!