On 07/26/2018 09:15 PM, Amos Jeffries wrote: > On 27/07/18 13:31, Alex Rousskov wrote: >> On 07/26/2018 05:47 PM, Vishali Somaskanthan wrote: >> >>> By re-use I meant to say that the server-connection S (TCP + SSL) is >>> re-used across 2 client connections (C1 and C2), from the same client >>> one after the other is torn down. I, presume that >>> “/server_persistent_connection on/” allows for such a use-case. >> >> server_persistent_connection controls whether a single Squid-to-server >> connection can carry more than one request. It does not (or should not) >> control re-pinning. > Also, pinned connections should never be added to the persistent pool > after pinning. Doing so is a bug IMO. Agreed. > Sending the client handshake to a server makes the TLS end-to-end > stateful between the client<->server. So *that* is the first point at > which pinning is required by Squid. At TLS level, yes. However, one could argue that Squid should honor a (higher level) client and server assumption that they are talking to each other (at HTTP+ level). We will probably break fewer transactions that way. With that idea in mind, the "first point" becomes establishing a TCP tunnel with the server, even if no client Hello pieces are forwarded. > Bumping at step1 does not involve any server information. So no pinning > required. The client is talking to *Squid* over TLS independent of how > the response is fetched. True for TLS level. Not necessarily true for higher levels as discussed above. >>> Case 1: We see that no pinning happens i.e. pinConnection() is not >>> called at all. C1->S gets established, C1 is closed and then C2 re-uses S >> The code just happens to work this way (evidently). It is not something >> I would rely on until the matter is discussed and settled. > I think the described behaviour of C2 using S after C1 has pinned the > connection is a bug. Your earlier "Sending the client handshake to a server" and "Bumping at step1" statements contradict this statement AFAICT because both C1 and C2 were bumped at step1 in "Case 1". FWIW, I would default to honor the tunnel until somebody presents a convincing argument for making the behavior configurable. That is, like you said, treat C2 reusing S (or, more precisely, not closing S when C1 is closed) as a Squid bug. > * S should not be pooled as persistent until the client which triggered > its TCP open has finished with it (eg after the TLS handshake completes). > * Once the handshake begins sending client data, whichever client was > opening it should pin it. I agree that pinned connections should not be pooled. Bugs notwithstanding, they are not pooled today IIRC. I am not sure you meant that, but I doubt a hypothetical feature of pooling before-sending-handshake/before-pinning connections is a good idea, but it does not contradict "pinned connections are not pooled" principle. In practice, once the TCP connection is established, the requester pins it immediately (if needed) so there is no opportunity or need for pooling. > * The sequence of the above two should result in S being pinned before > it is ever considered for the persistence pool. Which should cause it to > be excluded from the servers pool. Agreed. > So IMO when these things are working properly, C2 server selection > should never even see that S exists let alone be able to use it. The open question is whether S should be pinned in the case where C1 is bumped at step1 (i.e., "Case 1" in Vishali's email). If S should be pinned, then I agree with the above statement. If S should not be pinned, then S is just a regular Squid-to-server connection that can be pooled. Cheers, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
