Forum Discussion
6 Replies
- nitass_89166Noctilucent
The developers have a have a web app on servers that times out in 65 minutes.
is it indeed tcp idle timeout? i think it might be user session timeout rather than tcp idle timeout.
- mraful_64014NimbostratusI think your right. Is the session kept alive using the Connectoin: Keep-alive?
- nitassEmployee
The developers have a have a web app on servers that times out in 65 minutes.
is it indeed tcp idle timeout? i think it might be user session timeout rather than tcp idle timeout.
- mraful_64014NimbostratusI think your right. Is the session kept alive using the Connectoin: Keep-alive?
- nitassEmployee
Is the session kept alive using the Connectoin: Keep-alive?
i understand user session normally spans more than one tcp connection. what load balancer has to do is to send user to the server he has visited (i.e. persistence).
Cookies, Sessions, and Persistence by Lori MacVittie
- Kevin_StewartEmployee
There's different definitions of a "session" depending on the OSI layer you're referring to.
A TCP session is the layer 4 connection. Within this definition there are variances based on the protocol you use. For example, things like FTP require a single (or a few) long lived TCP session(s), while HTTP - a stateless protocol - can build and tear down TCP sessions between requests. Of course it's generally bad for performance to allow that sort of thing, so HTTP also allows you to keep a TCP session open between requests with an explicit Keep-Alive header in HTTP/1.0 and natively in HTTP/1.1.
An SSL session is the layer 6 session that a client and server maintain during encrypted communications. This session is largely independent of the TCP session below it.
And then there's the application layer session. This session is highly dependent both on the protocol and the implementation. For example, RDP will maintain a session using a session ID value that's passed by the client. HTTP can use a variety of tricks to maintain session "state", including TCP Keep-Alives and cookies.
So you have to examine what 65 means in terms of a session. Do you have TCP tuned via Keep-Alives to hold a TCP session for that long? Do you even care about TCP Keep-Alives in your environment? Do you have a browser cookie that expires 65 minutes after it was created? Do you have a session entry on the application server that times out after some period of time?