Forum Discussion
Tony_Jarvis_132
Altostratus
AltostratusConnections vs sessions
Hi all
This is my first post so apologies if I'm breaking any standards. I'm having trouble figuring out the difference between connections and sessions. No matter how much I Google this, I'm not finding a simple answer.
Let me phrase it this way...if you read the article on "LTM: Dueling Timeouts" (https://devcentral.f5.com/articles/ltm-dueling-timeouts), it says: "Persistence timeouts are actually idle timeouts for a session, rather than a single connection." Unfortunately that statement does not tell us anything meaningful unless the definition of a connection and session is clarified.
Or to put it another way, if you consult the F5 V11 configuration guide as it relates to session persistence profiles (http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-1-0/ltm_persist_profiles.html), it says: "The primary reason for tracking and storing session data is to ensure that client requests are directed to the same pool member throughout the life of a session or during subsequent sessions." So my question here would be, what factors influence whether ongoing HTTP GET requests (as an example) constitute a single session, or subsequent sessions?
I'd really appreciate somebody's help here as I know this is a fundamentally basic concept but I'm unable to find a definitive answer.
What_Lies_Bene1Cirrostratus
For HTTP:
HTTP Is considered to be a stateless protocol in that the client and server do not store state data in any way. A request is sent and a response received; this ‘transaction’ has no impact on future ones, nor do earlier ones affect this one. Cookies are used to provide a form of state when required.
Multiple transactions between the same client and server, completed over the same established TCP connection are considered a session. A session may also comprise of multiple TCP connections (again between the same client and server) to improve performance. Sessions rely on HTTP Persistent Connections.
Session persistence is only required where a single session uses multiple TCP connections - we need to ensure the second, third... connection in that session is sent to the same real server. This ensures that any state information stored only on that server (outside of HTTP), related to the session the connections form a part of, is valid. If those connections were Load Balanced to different servers the lack of the session state context (and loss of server affinity) will most likely result in application errors.
- What_Lies_Bene1
You're welcome. So, multiple TCP connections from the SAME client (same IP but different source port of course) to the same destination IP AND port. Yes, it would be correct to call this a TCP socket.
Yes, your second statement and paragraph are correct. You got it!
MOHIT_125417Nice explanation here!!!!!
rogeriopalmaresNimbostratus
Very nice explanation! Thank you!
YugandharHi,
>> Multiple transactions between the same client and server, completed over the same established TCP connection is considered a session.
i think an example for the above could be .. when a HTTP request is made .. the TCP connection is made on port 80 and after that multiple HTTP transactions like GET POST etc happen on the same port number 80 between the same client IP and server IP therefore we call this a session.
>> You also mentioned that a session may also comprise of multiple TCP connections (again between the same client and server). But I think this contradicts your initial statement reg session which says that the transactions that happen between same source and destination ips over an existing TCP connection is called a Session.
Could you please explain the above statement with an example ?.
Thanks,
Yugandhar.