Stateless no connection for HTTP

Intro:Recently in a good understanding of HTTP, found that the first sentence of the introduction of HTTP "HTTP protocol is stateless, non-connected" can not understand: stateless "state" what exactly refers to?! Find a lot of information not only did not find sharply positive answer to this question, and some explanations are filled with a variety of errors, looking at the feel of the heart holding a cloud of gas can not spit out so after reading a lot of information, I spit out the turbid gas, loudly raised this question: HTTP protocol stateless State What does it mean?! Then began to explore and solve the problem ... Finally very happy is that I found a satisfactory answer, first sell a Xiaoguanzi, you can directly pull to the bottom to see text: What does the "state" in the stateless State of the HTTP protocol mean?! Let's look at the other two concepts of this sentence: (Standard HTTP protocol is stateless, no connection)

1. Standard HTTP protocol refers to not including cookies, session,application HTTP protocol, they are not a standard protocol, although a variety of web application providers, implementation of language, web containers, etc., are supported by default
2. What does a connection mean?
   1. Every access is no connection, the server handles access to the queue, and closes the connection after processing one, and then handles the next new
   2. The meaning of no connection is to limit the processing of only one request per connection. When the server finishes processing the customer's request and receives the customer's answer, the connection is disconnected

For "Stateless", I see a lot of vague words (officially or in the tutorial) that are separated by a layer of frosted glass, and it's hard to see (but it's right) (and then I found out why I thought it looked uncomfortable because they introduced a lot of new and obviously a generalized noun that might be used in many places, The biggest function of these words is to confuse concepts, as I noted below.

1. Protocol has no memory capacity for transactional processing "thing handling" "Memory ability"
2. There is no context relationship for the same URL request "context"
3. Each request is independent, its execution and results are not directly related to the previous request and subsequent requests, it will not be affected directly by the previous request response situation, and will not directly affect the subsequent request response situation "No direct contact" "directly affected"
4. The state of the client is not saved in the server, and the client must take its own state to request the server "state" each time

I must get a precise and specific explanation! These points give me the direction to think next:

1. "The state of the client is not saved in the server, and the client must take its own state to request the server each time." Is the state of the client here the exact point of the server not saving the customer's information? But apparently not.
2. "HTTP stateless features are a serious impediment to the implementation of these applications, after all, the interaction is necessary, the simple shopping cart program also need to know what the user chose before the product," I questioned why can not realize the shopping cart? Can't the server store anything?
3. "Each request is independent,< its execution and results > is not directly related to the < request > and < Subsequent requests >" I think this statement is more reliable, but the so-called different requests are not related, refers to the content of the request is not related, Or does it just mean that the request itself is not related?
   1. The request content is not related only may not have the user data on the server to be possible ah, but obviously is the existence.
   2. The request itself does not matter, what is the point, what is the value of each request?

In this direction I did a simulated access experiment: if there is no cookie without a session, only HTTP, then when a registered user visits this shopping site, these things happen:

2. Condition:
   1. The server certainly establishes a data table for each registered user, recording the user's data
   2. HTTP is non-connected
4. The first step requires login
   1. The user's user name and password are sent to the server via HTTP, and the server compares them to the user data they have, and if it is consistent, the return information is successfully logged in.
6. Then the user clicks on a product page
   1. This action is equivalent to entering the URL of a product page
   2. If the product page is more confidential, it needs to be accessible to the user.
   3. And although HTTP can send the user name and password, and just entered, but also verified the success, but because the server will not remember the status of your login, your client will not store the user name and password you just entered
   4. So because this visit is not able to determine your identity, you can only access the failed
      1. At this time if you want to solve this problem, and no cookie does not have a session, then you can only visit the URL and continue to bring your user name and password (continue to input) is actually like my current app
8. Suppose the problem of the previous step is solved, that is, every time you access the user name and password will be entered manually, and then the situation is: You have selected a few items in your shopping cart, you want to add another item, so you click on a product next to the plus
   1. This action is also equivalent to entering a URL, the content of the URL is to send a request to your shopping cart to add this product
   2. The system first uses your user name and password to verify your identity, and then access your database, in which the shopping cart attributes add a piece of data, is the product data
   3. After the operation is finished, the return operation succeeds and ends the access
10. OK, the end of the experiment, seemingly no cookie does not have a session can solve the problem, in fact, two operations have a lot of problems
    1. Every time you access the content needs to enter the user name and password on the client, this is not necessary to repeat the tedious
    2. Every operation you make is interacting with the database at the bottom of the system.
       1. Many times a small amount of access has a very large performance waste. It is very easy to think that it must be a large number of operations more efficient, so I think of the buffer
    3. Your non-trivial data is also written into the database and put together with your main data
       1. Adding and removing shopping carts over and over again is a matter of temporary data, unrelated to the user's primary information, and simply redundant data (which does not rule out the fact that some companies now feel that this kind of data also has a great value to use wisely), With what to store these temporary data, it's also easy to think of buffers

After this simulated access experiment, combined with the previous thinking direction, we know three points:

1. The server must have the user's data, you submit additions and deletions to change it can also handle, so this sentence in the "server does not save the state of the client" State does not refer to the user's data, our guess is wrong
2. Our question is, stateless can realize the shopping cart, can be implemented by the user data stored on the server
3. However, there are three big problems in using this way to implement the shopping cart. As a result, we can not help but wonder whether the resolution of these three questions is related to the term "state" that we do not know for certain? So, we're going to explore the meaning of "state" by solving these three problems.

As mentioned above, we can add some mechanism on the basis of HTTP to solve the above three problems

2. It is very necessary to add a notebook to the client, just as the official cookie mechanism is, as it is, it is used to identify the identity of the visitor.
4. Adding a buffer to the server can solve the latter two problems at the same time
   1. With this cache as a data buffer, there is no need to access the database again and again, wasting a lot of computer resources, but in the final unified into the database
   2. With this buffer, you don't have to put the temporary data into the database, just after you have finished the communication, and then organize the data, put the useful data into the database
5. It naturally comes up with an important concept: the session, which is separated from the database as a buffer store, is not stiff, it has its own important and irreplaceable role. This thing happens to be the same as the official joining session mechanism.
   2. In addition, a very confusing easy to let people on the main role of the session to deviate from the understanding: that the value of the session is to assign a SessionID to the visitor instead of the user name and password,
   4. Why it's so confusing, because the session does it, and it plays a big role, so it's right, but only half, and it's not about the nature of the problem, it's the most dangerous (seemingly persuasive, convincing, so it's hard to be motivated to keep looking, But the real situation and it is biased, but the deviation is not big, so it is difficult to persuade you back, only the faint of the wrong, this time you from the real nearest, also from the real farthest)
   6. then by the way it is right, that is, another useful thing to do with the session:
      1. give each session an ID, on the one hand to facilitate their own query, on the other hand this ID to the user, the next time the user can not use the user name and password, Instead, use this ID directly to indicate your identity
      2. First, is this ID secure? Is this ID more secure than direct user name and password?
         1. You can easily think of the original user name and password combination is also specifically set to more complex, you change a group of numbers instead of, is it too unsafe?
         2. We know that the HTTP protocol itself is completely unencrypted, if the user name and password, the first access is placed in the HTTP header, the back automatically save the password will be placed in the cookie, these are completely unencrypted, its security is basically 0, is the bare-Ben, as long as the stolen, Then you lose
         3. . So, in this sense, SessionID security is not the same as using a user name and password
         4. but in fact, although HTTP itself can not be encrypted, but some software, you can manually encrypt at the application level, For example, QQ will use the user name password plus temporary verification code combined hash, SessionID plus a timestamp simple encryption is also a very common method
         5. and because SessionID itself has an expiration date, even if lost, it may soon fail, resulting in loss may not be so large, and the user name and password lost, it is big
         6. so the summary is:
            1. is not strictly encrypted sessionid and user name and password are not too secure
            2. but compared to the SessionID to be safe Some
            3. and using HTTPS is completely secure
      3. Then, what are the benefits of using SessionID
         1. easily query users directly by ID The corresponding session
         2. is encrypted with a small amount of computation
         3. security does not degrade, even higher.

OK, we explore the nature of cookies and session mechanisms by independently addressing the problems that the pure HTTP mechanism can produce. and thought: "Using the HTTP protocol, the server does not save the state of the client" problem caused by the addition of cookies and the session mechanism to solve, does that mean that the "state" and the cookie and the session is very closely related? So this stateless refers to the "not set a buffer for this session, record the state of the session, the buffer includes the server side and the client" but it seems that there is no dissected key (mainly feel that the previous official state of the statement is not very consistent, even no correspondence) Suddenly I think of a question: what is a stateful http?

2. It's hard to directly imagine what a stateful HTTP is like, because HTTP is a natural, stateless mechanism.
4. So analogy, another natural state mechanism called TCP
   1. If there is a status of the meaning of its every request is connected, then the status of TCP looks like: If a copy of the data is divided into three TCP packets sent, then the package will indicate that this is the first few packets, will indicate this package with those packets are linked, there is any connection
6. But it's like this stateful TCP doesn't have anything to do with the stateful HTTP we want, because even if each HTTP request is connected to each other, it doesn't solve the HTTP stateless problem mentioned above.
7. Eh, wait, it seems to be an analogy:
   2. If each HTTP connection has a signature, so after the first successful login, the server will know that the signature is allowed to log in, and then all the same signed HTTP connection can be logged in, here to take advantage of the same user sent HTTP connection between the host relationship, This resolves a problem that keeps the login status
   4. In the same way, try to use this "each HTTP request is connected to each other" to solve the problem encountered above "every operation to the system at the bottom of the database to interact", but think for a long time really can't go on
   6. But I brainwave, from another point of view, seems to have solved this problem:
      1. Only "Each HTTP request is connected to each other" is a condition that cannot be resolved "every operation must interact with the underlying database of the system"
      2. Because it is clear that "every operation needs to interact with the database at the bottom of the system," you have to open a buffer on the server side.
      3. 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 a buffer on the server side
      4. So "creating a buffer on the server side" is the real condition, that is, it is actually equivalent to "stateful"
      5. And I also found this "create a buffer on the server side" of the conditions with the previous official state of the point corresponding to the points, that is:
         1. By opening a cache on the server side, storing, remembering, and sharing some temporary data, you can:
            1. The protocol has the memory ability of transaction processing "thing handling" "Memory ability"
            2. Context relationship for the same URL request "context"
            3. Each request is not independent, and its execution and results are directly related to the previous request and the subsequent request are "not independent" "Direct relationship"
            4. The state "state" of the client is saved in the server
      6. So, this state, plus the previously said client has a cookie, that is, the client and the server in the temporary session of the data generated ! And that's how important it is to use buffers to save data in a temporary session.
         1. So the state not only includes the relationship between the different URL accesses, but also the data records that are accessed by other URLs, and some other things, so more specifically, the state should be the temporary data of the customer in the cache space behind the implementation of these things.
         2. The cookie and session should be fully implemented with a stateful function

A common misconception about the state:

1. Some people explain the state of the HTTP stateless, it is connected to the opposite, said to be two ways, that is, if you want to have a state, there must be a connection, but it is not
2. There are connections and no connections, and subsequent keep-alive are referred to as TCP connections
3. Stateful and stateless can refer to TCP or HTTP
4. TCP has been stateful, HTTP has been stateless, but the application in order to have a state, the HTTP added a cookie and session mechanism, so that the use of HTTP applications can also have a state, but HTTP or stateless
5. Start TCP is there is a connection, then TCP is not connected, then later that is now TCP is keep-alive, a bit like having a connection

Stateless no connection for HTTP