Why HTTP is a stateless protocol

http stateless or web App stateless

What do we typically mean by the stateless nature of Web applications?

Intuitively, "Each request is independent , its execution and results are not directly related to the previous request and the subsequent request, it will not be affected directly by the previous request response, nor directly affect the subsequent request response condition "

Understand that the meaning of this statement is that the HTTP protocol as a technical background of the Web application request-answer mode is stateless, this fact does not change, and does not because of the addition of cookies, session mechanism to become stateful. Understand that this causal relationship: "What we want to achieve is a Web application that implements the protocol for this application we chose HTTP, which is essentially a stateless communication protocol." But in fact, we need our web application to be stateful. So we have added cookies, sessions and other mechanisms to implement the Web application by state. " So we can understand this:

Web Application =http protocol +session, cookies and other State mechanisms + other auxiliary mechanisms.

In fact, the State or not of the application (software communication) is a very general concept. We know that in the network protocol, we call TCP as a stateful Transport layer communication protocol, while UDP is not; IP is stateless. To understand whether this state or not is determined by the function that you are referring to at this level-whether it is determined by the context-or if it is directly affected by the previous communication process and whether it directly affects the subsequent communication process

Below the IP layer we don't think. We do a Web application that requires the use of network protocols. In fact, according to the principle, the standard TCP/IP protocol provided to our Network layer protocol (FTP, HTTP) is not directly referred to as the application, because in the implementation of some kind of available, direct user-oriented applications (such as Web applications, people can surf the internet), only the HTTP protocol is not enough. So we can understand that. The application layer protocol that is provided to us in the Network standard protocol hierarchy is more like a classification. The application of nature may be a kind of infinite, but according to their characteristics, transmission characteristics, the standard network protocol in the Transport Layer (General network protocol) based on a number of different types of network applications for the Protocol.

At some point, we want to implement some kind of network application, we can use the network Protocol's transport layer to provide the interface to us (that is, socket interface), but sometimes this way is a bit cumbersome, so we still based on the Web application you want to implement, Choose among the protocols for application classification that are available in existing standard protocols. This will eliminate the tedious, general-purpose work.

It can be seen that our actual life in relation to the network of applications, with the standard network communication protocol provided to our application layer protocol is not an absolute correspondence. So the standard network communication protocol gives us the application layer protocol that just provides me with a sort of "recommended". Suggest you: "If you want to implement such an application, you can use the encapsulation protocol directly, not the socket interface."

Let's take a look at the previous diagram, which gives us the status of all levels in the network application hierarchy. It can be known that the support Protocol (lower level) is stateless, the consumer agreement (upper) has a stateless, there is no direct relationship. Or that sentence, the state of each layer of the Protocol is related to its own function when the performance of the state-of-the-way characteristics.

(1) IP is stateless, it is only responsible for sending an IP packet to the specified IP address up. It does not consider the connection of this package with the package that was previously sent and the package behind it. (It may be a re-bundle, possibly a discontinuous package, it does not matter).

(2) TCP is stateful , and it indicates the relationship between packages (pre-and post-relationships, re-packages, etc.) through some control fields (sequence encoding, etc.) in the header. So, with this protocol you can do a reliable transmission. So what does TCP mean by a connection-oriented protocol? In fact, the connection is actually "three times handshake". Three times handshake, the first can guarantee the other party's existence, and then the exchange of the handshake is to prepare for the future status of the transmission.

(3) UDP is stateless, it just adds a port to the IP, and the other things do nothing. In this way it is not possible to achieve reliable transmission, nor does it need to be connected.

(4) HTTP is stateless, its underlying protocol is TCP by state, but HTTP is a complete protocol action, which is done using stateful TCP protocol. And there is no relationship between each protocol action. For example: The 7th time the HTTP protocol packet is requested, it is not known what the package is for. It may be because the last time there was no request for a successful retransmission, perhaps the last request, or something else, the HTTP itself is not known.

(5) WWW application, but most of the time, the WWW application is required to have an association between HTTP actions, which is to make the application stateful. This will provide the user with the best user experience.

So, the problem is, why the HTTP will be designed to be stateless, since now we need the WWW application is stateful, why give him the underlying protocol is stateless. I think this question can be considered from the historical point of view. When the WWW application is very simple, this app is just used to browse the content. If you just browse the content, the stateless protocol is enough, so the implementation can alleviate the burden of implementation, because stateful protocols are relatively expensive to implement (to maintain state, to handle situations based on state, which is why it is recommended that you do not need to use the session, Because the server will give you a lot of things, such as memory space AH). Well, now it seems that the WWW application is mostly in need of state, then whether we should change this protocol to make him a stateful agreement. From this point of view, I think it should not be.

First of all, Web applications and file transfer is different, file transfer, from the beginning to the end is a "as far as possible" action, so this kind of action will not be in the possession of resources, waste it should not waste things. In a Web application, a user may visit a page and stay on that page for a long time before jumping to another page, which is very costly if you need us to maintain state between these two pages (two HTTP request responses).

Secondly, history makes HTTP stateless, and the application requirements for HTTP state requirements, according to the usual practice in the software domain is to maintain the experience of history (no longer the HTTP protocol is substantially changed), compatible with the past software. Add a layer on the HTTP to achieve our goal ("plus one layer, you can do anything"). This layer, is the cookie, is the session and so on.

Finally, the HTTP protocol remains stateless, its full justification, and the need for Web applications based on the HTTP protocol to become stateful is not cumbersome to implement.

What web apps have to make apps stateful

Therefore, on the basis of the HTTP protocol, Web applications introduce cookies, session, application. Such things to keep the state between Web apps.

It is known that cookies, session,application are not standard protocols, but all kinds of web application providers, implementing languages, web containers, etc., are supported by default. Of course, this support is different from the support of the Network Standard protocol, the interface stipulated by the standard protocol, and this kind of mechanism only prescribes the thought. Just tell you, big concept, JSP and ASP of the session mechanism to realize the function and implementation of the method will not be too big.

Some people will be in the Web App in a state of the situation, than the customer to go shopping scene.

Customer: Browser visitor;

Store: Web server;

One purchase: one HTTP access

We know that the last customer purchase does not mean that the customer will buy the next one hours (of course, it does not mean not). This means that the relationship between different purchases of the same customer is uncertain. So honestly, in this case, let the store keep all the information the customer buys, and wait until the next purchase can know the cost of the customer's previously purchased content is very high. So in order to avoid this price, the store thinks that each purchase is an independent new purchase. Shallow lines: Shops do not differentiate between old customers and new passers-by. This is the state of being stateless.

But stores are trying to improve their earnings. She wants to encourage the customer to buy it. So tell you, as long as you buy more than 5 bottles of beer in one months, give you a glass.

Let's see how we can achieve this.

A, the customer issued a magnetic card, which contains the customer's past purchase information.

So the store can know. This is the cookie.

B, to give the customer a unique number, the number of the customer's consumer information, stored in the store's server. This is the session.

Finally, the store can determine the overall decision, whether it is 5 bottles for the wine or 6 bottles. This is application.

In fact, these mechanisms are in the stateless traditional purchase process to add a little something to make the whole process become state. This is the case with Web applications.

Note that ViewState

In fact, from our analysis above, application should not be seen as a mechanism for maintaining state in this sense. It is the "compounding file" that determines how the application is made. But if you derive from the scope covered by this state maintenance mechanism, you will find that application seems to be.

The scope controlled by the session is a session. A session, the session from the first access server to exist, to the server call Session.invalidator () (may be a timeout, possibly other reasons).

The scope of the cookie control has its own definition (not directly related to the session), can be long and short. As long as the cookies placed on the user's file system are not deleted, at least the server also recognizes it. The scope of its control is still there.

In this perspective, sessions and cookies can be categorized as cross-page states. However, the session does not span a single conversation, and the cookie does not cross the limit.

Application, it is associated with this network application.

In addition to these three state mechanisms, some of the special implementations of network applications have their own special things. Like the viewstate of ASP. This thing, in fact, is to use the input type= "Hyde" things to achieve. With the help of the Web server, it can be implemented, a page in the "callback" can also maintain the last page state.

In fact, here to illustrate is the meaning of "callback", in fact, the stateless HTTP protocol, there is no so-called callback concept. The callback here, the situation can be so understood.

I fill in a certain amount of data in the client (in the text box, in the Password box, in the drop-down list). It then triggers an action to access the server, for example: Commit. This time the server accepts my request and then returns to us just this page. This situation we are very common (enter the user name password, click "Login", the server side to determine the password is not correct, return to the landing page, but before we fill in the content has not been erased. This scenario is like a return (you pass it on to me, I pass it back to you). Of course, if you understand the working patterns of Web services, such callbacks can only be an illusion. The front and back two pages are not a single page at all. We can actually implement this scenario (regardless of Ajax). The data on the page is uploaded to the server by request, and the data is injected into the page when the server returns to the page.

And viewstate can make it easy for users to implement this functionality. But one problem with it is that it is attached to the Hide control on the page. Although there are two different pages before and after, but from an ASPX template, the state data on the page is propagated between the hide spaces of the same template page (controlled by the server), impossible, and should not be passed on to other asp.new pages. So we call him a page-level state maintenance mechanism.