1
Good old days
Thirty years ago I often miss the good old days, work is easy, life is very relaxed.
Some occasionally work when the HTTP request is sent to me, I simply look at out the corresponding html documents, pictures, send it back, then you can continue to drink tea and chat.
A simple HTTP protocol my Creator who is good to me, they developed, is added in response to a request, especially since I do not remember who had just made a HTTP request, each request is new to me!
Mail server envy me, he said: brother, your life is too comfortable, and which, like me, every time someone from the client to access the mailbox, I had to give him the establishment of a special session to deal with his outgoing messages, you touch , no need to manage the session.
This is determined by the characteristics of the application, if the mail server does not manage the session, that mail messages between more than one person will be completely mingled together, a tangle.
And 30 years ago, it is basically a Web browsing document only, since it is the view, I, as a server, why should remember who for some time have viewed what document it?
2
Session
But the good times did not last long, and soon we will not be satisfied with static Html files, and interactive Web applications began to rise, especially in forums, online shopping sites.
I immediately ran into the same problem and the mail server that must manage session and who log must remember, who in his own cart, put a commodity, which means I must separate area for everyone.
This is not a small challenge for me, due to the stateless nature of the HTTP protocol, I have to add some small tools to complete the session management.
I came up with the solution is for everyone to send a session identifier (session id), it means a random string that is different for each person received, each time you initiate to me when HTTP requests, this string come together to take along, so I can distinguish who is who.
3
heavy burden
We are very happy, but I was unhappy.
Each person only needs to keep the session id, but I need to save the session id for all! If I visit more people, you have to by the thousands, even hundreds of thousands.
This is for me a huge overhead, severely limited my ability to expand, for example, I use two machines form a cluster, small machine A through F logged into the system, and that session id will be saved on the machine A , under the assumption of a small F request is forwarded to the machine B how to do? Session id machine B may not small F ah.
Sometimes I will use a little trick: session sticky, it is to make a small request F has been sticking on the machine A, but this is not effective, and if the machine A hang, had to go to the machine B to go.
Then I had to make a copy of the session, the session id moved around between two machines quickly exhausted.
Later, a man named Memcached give me support the move: the session id stored centrally in one place, all the machines are used to access the data of this place, this way, you do not copy, but it increases the likelihood of a single point of failure if the session is responsible for the machine hung up, everyone had to log in again and again, it is estimated Masi people.
I also try to put this machine also come up with a single point cluster, increase reliability, but no matter what, this little session for me is a heavy burden.
4
Time for space
These days I have been thinking at night, why do I want to save this nasty session it, just let each client to preserve nice?
But if I do not save the session id, how do I verify the client's session id sent to me indeed is my generation do? If I do not verify, I do not know that they are a legitimate user is not logged on, those guys can forge malicious session id, do whatever they want.
Ah, yes, the key point is to verify!
For example, a small F has logged into the system, I sent him a token (token), which contains a proposed user id small F, the next time I visit small F again through Http request, when this token via Http header with not over it.
But this session id and there is no essential difference ah, anyone can be forged, so I have to do something about, so that others can not fake.
Then the data to make it a signature, for example, I algorithm HMAC-SHA256, a plus only I know the key, the data make a signature, the signature and the data together as a token, because the others do not know the key , the token can not be forged.
This token I do not save, when this small token to F me over when I use the same HMAC-SHA256 algorithm and the same key, the data re-calculated once the signature, and the signature token make a comparison, If so, I know that a small F has logged over, and can be taken directly to the user id small F, if not identical, the data portion certainly been tampered with, I'll tell the sender: Sorry, no certification.
Token data is stored in plain text (although I will do the next coding, but that is not encrypted), can still be seen by others, so I can not in which to save sensitive information such as passwords.
Of course, if a person's token is stolen someone else, then I have no idea, I would think the thief is a legitimate user, and this is actually a person's session id was stolen someone else is the same.
As a result, I will not save the session id, I just generate token, then verify that token, I use my CPU time to obtain my session storage space!
The lifting of the session id of this burden can be said that nothing out of danger, my machine clusters can now easily do horizontal scaling, user traffic increases, plus the machine directly on the line. This stateless feeling is wonderful!
(Finish)
Transfer: https: //blog.csdn.net/jek123456/article/details/64923545
