!!! Overview
[{$pagename}] is a semi-permanent interactive information interchange, also known as a dialogue, a [protocol] conversation or a meeting, or [Communication] between two or more communicating [Entities].

Typically, the [Protocol Client] initiates a [{$pagename}] with a [Protocol Server] but may also, perhaps, incorrectly, refer to a [peer-to-peer] [{$pagename}].

Communication Transport 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] [{$pagename}], which allow associating information with individual visitors
* A telnet remote login session

[Session Layer] example:
* A [{$pagename}] Initiation Protocol ([SIP]) based [Internet] phone call

[Transport Layer] example:
* A [TCP] [{$pagename}], which is synonymous to a [TCP] virtual circuit, a [TCP] connection, or an established [TCP] socket.[HTTP]/1.0 was thought to only allow a single [Request-Response] during one Web/[HTTP Session]. Protocol version HTTP/1.1 improved this by completing the [Common Gateway Interface] ([CGI]), making it easier to maintain the Web Session and supporting [HTTP Cookies] and file uploads.

Most [Client-Server Exchange] [sessions] are maintained by the [Transport Layer] - a single connection for a single [session]. However each transaction phase of a Web/[HTTP session] creates a separate connection. Maintaining session continuity between phases requires a [Session ID]. The [Session ID] is embedded within the <A HREF> or <FORM> links of dynamic web pages so that it is passed back to the [CGI]. [CGI] then uses the [Session ID] to ensure session continuity between transaction phases. One advantage of one connection-per-phase is that it works well over low bandwidth (modem) connections.!! [Server-side] web [{$pagename}]
[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 some 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).

The use of [Tokens], especially [JSON Web Tokens] is also a method of maintaining [{$pagename}]s across [Load Balancing]

!! [Client-side] web [{$pagename}]
[Client-side] sessions use cookies and [cryptographic] techniques to maintain [state] without storing as much [data] on the server. When presenting a dynamic web page, the server sends the current state data to the client (web browser) in the form of a [cookie]. The client saves the [cookie] in memory or on disk. With each successive request, the [client] sends the [cookie] back to the server, and the server uses the data to "remember" the [state] of the [application] for that specific client and generate an appropriate response.

This mechanism may work well in some contexts; however, data stored on the [client] is vulnerable to tampering by the user or by software that has access to the client computer. To use client-side sessions where [confidentiality] and [integrity] are required, the following must be guaranteed:

* [Confidentiality]: Nothing apart from the server should be able to interpret session data.
* Data [integrity]: Nothing apart from the server should manipulate session data (accidentally or maliciously).
* Authenticity: Nothing apart from the server should be able to initiate valid sessions.
To accomplish this, the server needs to encrypt the session data before sending it to the client, and modification of such information by any other party should be prevented via cryptographic means.

Transmitting [state] back and forth with every request is only practical when the size of the [cookie] is small. In essence, client-side sessions trade server disk space for the extra bandwidth that each web request will require. Moreover, web [browsers] limit the number and size of cookies that may be stored by a web site. To improve efficiency and allow for more session data, the server may compress the data before creating the [cookie], decompressing it later when the [cookie] is returned by the client.

!! [HTTP] [{$pagename}] [token]
A session token is a unique identifier 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 [HTTP GET] or [HTTP POST] queries. The reason to use session [tokens] is that the client only has to handle the identifier—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 HTTP cookie include: 
* [JSESSIONID] (JSP)
* [PHPSESSID] (PHP)
* [CGISESSID] (CGI)
* [ASPSESSIONID] (ASP).!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Session_(computer_science)|Wikipedia:Session_(computer_science)|target='_blank'] - based on information obtained 2016-08-09