Session (computer science)
From Wikipedia, the free encyclopedia
In computer science, in particular networking, a session is a semi-permanent interactive information exchange, also known as a dialogue, a conversation or a meeting, between two or more communicating devices, or between a computer and user (see Login session). A session is set up or established at a certain point in time, and torn down at a later point in time. An established communication session may involve more than one message in each direction. A session is typically, but not always, stateful, meaning that at least one of the communicating parts needs to save information about the session history in order to be able to communicate, as opposed to stateless communication, where the communication consists of independent requests with responses.
Communication sessions may be implemented as part of protocols and services at the application layer, at the session layer or at the transport layer in the OSI model.
- Application layer examples:
- HTTP sessions, which may allow dynamic web pages, i.e. interactive web pages, as opposed to static web pages.
- A telnet remote login session
- Session layer example:
- A Session Initiation Protocol (SIP) based Internet phone call
- Transport layer example:
- A TCP session, which is synonymous to a TCP virtual circuit, a TCP connection, or an established TCP socket.
In the case of transport protocols which do not implement a formal session layer (e.g., UDP) or where sessions at the session layer are generally very short-lived (e.g., HTTP), sessions are maintained by a higher level program using a method defined in the data being exchanged. For example, an HTTP exchange between a browser and a remote host may include an HTTP cookie which identifies state, such as a unique session ID, information about the user's preferences or authorization level.
Protocol version HTTP/1.1 makes it possible to reuse the same TCP session for a sequence of service requests and responses (a sequence of file transfers) in view to reduce the session establishment time, while HTTP/1.0 only allows a single request and response during one TCP session. However, this transport layer session mechanism should not be confused with a so called HTTP session, since it is not lasting sufficiently long time, and does not provide application level interactive services such as dynamic web pages.
Contents |
[edit] Software implementation
TCP sessions are typically implemented in software using child processes and/or multithreading, where a new process or thread is created when the computer establishes or joins a session. HTTP sessions are typically not implemented using one thread per session, but by means of a database with information about the state of each session. The advantage with multiple processes or threads is relaxed complexity of the software, since each thread is an instance with its own history and encapsulated variables. The disadvantage is large overhead in terms of system resources, and that the session may be interrupted if the system is restarted.
When a client may connect to any in a cluster of servers, a special problem is encountered in maintaining consistency when the servers must maintain session state. The client must either be directed to the same server for the duration of the session, or the servers must transmit server-side session information via a shared file system or database. Otherwise, the client may reconnect to a different server than the one it started the session with, which will cause problems when the new server does not have access to the stored state of the old one.
[edit] Server side web sessions
Server-side sessions are handy and efficient, but can become difficult to handle in conjunction with load-balancing/high-availability systems and are not usable at all in embedded systems with no storage. The load-balancing problem can be solved by using shared storage or by applying forced peering between each client and a single server in the cluster, although this can compromise system efficiency and load distribution.
A method of using server-side sessions in systems without mass-storage is to reserve a portion of RAM for storage of session data. This method is applicable for servers with a limited number of clients (e.g. router or access point with infrequent or disallowed access to more than one client at a time).
In the two scenarios above, using client-side sessions could provide advantages over server-side sessions: in the first case by removing the limitations applied to load-balancing algorithms (which usually translates to load distribution optimisation), and in the second case by allowing the use of sessions in web applications when server disk space or RAM is not available or sufficient for this storage.
[edit] Client side web sessions
Client-side sessions use cookies and cryptographic techniques to transparently use sessions in scenarios.
[edit] How they work
At the end of execution of a dynamic web page, the value of session variables is calculated, compressed and transmitted to the client by an HTTP response header and stored in a cookie on the client (web browser). At this stage the state resides entirely and only on the client file system (or RAM).
For each successive request, once it has been decompressed, the cookie is forwarded to the server which uses it to "remember" the state of the application on that specific client.
Although this mechanism may suffice in some contexts, it cannot be adopted where confidentiality and integrity are necessary. If one wishes to use client-side sessions instead of server-side sessions, the following must be guaranteed:
- confidentiality (optional): nothing apart from the server should access session information
- data integrity: nothing apart from the server should manipulate session data (accidentally or maliciously)
- authenticity: nothing apart from the server should be able to generate valid sessions
In order to accomplish this, the session data needs to be encrypted before being memorised on the client and modification of such information by any other party should be prevented via other cryptographic means.
[edit] HTTP session token
A session token is a unique identifier (usually in the form of a hash generated by a hash function) that is generated and sent from a server to a client to identify the current interaction session. The client usually stores and sends the token as an HTTP cookie and/or sends it as a parameter in GET or POST queries. The reason to use session tokens is that the client only has to handle the identifier (a small piece of data which is otherwise meaningless and thus presents no security risk) - all session data is stored on the server (usually in a database, to which the client does not have direct access) linked to that identifier. Examples of the names that some programming languages use when naming their cookie include JSESSIONID (JSP), PHPSESSID (PHP), and ASPSESSIONID (Microsoft ASP).
[edit] External links
- Understanding Sessions in PHP
- Session tracking methods
- How to choose from Session, Viewstate, Application, Cache, and Cookies
