On 24/04/18 10:46, Vishali Somaskanthan wrote: > Hi all, > > I am working on opening up a persistent connection from Squid -> server. > i have 2 questions. > > 1. I find Squid sometimes sends a [FIN, ACK] signal to server as a > result of which, Squid sends RST and resets the connection. Ideally, for > persistent connections, this shouldn't be the case. Can somebody help me > in this regard? Am I missing any other config directives with respect to > establishing keep-alive connections?? You are missing the part were the server (or something) is sending FIN to Squid. FIN ACK is the _answer_ responding to a server FIN. Connections MAY be closed at any time for any reason. It may not even be the server sending the FIN but some hardware, router or other software or device along the traffic route. RST occuring after the FIN ACK is usually a sign that some other things along the path is probably sending the FIN - not the server itself unless you have REALLY bad routing and latency problems. NP: Experience tells me to start by looking for NAT devices along the traffic path when this happens. Replacing NAT and old routers usually makes this type of symptom magically disappear. > > 2. Are there any ways to configure how many number of keep-alive > connections should be initiated to the server?? No. The default for keep-alive is simply "all of them". Anything you can configure will merely be a reduction in service ability. > > PS: > 1. I am using Squid 4 > 2. I have my /server_persistent_connections on/ and > /client_persistent_connections on/ > 3. Also, I enabled persistent connections for POST requests as well by > the following lines. > /acl post_req method POST PUT > / > /server_pconn_for_nonretriable allow post_req / > That is all you can do. Squid is at the mercy of client and server software - if *they* do not also use every available HTTP mechanism to enable keep-alive on messages then eventually they will send a message that ends the connection. There is nothing Squid can do about that. What you can do is work with the server to ensure *it* is doing its best to retain persistence. Make sure that it supports HTTP/1.1 chunked encoding, AND that it uses that encoding to prevent messages with unknown-length payloads closing connections. If the messages to your server are CONNECT messages, discard all hope. The traffic ceases to even be HTTP right after the tunnel setup is complete. Tunnels can stay open for long time, but when they are done they are done absolutely and the entire TCP connection ends as well. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
