WebSocket Tutorial (a) very interesting understanding of websocket

One, WebSocket and HTTP

Transferred from: https://www.cnblogs.com/tohxyblog/p/7112917.html

WebSocket is the HTML5 (protocol), that is, the HTTP protocol does not change, or it does not matter, but HTTP is not support for persistent connection (long connection, not counting the loop connection)

First of all, HTTP has, 1.1 and 1.0 it is called keep-alive , to merge multiple HTTP requests into one, but in Websocket fact a new protocol, with the HTTP protocol basically does not matter, just to be compatible with the existing browser handshake specification, In other words, it is a supplement to the HTTP protocol that can be understood by such a graph.

There are intersections, but not all.

Another HTML5 refers to a series of new APIs, or new specifications, and new technologies. The HTTP protocol itself is only 1.0 and 1.1, and is not directly related to HTML itself. In layman's terms, you can transfer non-HTML data using the HTTP protocol. =

In simple terms, the hierarchy is different.

Second, WebSocket is what kind of agreement, concrete have what merit

First, WebSocket is a persistent protocol, relative to HTTP, a non-persistent protocol. Let's take a simple example and explain it in the PHP life cycle, which is widely used today.

The lifetime of the HTTP is defined by one, and Request Request in this case the Response HTTP1.0 HTTP request ends.

Improvements have been made in HTTP1.1, which makes it possible to have a keep-alive, which means that in an HTTP connection, multiple request messages can be sent to receive multiple response. But keep Request = Response in mind that this is always the case in HTTP, which means that a request can have only one response. And this response is also passive, can not initiate.

