I think a session is like a communication history. It begins when client logs in and ends when client logs out. The server normally identifies a client with an session ID to keep track of the client's current state.
meatie
@HingOn, thanks for the explanation!
dumbo_
In class question: Why not move the state to the load balancer? Load balancer is supposed to be simple to scale. So if we put more logic in the load balancer, there's more logic sequential, and we shouldn't have these many workers in the first place.
kayvonf
@dumbo: It's also a separation of concerns/modularity argument -- which is often very important in the web-architecture world. You might want a turn-key load balancer that you get off the shelf, such as Amazon's Elastic Load balancing service. This system will have no knowledge of a specific site.
kayvonf
Nice little blog post on the some of the advantages/disadvantages of client-side session storage vs. server-side session storage.
@meatie: Http is designed as stateless protocol. Session is designed to let service remember the temporary status of requesting user. User browser sends a session cookie to server, server decode the session cookie to the right session. Therefore, Facebook can know your name, your friend list by the session cookie without asking you to login again.
toutou
Server-side session can be stored in IIS process, stateServer process or the database. Among the three methods, the first is often used but the information would be lost after a web server failure. The other two will keep data even when the server fails. However, it will results in a worse performance due to the serialization and de-serialization.
zhiyuany
Beyond the architecture, DNS also acts as one kind of load balancer. For the same domain name, there might be multiple ip address for it, and DNS server responses requests of same domain by multiple addresses in the round-robin manner.
What is a session?
I think a session is like a communication history. It begins when client logs in and ends when client logs out. The server normally identifies a client with an session ID to keep track of the client's current state.
@HingOn, thanks for the explanation!
In class question: Why not move the state to the load balancer? Load balancer is supposed to be simple to scale. So if we put more logic in the load balancer, there's more logic sequential, and we shouldn't have these many workers in the first place.
@dumbo: It's also a separation of concerns/modularity argument -- which is often very important in the web-architecture world. You might want a turn-key load balancer that you get off the shelf, such as Amazon's Elastic Load balancing service. This system will have no knowledge of a specific site.
Nice little blog post on the some of the advantages/disadvantages of client-side session storage vs. server-side session storage.
http://phillbarber.blogspot.com/2014/02/client-side-vs-server-side-session.html
@meatie: Http is designed as stateless protocol. Session is designed to let service remember the temporary status of requesting user. User browser sends a session cookie to server, server decode the session cookie to the right session. Therefore, Facebook can know your name, your friend list by the session cookie without asking you to login again.
Server-side session can be stored in IIS process, stateServer process or the database. Among the three methods, the first is often used but the information would be lost after a web server failure. The other two will keep data even when the server fails. However, it will results in a worse performance due to the serialization and de-serialization.
Beyond the architecture, DNS also acts as one kind of load balancer. For the same domain name, there might be multiple ip address for it, and DNS server responses requests of same domain by multiple addresses in the round-robin manner.