Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "how to understand Cookie, Session, Token". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Text

In 1990.

Tim Berners-Lee created the HTTP protocol.

Li Lao's idea is to store the document in the server, who needs the document directly from the server can be obtained.

According to this idea, the only demand at that time was GET.

And according to the idea of taking the document: after taking the connection, it can be broken, and there is no need for any interaction.

So HTTP was originally designed to be stateless.

That is, there is no correlation between request and request.

With the development of the Internet, interaction began to rise.

People are no longer satisfied with simple static file access, and all kinds of shopping and socializing follow.

This means that the server needs to determine who is the initiator of each request, that is, the required status.

You have to show who you are when you talk, and who do you talk to? Otherwise, the server won't know who to send this chat message to.

When you shop, you have to let the server know who bought this thing, right?

You can't go offline after you buy it, and then go online and find that what you bought is gone.

At this point, a technology is needed to establish a connection between the request and the request, so that the request becomes stateful.

This technology is called Cookie, which is a small file stored in Key-Value format and saved locally on the client side.

For example, after logging in, the server can set Cookie to return to the browser and save it locally.

Casually cut off a Baidu, the list is key, the drop-down arrow opened inside there is value.

After that, the request to Baidu can take Cookie to visit the server. Here, it is assumed that BAIDUID is the user ID.

As soon as Baidu's server looked at the original ID, it was known that it was a "I" request, and it was in a state.

To put it simply, a Cookie is a file stored locally, and each request will bring Cookie to access the server.

So stuff some user information into the Cookie so that the server can tell which user made the request.

Note that Cookie is divided into domains. Take a look at this figure:

That is, each domain has its own Cookie, visit different sites with Cookie belonging to this site, will not bring other people's Cookie, otherwise it will be messed up.

But Cookie is stored locally in plaintext and with a large amount of user information, which is not very secure.

And it's not cost-effective to bring so much Cookie with each request.

Session solves this problem, and Session is conversation, and it has a broader meaning, and in scenarios like Cookie, we narrow it down.

Session is to store the user's session information on the server.

Then issue a sessionId to the client and let the client request later with sessionId.

In this way, the server can use sessionId to find the user's information and identify the request.

So how does the client bring sessionId?

The sessionId is still stored locally in the form of Cookie, and can be taken with you when the request is made.

But storing this state information in the server makes the server have a state.

Generally speaking, there are multiple servers deployed online to do load balancing and act as backup to each other.

So if the Session information is stored on one machine, the Session information will not be found when the next request is assigned to another machine by load.

Also do not recognize this request, the possible phenomenon is to tell the user did not log in, the user is not stupid.

I just logged in, so that tells me I'm not logged in?

So the way to deal with it is session replication, that is, the servers synchronize session with each other, so that no matter which server is requested, there is the user's information.

However, this replication is redundant and has additional overhead.

Another is session sticky, which is to stick your request to a server all the time. If your request is assigned to server An at the beginning, then all subsequent requests will only be assigned to server A.

But if server A dies, your request will still be assigned to another server, so the user's login information will still be lost.

You can see that both replication and sticky are flawed, so you can put session in third-party storage, such as Redis.

In this way, the server is out of state again.

The stateless server means that it can scale at will, and the service cluster can add or subtract several servers according to the traffic, which is very convenient.

But putting session on third-party storage just transfers the maintenance from the server to the third party.

The third party must ensure its high availability, otherwise the user's login information will be lost again.

But generally speaking, our system is supposed to maintain third-party storage, so it doesn't have much impact.

Summary: it is not safe to store Cookie plaintext locally, so you want to store the user status on the server, while Session stores the user status information on the server.

Expose the sessionId to the client, which is relatively safe and reduces network traffic.

But in this way, the server is in a state and is difficult to expand.

So you can put Session on third-party storage, but the state is still maintained by the server.

Token

In fact, if you think about it, is it not necessary to store the user's information on the server?

All you need is a credential that represents the identity, and a server issues the credential to the user, and the subsequent request allows the user to carry the credential.

Just like our ID cards, they represent us.

This credential contains the user's information, and some people may be afraid that the voucher will be forged.

It's all right. Sign the voucher so that our server can verify the authenticity of the credential.

Just like no one else can make a fake ID card.

This kind of certificate is called Token.

If a user logs in to the system, I return a Token to him, and then I ask him to bring the Token every time.

After the server verifies the authenticity, it gets the user information in the Token and knows who sent the request.

In this way, the server is stateless, it is really stateless, and of course the client is stateful.

It is most reasonable for the client to save the Token, and there is no need for redundant data on the server side.

With Token, the server is scalable because it is stateless, and Token can be used across applications.

Compared to calls between different applications in a company, all applications can log in as long as they can recognize this Token.

A Token is done. You don't have to log in to every website. This is single sign-on.

If it is easier for a third-party service provider to provide the service, you only need to issue a Token to the caller.

Token is simply a token containing credential information. As long as the server can recognize the token, it can respond accordingly according to the identity of the token.

In fact, this also contains the idea of time for space, expose the user information stored in the server, and use signatures to verify the authenticity of Token.

In this way, each request takes time to check, but the advantage is that there is no need to store information, that is, time for space.

This is the end of "how to understand Cookie, Session, Token". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.