Accidentally in the know to see a reply, instantly feel like so many of the information before this one reply let me to websocket of deep understanding has wood. So go to my blog and share. Prefer to read this kind of blog, reading it is easy, not boring, no preacher of the battle, purely for sharing. So much nonsense, and finally praise a ~ a, websocket and Httpwebsocket is HTML5 out of the Things (protocol), that is, the HTTP protocol does not change, or that it is okay, but HTTP is not support persistent connection (long connection, not count of loops) first HTTP has 1.1 and 1.0 say, the so-called keep-alive, to merge multiple HTTP requests into one, but Websocket is actually a new protocol, and 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, 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 agreement, relative to HTTP such non-durable protocol. Let's take a simple example and explain it in the PHP life cycle, which is widely used today. The life cycle of HTTP is defined by the request, which is a request for a Response, and in HTTP1.0, the HTTP requests end. 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 remember that request = Response, which 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, let's 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, Nginx and other servers: note, I initiated 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, 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 a WebSocket assistant. Then, Sec_websocket-protocol is a user-defined string used to distinguish between the protocols required for different services under the same URL. Easy to understand: Tonight I have to service A, do not make a mistake ~ Finally, Sec-websocket-version is to tell the server to use the WebSocket Draft (protocol version), at the initial time, the WebSocket protocol is still in the Draft phase, All kinds of bizarre agreements have, and there are many strange different things, what Firefox and Chrome is not a version of the same, the original WebSocket agreement 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 to start is the HTTP last responsible area, tell the customer, I have successfully switched protocol ~upgrade:websocketconnection:upgrade is still fixed, tell the client is about to upgrade is Websocket protocol, not mozillasocket,lurnarsocket or shitsocket. Then, sec-websocket-accept this is the server confirmed, and encrypted after the Sec-websocket-key. Server: OK, OK, I'll show you my ID card to prove it. Later, Sec-websocket-protocol is the protocol that represents the final 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 Part is finished —————— you TMD and BBB for so long, that exactly websocket what ghost use, HTTP long poll, or Ajax polling can not be realized real-time information transfer. Well, young man, let's talk about WebSocket. I'm going to get you some Hu (su) luo (dan) bu (red) Three, the role of WebSocket before I speak WebSocket, I will take a long poll and Ajax polling principle. Ajax polling Ajax polling is very simple, allowing the browser to send a request every few seconds to ask the server for new information. Scene rendition: client: La La la, there is no new information (request) Server: No (Response) client: La La, there is no new information (request) server: No. (Response) client: La La la, there is no new information (Request) server: Hello annoying ah, no AH. (Response) client: La La la, there is no new message (Request) server: All right, here you are. (Response) client: La La la, there is no new message (Request) server: ... Didn't.... Didn't... No (Response)--Looplong Polllong poll In fact the principle of the same as Ajax polling, are the way to use polling, but to take a blocking model (always call, do not receive the phone), that is, after the client initiates the connection, if no message, 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 rendition: client: La La la, there is no new information,If you don't have one, you can return it to me. Service side: Amount. Wait till there's a message. Here you are. (Response) client: La La, there is no new information, no words to wait for it to return to me (Request)-loop from the above can be seen in fact, both of these methods are constantly establishing an HTTP connection, and then waiting for server processing, Can embody another feature of the HTTP protocol, 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) from the above is easy to see, no matter what, the above two 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. (site size) so Ajax polling and long poll are likely to 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. To get to the point, let's say websocket. With this 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 SwitchedClient: Please push it to me when you have information. Server: OK, sometimes I will tell you. Service side: Balabalabalabala Server: Balabalabalabala server: ha haha haha ah haha haha service end: Laughing dead i ha ha haha haha turned into this, only need to go through an 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 inform me, and not my stupid every time I ask you) such a protocol solves the above synchronization has a delay, but also very resource-consuming situation. 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. In short, we have a very fast operator (Nginx) who is responsible for handing over the problem to the appropriate customer service (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 continue to establish, close the HTTP protocol, because HTTP is non-stateful, each time to re-transmit 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 to how to use websocket on clients that do not support websocket. The answer is: no, but you can simulate a similar effect by saying long poll and Ajax polling.
Read to make you understand the WebSocket principle completely
