TCP Connections might stay in CLOSE_WAIT state for a period of time after receiving FIN-ACK from upstream

Products

• ProxySG Software - SGOS

Issue/Introduction

TCP Connections might stay in CLOSE_WAIT state for a period of time after receiving FIN-ACK from upstream when HTTP Server Persistence is enabled (default). This should not cause any impact to user experience.

The packet capture below demonstrates an example of the situation where the upstream device sends a FIN-ACK to the proxy.

No.     Time     Source                Destination           SrcPort DstPort Protocol Info
     89 9.824    10.10.10.20           10.10.10.40           56511   8080    TCP      56511 > http-alt [SYN]
     90 9.824    10.10.10.40           10.10.10.20           8080    56511   TCP      http-alt > 56511 [SYN, ACK]
     91 9.824    10.10.10.20           10.10.10.40           56511   8080    TCP      56511 > http-alt [ACK]
     92 9.827    10.10.10.20           10.10.10.40           56511   8080    HTTP     GET http://bto.bluecoat.com/ HTTP/1.1
     93 9.895    10.10.10.40           10.10.10.20           8080    56511   TCP      http-alt > 56511 [ACK]
     96 10.727   10.10.10.40           10.10.10.20           8080    56511   HTTP     HTTP/1.1 302 Found  (text/html)
     99 10.821   10.10.10.20           10.10.10.40           56511   8080    TCP      56511 > http-alt [ACK]
    102 15.683   10.10.10.40           10.10.10.20           8080    56511   TCP      http-alt > 56511 [FIN, ACK]
    103 15.683   10.10.10.20           10.10.10.40           56511   8080    TCP      56511 > http-alt [ACK]
    379 127.865  Cisco_91:91:91        Spanning-tree-(for-bridges)_00        STP      Conf. Root = 32768/0/00:00:00:00:00:00

 

Resolution

If the server persistence is not enabled, the sockets will be closed immediately. If it is enabled, once the response for the current transaction is received, the socket  will be put into the connection cache for further requests if SG has not received a FIN signal from the server by that time.

Once it is put into the cache, it wont be monitored for any FIN signal from the server and SG will close the connection either when it reaches the persistent timeout or when the subsequent request try to use the socket.

 

To workaround this :

- disable HTTP Server Persistence

SG8100#(config)http no persistent server
 

- reduce the HTTP Persistent-timeout Server to a smaller value :

SG8100#(config)http persistent-timeout server ?
 <# seconds> or 0 to disable