[go: nahoru, domu]

Stateless protocol: Difference between revisions

Content deleted Content added
m /* In computing, a stateless protocol is a communications protocol in which no session information is retained by the receiver, usually a server. Relevant session data is sent to the receiver by the client in such a way that every packet of information transferred can be understood in isolation, without context information from previous packets in the session. This property of stateless protocols makes them ideal in high volume applications, increasing performance by removing server load caus...
Reverting edit(s) by 103.170.228.58 (talk) to rev. 1221489598 by Wikipedialuva: Unexplained content removal (RW 16.1)
 
(45 intermediate revisions by 23 users not shown)
Line 1:
{{shortShort description|Communications protocol in which no information is retained by either sender or receiver}}
A '''stateless protocol''' is a [[communication protocol]] in which the receiver must not retain [[Session (computer science)|session]] state from previous requests. The sender transfers relevant session state to the receiver in such a way that every request can be understood in isolation, that is without [[reference]] to session state from previous requests retained by the receiver.<ref>{{cite thesis |last=Fielding |first=Roy |date=2000 |title=Architectural Styles and the Design of Network-Based Software Architectures |type=Doctoral dissertation |publisher=University of California, Irvine |oclc=45706361 |url=https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm |section-url=https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_4_3 |section=3.4.3 Client-Stateless-Server (CSS) |access-date=2021-05-18}}</ref>
 
In contrast, a '''stateful protocol''' is a communication protocol in which the receiver may retain session state from previous requests.
In computing, a '''stateless protocol''' is a [[communications protocol]] in which no session information is retained by the receiver, usually a server. Relevant session data is sent to the receiver by the client in such a way that every packet of information transferred can be understood in isolation, without context information from previous packets in the session. This property of stateless protocols makes them ideal in high volume applications, increasing performance by removing server load caused by retention of session information.
A stateless protocol does not require the [[server (computing)|server]] to retain [[session (computer science)|session]] information or status about each communicating partner for the duration of multiple requests. In contrast, a protocol that requires keeping of the internal state on the [[server (computing)|server]] is known as a stateful protocol. A [[Transmission Control Protocol|TCP]] connection-oriented session is a ''[[stateful]]'' connection because both systems maintain information about the session itself during its life.
 
ExamplesIn [[computer network]]s, examples of stateless protocols include the [[Internet Protocol]] (IP), which is the foundation for the [[Internet]], and the [[Hypertext Transfer Protocol]] (HTTP), which is the foundation of data communication for the [[World Wide Web]]. Examples of stateful protocols include the [[Transmission Control Protocol]] (TCP) and the [[File Transfer Protocol]] (FTP).
 
Stateless protocols improve the properties of visibility, reliability, and scalability. Visibility is improved because a monitoring system does not have to look beyond a single request in order to determine its full nature. Reliability is improved because it eases the task of recovering from partial failures. Scalability is improved because not having to store session state between requests allows the [[Server (computing)|server]] to quickly free resources and further simplifies implementation.
The stateless design simplifies the server design because there is no need to dynamically allocate storage to deal with conversations in progress. If a client session dies in mid-transaction, no part of the system needs to be responsible for cleaning up the present state of the server. A disadvantage of statelessness is that it may be necessary to include additional information in every request, and this extra information will need to be interpreted by the server.
 
The disadvantage of stateless protocols is that they may decrease network performance by increasing the repetitive data sent in a series of requests, since that data cannot be left on the server and reused.
==Examples==
An example of a stateless protocol is [[HTTP]],<ref>{{cite web|url=http://tools.ietf.org/html/rfc7230|title=RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing|work=ietf.org|accessdate=20 August 2015}}</ref> meaning that each request message can be understood in isolation.
 
== Examples ==
Contrast this with a traditional [[File Transfer Protocol|FTP]] server that conducts an interactive session with the user. During the session, a user is provided a means to be authenticated and set various variables (working directory, transfer mode), all stored on the server as part of the user's state.
An [[HTTP]] server can understand each request in isolation.<ref>{{cite journal |url=http://tools.ietf.org/html/rfc7230 |title=RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing|website=ietf.org |year=2014 |doi=10.17487/RFC7230 |access-date=20 August 2015|editor-last1=Fielding |editor-last2=Reschke |editor-first1=R. |editor-first2=J. |last1=Fielding |first1=R. |last2=Reschke |first2=J. |doi-access=free }}</ref>
 
Contrast this with a traditional [[File Transfer Protocol|FTP]] server that conducts an interactive session with the user. During the session, a user is provided a means to be authenticated and set various variables (working directory, transfer mode), all stored on the server as part of the user'ssession state.
 
== Stacking of stateless and stateful protocol layers ==
There can be complex interactions between stateful and stateless protocols among different protocol layers. For example, HTTP is an example of, a stateless protocol, is layered on top of [[Transmission Control Protocol|TCP]], a stateful protocol, which is layered on top of [[Internet Protocol|IP]], another stateless protocol, which is routed on a network that employs [[BGP]], another stateful protocol, to direct the IP packets riding on the network.
 
This stacking of layers continues even above HTTP. As a workaround for the lack of a retained session layer in HTTPstate, [[HTTP server]]sservers implement various [[HttpHypertext sessionTransfer Protocol#Web serverHTTP session management|session management]] methods,<ref>{{cite web |title=session management methods reviewed |url=http://cookiebits.com/htm/tech.htm|last=|first=|date= |work=C cookie bits |location=Toronto|url-status=live |archive-url=https://web.archive.org/web/20190213015423/http://cookiebits.com/htm/tech.htm |archive-date=2019-02-13 |accessdateaccess-date=2011-04-12 |quote=The following material is intended to introduce the reader to the various techniques that developers have used to implement session tracking on the Web. The main operational characteristics of each method are mentioned in addition to the shortcomings that have been observed in usage. Additional information on session management can be found by searching the Internet. […]}}</ref> typically utilizing a uniquesession identifier in thean [[HTTP cookie]] referencing a session state stored on the server, effectively creating a stateful protocol on top of HTTP.<ref name="statefulvstateless">{{cite news |cookietitle=Stateful vs Stateless Architecture |last=Dwyer |first=Gareth |work=Virtasant |date=18 November 2020 |url=https://virtasant.com/blog/stateful-vs-stateless-architecture-why-stateless-won/}}</ref> HTTP cookies violate the [[Representational state transfer|REST]] orarchitectural parameterstyle thatbecause allowseven without referencing a session state stored on the server, tothey trackare requestsindependent{{Clarify|date=May originating2023}} fromof session state (they affect previous pages of the same client,website in the browser history) and effectivelythey creatinghave ano statefuldefined protocolsemantics.<ref>{{cite onthesis top|last=Fielding |first=Roy |date=2000 |title=Architectural Styles and the Design of HTTPNetwork-Based Software Architectures |type=Doctoral dissertation |publisher=University of California, Irvine |oclc=45706361 |url=https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm |section-url=https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3_4_2 |section=6.3.4.2 Cookies |access-date=2021-05-24}}</ref>
 
== See also ==
* [[Representational state transfer]]
* [[Soft state]]
* [[HATEOAS]]
 
== References ==
{{reflist}}
<references/>
*{{FOLDOC}}
 
[[Category:Servers (computing)]]