If sticky (session persistence) is configured, then all of the sessions coming from a client to server should endup on the same server. Some applications although same browser window may open multiple TCP sessions for the same browser session and some applications may require stickiness to preserve the state of the application usage. If there is no state replication between different Web or app servers and Application needs stickiness then this may result 10 tcp sessions on Server-1(coming from user-1, and next session from the next client may result 10 sessions on Server-2(coming from user-2)
Since there are normally many users using the application, at some time t all of the servers should have very near total Tcp connections.
The application architecture may need stickiness if it doesn't provide state replication between app servers.
These links could be helpful
http://blog.ipspace.net/2017/03/why-do-we-need-session-stickiness-in.html
https://www.haproxy.com/blog/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-kn...
https://www.nginx.com/resources/glossary/session-persistence/
https://serverfault.com/questions/425623/sticky-sessions-on-load-balancers-with-http-and-https
https://f5.com/resources/white-papers/cookies-sessions-and-persistence
Persistence
Persistence—otherwise known as stickiness—is a technique implemented by ADCs to ensure requests from a single user are always distributed to the server on which they started. Some load balancing products and services describe this technique as “sticky sessions”, which is a completely appropriate moniker.
Persistence has long been used in load balancing SSL/TLS-enabled sites because once the negotiation process—a compute intensive one—has been completed and keys exchanged, it would significantly degrade performance to start the process again. Thus, ADCs implemented SSL session persistence to ensure that users were always directed to the same server to which they first connected.
Over the years, browser implementations have necessitated the development of a technique to avoid costly renegotiation of those sessions. That technique is called cookie-based persistence.
Rather than rely on the SSL/TLS session ID, the load balancer would insert a cookie to uniquely identify the session the first time a client accessed the site and then refer to that cookie in subsequent requests to persist the connection to the appropriate server.
The concept of cookie-based persistence has since been applied to application sessions, using session ID information generated by web and application servers to ensure that user requests are always directed to the same server during the same session. Without this capability, applications requiring load balancing would need to find another way to share session information or resort to increasing session and connection time outs to the point that the number of servers needed to support its user base would quickly grow unmanageable.
Although the most common form of persistence is implemented using session IDs passed in the HTTP header, ADCs today can persist on other pieces of data as well. Any data that can be stored in a cookie or derived from the IP, TCP, or HTTP headers can be used to persist a session. In fact, any data within an application message that uniquely identifies the user can be used by an intelligent ADC to persist a connection between the browser and a server.