Coach, what do you have to do with websocket when you have so much BB? _ (: З"∠) _ Well, I'm just going to say websocket.

First, the WebSocket is based on the HTTP protocol, or the Protocol that borrowed HTTP to complete a part of the handshake.

First we look at a typical Websocket handshake (borrowed from Wikipedia. ）

Get/chat Http/1.1host:server.example.comupgrade:websocketconnection:upgradesec-websocket-key: X3jjhmbdl1ezlkh9gbhxdw==sec-websocket-protocol:chat, superchatsec-websocket-version:13origin:http://example.com

Familiar with the HTTP children's shoes may have found, this is similar to the HTTP protocol handshake request, a few more things. I'll explain the effect by the way.

Upgrade:websocketConnection:Upgrade

This is the core of WebSocket, tell Apache , and Nginx so on server: notice, I initiated is the WebSocket agreement, quickly help me find the corresponding assistant processing ~ Not that old-fashioned HTTP.

Sec-websocket-key:x3jjhmbdl1ezlkh9gbhxdw==sec-websocket-protocol:chat, Superchatsec-websocket-version:13

First of all, Sec-WebSocket-Key is a Base64 encode value, this is the browser randomly generated, tell the server: Peat, do not confuse the nest, I want to verify that Nikki is not really websocket assistant.

Then, Sec_WebSocket-Protocol a user-defined string is used to distinguish between the protocols that are required for different services under the same URL. Easy to understand: Tonight I have to service A, do not mistake

Finally, to Sec-WebSocket-Version tell the server to use the Websocket Draft (Protocol version), at the initial time, the WebSocket protocol is still in the Draft stage, all kinds of bizarre protocols have, and there are many strange things in the period, What Firefox and Chrome use is not a version of the same, the original WebSocket protocol too much is a big problem. But now it is OK, has been set up ~ everyone uses a thing ~ dehydration: Waiter, I want to be 13 years old Oh →_→

Then the server will return the following things, indicating that the request has been accepted, the successful establishment of WebSocket!

http/1.1 101 Switching protocolsupgrade:websocketconnection:upgradesec-websocket-accept: Hsmrc0smlyukagmm5oppg2hagwk=sec-websocket-protocol:chat

Here at the beginning is the HTTP last responsible area, tell the customer, I have successfully switched the protocol ~

Upgrade:websocketConnection:Upgrade

is still fixed, telling the client that the protocol is about to be upgraded Websocket , not mozillasocket,lurnarsocket or shitsocket.

Then, Sec-WebSocket-Accept this is confirmed by the server, and after the encryption Sec-WebSocket-Key . Server: OK, OK, I'll show you my ID card to prove it.

Later, the Sec-WebSocket-Protocol protocol that represents the end-use.

Now that HTTP has done all of its work, the next step is to follow the WebSocket protocol completely. The specific agreement is not elaborated here.

—————— Technical Analysis section is complete ——————

You've been so damn websocket for so long, what the hell are you going to do with that, http long poll or ajax轮询 not all of them can deliver real-time information?

Well, young man, let's talk about WebSocket. Here to get you some Hu (Sue) luo (dan) bu (red)

Third, the role of WebSocket

Before I speak WebSocket, I go with long poll ajax轮询 the principle of speaking and.

Ajax polling

The principle of Ajax polling is very simple, allowing the browser to send a request every few seconds, asking the server if there is any new information.

Scene Reproduction:

Client: La LA, no new information (Request)

Service side: No (Response)

Client: La LA, no new information (Request)

Service side: No. (Response)

Client: La LA, no new information (Request)

Service side: Hello annoying ah, no AH. (Response)

Client: La LA, there are no new messages (Request)

Server: All right, all right, here you are. (Response)

Client: La LA, there are no new messages (Request)

Service side: ... Didn't.... Didn't... No (Response)--loop

Long poll

long pollIn fact, the principle is ajax轮询 similar, is the use of polling, but the blocking model is taken (always call, not received on the phone), that is, after the client initiates the connection, if there is no message, it has not returned response to the client. Until a message is returned, the client establishes a connection again and again after the return is completed.

Scene Reproduction:

Client: La La la, there is no new information, no words to wait for it to return to me (Request)

Service side: Amount. Wait till there's a message. Here you Go (Response)

Client: La La la, there is no new information, no words to wait for the return to Me (Request)-loop

From the above can be seen in fact, these two ways, are constantly establishing an HTTP connection, and then wait for server processing, can reflect the HTTP protocol another feature, passivity.

What is passive, in fact, the server can not actively contact the client, can only be initiated by the client.

Simply put, the server is a very lazy refrigerator (it is a stem) (not, not the initiative to initiate the connection), but the boss has orders, if there are customers, no matter how tired should be well received.

To finish this, let's talk about the above flaws (forgive me for so much nonsense Oaq)

It's easy to see from above, however, that both of these are very resource-intensive.

Ajax polling requires the server to have fast processing speed and resources. (speed) Long poll need to have very high concurrency, that is, the ability to host customers at the same time. (Venue size)

So ajax轮询 and long poll all of this could happen.

Client: La la la, do you have any new information?

Service side: The monthly line is busy, please try again later (503 Server unavailable)

Client:.... All right, cheer up, do you have any new information?

Service side: The monthly line is busy, please try again later (503 Server unavailable)

Client: Then the service side is busy dying: refrigerator, I want more refrigerators! More.. More.. (I was wrong.) This is the stem again. ）

Well, let's just say websocket.

From the above example, we can see that neither of these approaches is the best way and requires a lot of resources.

A need for faster speed, a need for more ' phone '. Both of these will lead to higher demand for ' phones '.

Oh yes, forget to say HTTP is still a stateful protocol.

Popular saying is that the server because every day to receive too many customers, is a forgetful ghost, you hang up the phone, he put your things all forgotten, put all your things lost. You'll have to tell the server again the second time.

So in this case, WebSocket appeared. He solves these problems with HTTP. First, the passivity, when the server completes the Protocol upgrade (Http->websocket), the service side can proactively push the message to the client. So the above scenario can be modified as follows.

Client: La LA, I want to set up the WebSocket protocol, required services: Chat,websocket protocol version: + (HTTP Request)

Server: OK, confirm, upgrade to WebSocket protocol (HTTP protocols switched)

Client: Please push it to me when you have information.

Server: OK, sometimes I will tell you.

Service side: Balabalabalabala

Service side: Balabalabalabala

Service side: ha haha haha ah haha haha

Service side: Laughing at me ha ha haha haha

It becomes so that only one HTTP request, you can do a steady stream of information transmission. (in programming, this design is called a callback, that is: you have the information to notify me again, and not my stupid every time to ask you)

Such a protocol solves the situation where there is a delay in synchronization and is very resource intensive. So why would he solve the problem of consuming resources on the server?

In fact, we use the program is to go through two layers of proxy, that is, HTTP protocol in Nginx and other servers, and then sent to the corresponding handler (PHP, etc.) to deal with. To put it simply, we have a very fast one 接线员（Nginx） and he is responsible for handing over the questions to the corresponding 客服（Handler） .

The operator itself is basically the speed is enough, but each time is stuck in customer service (Handler), the old customer service processing speed is too slow. , resulting in insufficient customer service. WebSocket solves such a problem, after the establishment, can directly with the operator to establish a persistent connection, there is information when customer service to find ways to inform the operator, and then the operator in the unified transfer to the customer.

This will solve the problem of customer service processing speed too slow.

At the same time, in the traditional way, to constantly build, close the HTTP protocol, because the HTTP is non-stateful, each time to re-transfer identity info (authentication information), to tell the server who you are.

Although the operator is very fast, but every time to listen to such a heap, the efficiency will be reduced, but also have to constantly transfer this information to customer service, not only waste customer service processing time, but also in the network transmission consumes excessive traffic/time.

But websocket only need an HTTP handshake, so that the entire communication process is established in a connection/state, also avoids the non-state of HTTP, the server will always know your information until you close the request, so that the operator to resolve the HTTP protocol repeatedly, Also view information for identity info.

At the same time by the customer unsolicited inquiry, the conversion to the server (push) has information when it is sent (of course, the client is still waiting to send the message over the active). ), when no information is given to the operator (Nginx), do not need to occupy their own slow speed of customer service (Handler)

——————–

As for how to use WebSocket on clients that do not support websocket. The answer is: no

WebSocket Tutorial (a) very interesting understanding of websocket