Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what does the" state "in the stateless http protocol mean". In the daily operation, I believe that many people have doubts about what the "state" in the http protocol stateless refers to. The editor consulted all kinds of materials and sorted out a simple and useful method of operation. I hope it will be helpful to answer the doubts of "what does the" state "in the http protocol stateless mean? Next, please follow the editor to study!

What exactly does [state] in http protocol stateless refer to?!

1. Let's take a look at the other two concepts of this sentence: (the standard http protocol is stateless, connectionless) the standard http protocol refers to the http protocol that does not include cookies and session,application. None of them belong to the standard protocol, although various network application providers, implementation languages, web containers, etc., support it by default.

What does connectionless mean?

Each access is connectionless, and the server processes the access in the access queue one by one, closes the connection after processing one, and then deals with the next new

Connectionless means limiting the processing of only one request per connection. After the server processes the customer's request and receives the customer's reply, it disconnects.

For stateless, I see a lot of vague expressions (official or tutorial) that look very uncomfortable (but it's actually right) across a layer of frosted glass. (later I found out why I thought it looked uncomfortable. Because they have introduced a lot of new nouns, and they are obviously a generalized noun that may be used in many places, the greatest effect of these words is to confuse concepts, which I marked below).

The protocol has no memory ability for transaction processing [transaction processing] [memory]

No context for the same url request [context]

Each request is independent, its execution and result are not directly related to the previous request and the subsequent request, it will not be directly affected by the previous request response, nor will it directly affect the subsequent request response [no direct contact] [directly affected]

The state of the client is not saved in the server, and the client must take its own status each time to request the server [status]

I must get a definite and specific explanation!

These points give me the direction of my next step:

1. [the state of the client is not saved in the server, and the client must take its own status to request the server every time.] does the status of the client here exactly mean that the server does not save the client's information? But obviously not.

2. [the stateless nature of HTTP seriously hinders the implementation of these applications. After all, interaction needs to be a link between the past and the future, and simple shopping cart programs also need to know what products users have chosen before.] I question why stateless shopping carts can not be implemented. Can't the server store things?

3. [each request is independent and has no direct relationship with and] I think this statement is more reliable, but the so-called no relationship between different requests, does it mean that the content of the request has nothing to do with the request, or does it just mean that the request itself has nothing to do with it?

The content of the request does not matter. It is only possible that there is no user data on the server, but obviously it exists.

The request itself does not matter, what is the point of this, what is the value of each request?

According to this direction, I did a simulated visit experiment: if there is no cookie, no session, only http, then these things will happen when a registered user visits the shopping site:

1. Prerequisite conditions:

The server must have established a data table for each registered user to record the user's data.

Http is connectionless

two。 The first step requires logging in

The user sends the user name and password to the server through http, and the server compares them with the user information they have. If they are consistent, the login information is successful.

3. Then the user clicks on a product page

This action is equivalent to entering the URL of a product page

If the product page is confidential and is not made public, it needs to be accessed by the user.

Although http can transmit the user name and password, and just entered it, and verified successfully, but because the server will not remember your login status, your client will not store the user name and password you just entered

Therefore, because this visit can not determine your identity, the visit can only fail.

At this time, if you want to solve this problem, and there is no cookie, no session, then you can only visit the URL and continue to bring your user name and password (keep typing), just like my current APP.

4. Suppose the problem in the previous step is solved, that is, the user name and password will be manually entered every time you visit, and now the situation is: you have selected several items in your shopping cart, and you want to add another item. So you click on the plus sign next to an item.

This action is also equivalent to entering a URL that sends a request to add the item to your shopping cart

The system first verifies your identity with the user name and password you sent, then accesses your database and adds a piece of data under the shopping cart properties, that is, the data of this product.

After the operation is completed, the operation is returned to be successful and the access is terminated.

5.OK, at the end of the experiment, it seems that you can solve the problem without cookie and session, but in fact, both operations have big problems.

Every time you access something that requires permission, you need to enter a user name and password on the client side, so there is no need to repeat the tediousness of this item.

Every operation you do has to interact with the underlying database of the system.

There is a great waste of performance in a small number of visits. It is very easy to think that a large number of operations must be more efficient, so I think of the cache area.

Your unimportant trivial data is also written into the database, along with your main data

In fact, adding and deleting shopping carts over and over again is only related to this browse, or this session, it is temporary data, it has nothing to do with the main information of users, and they are of little value. Pure redundant data (do not rule out the fact that some companies feel that this kind of data also has great value for their ingenious use), with what to store these temporary data, we can easily think of cache areas.

Search the official account of Java bosom friend, reply to "back-end interview" and send you a treasure book of Java interview questions.

Through this simulated interview experiment, combined with the previous thinking direction, we know three points:

The user's data must be stored on the server, and the addition, deletion, modification and query you submitted can also be handled, so the state of "the server does not save the client's state] does not refer to the user's data, and our guess is not correct.

Our query is right. Stateless shopping carts can be realized through the user data stored on the server.

However, there are three big problems with implementing a shopping cart in this way. As a result, we can't help but wonder whether the solution of these three problems has anything to do with the word "state" that we don't know exactly. So, next, let's explore the meaning of state by solving these three problems.

From the above, we can add some mechanisms on the basis of http to solve the above three problems.

1. It is very necessary to add a log book on the client side. It just happens that the official cookie mechanism is the same as this one, and its use is indeed as discussed above. It is generally used to identify visitors.

two。 Adding a cache area to the server can solve the latter two problems at the same time.

With this cache area as a data buffer, you don't have to access the database again and again, wasting a lot of computer resources, but finally unify it into the database.

With this cache, you don't have to put temporary data in the database, you just need to sort out the data and put the useful data into the database after your communication is over.

3. Here naturally leads to an important concept: session, as a buffer storage area is separated from the database, the reason is not blunt, it has its unique important and irreplaceable role. This thing happens to be the same as the official session mechanism.

3.1. In addition, there is a very confusing understanding that people tend to deviate from the main role of session: that the value of the existence of session is to assign a sessionID to visitors instead of username and password.

3.2. Why is it very confusing? because session did do it, and played a big role, so it is right, but only half of it, and does not involve the nature of the problem, this situation is the most dangerous (seems to be very persuasive and persuades you, so it is difficult for you to have the motivation to keep looking, but the real situation deviates from it, but the deviation is not big, so it is difficult to persuade you back. There is only something faintly wrong, at this time you are closest to and farthest from the truth)

3.3. By the way, why is it right, that is, another useful thing to do with session:

Give each session an ID, on the one hand, to facilitate your own query, on the other hand, give the ID to the user, so that the user can directly use this ID to identify himself instead of the user name and password the next time he visits.

First of all, is this ID safe? Is this ID more secure than directly passing the user name and password?

SessionID, which is not strictly encrypted, is as insecure as username and password.

But in comparison, sessionID is safer.

And using https is completely safe.

1. It is easy to think that the combination of user name and password is specially set up to be complicated. Is it too insecure for you to replace it with a new set of numbers?

two。 We know that the http protocol itself is completely unencrypted. If you use a user name and password, the first access is placed in the http header, and then the password is automatically saved and placed in the cookie. These are completely unencrypted, and its security is basically zero, that is, streaking. As long as it is stolen, it will be lost.

3. So, in this sense, the security of sessionID is no different from using a user name and password

4. But in fact, although http itself cannot be encrypted, there are some software that can manually encrypt you at the application level. For example, QQ will use a user name password plus temporary verification code to combine hashing, and sessionID plus a timestamp is also a very common method for simple encryption.

5. And because sessionID itself has a validity period, even if it is lost, it may expire quickly, and the loss may not be so great, but if the user name and password are lost, it will be big.

6. So the summary is:

Then, what are the benefits of using sessionID

1. It is convenient to query the user's corresponding session directly according to ID.

two。 The amount of computation is small when encrypting.

3. Security will not be reduced, or even higher.

OK, by independently solving the problems caused by the pure http mechanism, we explore the nature of the cookie and session mechanisms. And think: [using the http protocol, the state of the client will not be saved in the server] is solved by adding cookie and session mechanisms, does it mean that this [state] is very closely related to cookie and session?

So this statelessness refers to [no cache has been set up for this session to record the status of this session. The cache area includes the server side and the client side] but it still doesn't seem to have a key point (mainly because it doesn't match or even correspond to the previous official statements about state).

Search the official account of Java bosom friend, reply to "back-end interview" and send you a treasure book of Java interview questions.

Suddenly a question occurred to me: what does a stateful http look like?

1. It is difficult to directly imagine what a stateful http looks like, because the mechanism of http is naturally stateless.

two。 By analogy, another natural stateful mechanism is called TCP.

If stateful means that each request is connected, then the stateful TCP looks like: if a piece of data is sent in three TCP packets, the packet will indicate which packet this is, and what is the connection between this package and those packets?

3. But it seems that this stateful TCP has nothing to do with the stateful HTTP we want, because even if each http request is related to each other, it will not solve the http stateless problem mentioned above.

4. Wait, wait. it seems to be an analogy:

4.1. If each http connection has a signature, then after the first login is successful, the server knows that the signature is allowed to log in, and then all http connections with the same signature can log in. Here, the relationship between the host and the http connection sent by the same user is used. Here, a problem of maintaining login status is solved.

4.2. Similarly, try to use this [each http request is connected to each other] to solve the above problem [every operation has to interact with the underlying database of the system], but it really can't go on after thinking about it for a long time. Previous issue: a summary of 100 interview questions

4.3. However, I had an idea, and from another point of view, I seemed to have solved the problem:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Only the condition of "each http request is related to each other" cannot be solved. [every operation has to interact with the underlying database of the system]

Because obviously, in order to solve the problem that every operation has to interact with the underlying database of the system, it is necessary to open up a cache area on the server side.

But if you think about how to implement [each http request is connected to each other], you will find that it also needs to open up a cache on the server side.

So [opening a cache on the server side] is the real condition, that is, it is really equivalent to [stateful].

And I also found that the condition of [opening a cache on the server side] corresponds to the previous official statement of state, that is:

By opening a cache on the server side to store, remember, and share some temporary data, you can:

The protocol has the ability to remember transactions [transaction processing] [memory]

Context for the same url request [context]

Each request is not independent, and its execution and result are directly related to the previous request and the subsequent request.

Save the state of the client in the server

6. So, this state, coupled with the fact that the client also has cookie, refers to the data generated by the client and the server in a temporary session! And as I said earlier, how important it is to use a cache to save data in a temporary session

So the state includes not only the relationship between different URL accesses, but also data records for other URL accesses, and some other things, so more specifically, the state should be the temporary data of the customer in the cache space behind which these things are implemented.

Cookie and session should fully implement the stateful function.

A common misunderstanding of status:

When explaining the statelessness of HTTP, some people regard it as opposed to having a connection, saying that there are two ways, that is, if you want to be stateless, you must have a connection, but it is not.

Connected and disconnected, and then Keep-Alive refers to TCP connections.

Stateful and stateless can refer to TCP or HTTP.

TCP has always been stateful, HTTP has been stateless, but in order to be stateful, applications have added cookie and session mechanisms to HTTP, so that applications that use http can also be stateful, but http is still stateless.

At first, TCP had a connection, then TCP had no connection, and later, now TCP is Keep-Alive, which is a bit like having a connection.

At this point, the study of "what does the" state "in the stateless http protocol mean is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.