1

The good old days

I often miss the good old days 30 years ago when work was easy and life was easy.

When I was at work, some HTTP requests were sent to me occasionally. I simply looked at them, took out the corresponding HTML documents and pictures, and sent them back. Then I could continue chatting over tea.

My creators have been kind to me, and one of their simple HTTP protocols is request plus response, especially since I don’t have to remember who just sent an HTTP request, every request is new to me!

The mail server admired me and said, “My brother, your life is so comfortable. Unlike me, every time someone accesses my mailbox from the client, I have to set up a special session for him to handle his messages, but you don’t need to manage the session at all.

Depending on the nature of the application, if the mail server does not manage sessions, mail messages between multiple people will be completely jumbled up.

Thirty years ago, the Web was basically browsing documents. Since it was browsing, why should I, as a server, remember who was browsing what documents at any given time?

2

Session

But the good times didn’t last long. Soon people were not satisfied with static Html documents, and interactive Web applications began to emerge, especially for forums and online shopping sites.

I immediately ran into the same problems as the mail server, which was having to manage sessions and keep track of who logged in and who put items in their shopping carts, which meant I had to separate everyone.

This was quite a challenge for me, and due to the stateless nature of the HTTP protocol, I had to do some tricks to get the session management done.

The solution I came up with was to send people a session ID, which is basically a random string that each person receives differently, along with each HTTP request they make to me, so I can tell who is who.

3

A heavy burden

Everyone’s happy, but I’m not.

Everyone only needs to save their session ID, and I need to save everyone’s session ID! If I get a lot of visitors, it’s thousands, even hundreds of thousands.

This is A huge cost for me and severely limits my ability to expand. For example, I use two machines to form A cluster, and little F logs in to the system through machine A, so the session ID will be saved on machine A. What if the next request of little F is forwarded to machine B? Machine B does not have the session ID of little F.

Sometimes I use A sticky session, which means that F’s requests stick to machine A all the time, but it doesn’t work either. If machine A dies, it will have to transfer to machine B.

So I’m going to have to copy sessions, move session ids between the two machines, and I’m going to get tired.

Then a guy named Memcached gave me a tip: Storing session ids centrally in one place, where all machines can access the data, eliminates the need for replication, but increases the possibility of a single point of failure. If the session machine dies, everyone has to log in again, probably cursed to death.

I also tried to cluster this single point machine to increase reliability, but the small session was a heavy burden for me anyway.

4

Time for space

These days I have been thinking in the evening, why should I save this horrible session, only let each client save it?

However, if I do not save these session ids, how can I verify that the session ID sent to me by the client is actually generated by me? If I don’t verify it, I don’t even know if they’re legitimate logins, and malicious guys can fake session ids and do whatever they want.

Well, the key is validation!

For example, if F has logged in to the system, I issue him a token, which contains F’s user ID. Next time F requests to access me through Http, he just needs to bring this token through Http header.

But it’s not that different from the session ID, because anyone can forge it, so I have to do something to make it impossible.

Then make a signature for the data. For example, I use HMAC-SHA256 algorithm, add a key that only I know, make a signature for the data, and use the signature and the data as a token. Since the key is unknown to others, it is impossible to forge the token.

I will not save this token. When F sends this token to me, I will use the same HMAC-SHA256 algorithm and the same key to calculate the signature of the data again and compare it with the signature in the token. If they are the same, I will know that F has logged in. In addition, the user ID of small F can be directly obtained. If it is different, the data part must have been tampered with. I will tell the sender: Sorry, there is no authentication.

The data in the Token is in clear text (although I do Base64 encoding, it’s not encrypted) and can still be seen by others, so I can’t store sensitive information like passwords in it.

Of course, if a person’s token is stolen by others, I can’t help it. I will also think that the thief is a legitimate user, which is actually the same as a person’s session ID is stolen by others.

In this way, INSTEAD of saving the session ID, I just generated the token and verified the token, and I used my CPU computing time to get my session storage space!

Relieved of the burden of session ids, my cluster of machines can now easily scale horizontally, increasing user visits and simply adding machines. This feeling of statelessness is so good!

(after)

What you’ve seen is just the tip of the iceberg. For more exciting articles, see “Code farmers turn over the article essence”.

Any tips you’d like to share? Welcome to contribute! My contact information: Wechat: Liuxinlehan QQ: 3340792577

Public number: code farmer turn over

The account was created by a former IBM architect who worked for 15 years to share lessons learned in programming and the workplace.



The editors recommend

Digg is a high quality technology community, from mobile development to architecture, programming languages to open source libraries, so that you don’t miss every technical dry matter of Internet development. Long press the picture qr code to identify or search for “gold digging” in the major application market, the technology is in your grasp.

Did this article help you? Welcome to join the wechat group of back-end learning Group: