In the usual smart home scenario, we can easily take out the mobile phone from our pocket, open the APP application, and start the water heater at home with a few clicks, so that we can take a hot bath immediately after returning home from get off work.
Within a few tenths of a second of this click, the control message on the Internet is transmitted as follows.
â‘ The customer's mobile phone is connected to the cloud server to issue a control command for the water heater
â‘¡The cloud server forwards the control instructions to the smart home gateway at home to control the water heater switch
â‘¢The water heater responds to the control command and feeds the result back to the cloud server
â‘£The cloud server will feed back the result to the client APP, and the APP shows that the setting is successful
You may ask a question, why does the client APP not directly control the smart home gateway, but use the cloud server for transfer?
Answer: The smart home device is hidden behind the home router, and its ip address is not a public network address, so the user's mobile phone cannot access the smart home device. Similarly, the cloud server cannot access smart home devices.
Therefore, smart home devices need to actively initiate a connection to the cloud server and establish a connection. In this way, the customer APP can log in to the cloud at any time and control the smart home through the cloud.
We use the HTTP protocol commonly used in the internet world to implement interactive control between smart home gateways and cloud servers. The HTTP protocol is very simple. The client initiates a request and the server returns a response.
Please note that the server cannot initiate requests actively, because the HTTP protocol must be initiated by the client. Therefore, if you want to control a smart home device, the smart home device needs to continuously inquire to the server to check whether the cloud server issues a control command to it.
The device's constant requests to the server will cause the following problems:
1. Regardless of the device or the cloud server, the CPU is very busy and the device performance is degraded
2. Occupy bandwidth, especially the bandwidth resources of cloud servers are relatively expensive
Well, we now invite the WebSocket protocol to replace the implementation of the HTTP protocol. The request from the device and the server becomes the following dialog:
This is obviously more reasonable, so the WebSocket protocol has the following advantages:
1. Less control overhead. After the connection is established, the header of the data packet used for protocol control is relatively small, with only 2-10 bytes without expansion. Compared with the HTTP request with a complete header each time, the overhead is much smaller
2. Stronger real-time performance, and the protocol is duplex. Both the client and the server can initiate a request at any time.
Because of the advantages of WebSocket, it is currently widely used in the following areas:
1. Social chat, if WebSocket comes out earlier, the protocol for QQ and WeChat chat is probably it.
2. Barrage
3. Multi-player games
4. Collaborative editing, such as Google Docs, allows multiple people to edit the same document online at the same time
5. Stock fund quotes
6. Location-based applications
7. Smart home
It can be seen that WebSocket is used in scenarios that require real-time performance.
WebSocket vs HTTP
The following figure shows the WebSocket and HTTP protocol hierarchical model:
Why don't customers directly control the smart home gateway, but use the cloud server for transit?
As can be seen from the figure, HTTP and WebSocket have some intersections, which we show through the following typical WebSocket handshake request:
Client request
GET/webfin/websocket/ HTTP/1.1Host: localhostUpgrade: websocket
Connection:UpgradeSec-WebSocket-Key: xqBt3ImNzJbYqRINxEFlkg==Origin: http://server address Sec-WebSocket-Version: 13
Server response
HTTP/1.1101 Switching ProtocolsUpgrade: websocketConnecTIon: UpgradeSec-WebSocket-Accept: K7DJLdLooIwIG/MOpvWFB3y3FE8=
It can be seen that the WebSocket connection establishment uses the HTTP protocol for handshake. After the handshake is completed, WebSocket has nothing to do with HTTP. The real data transmission phase does not require the participation of the HTTP protocol.
WebSocket and HTTP are independent protocols, so why does the WebSocket protocol borrow the HTTP protocol to establish a connection instead of building a set of independent protocols?
In the past few years, in most companies, IT blocked the QQ port number on the company's firewall in order to make everyone work at ease. This solved the problem that everyone can go online normally but cannot chat online. If QQ uses WebSocket instead, and WebSocket uses the same port 80 as HTTP, IT will not be able to restrict it unless Web browsing is also prohibited. Therefore, the WebSocket protocol borrows the HTTP protocol to establish a connection, and using the HTTP port number can bypass most firewall restrictions. Where there is a Web, WebSocket can pass unimpeded.
Browser compatibility
Since the WebSocket protocol was finalized in 2011, some older browsers still cannot support WebSocket, such as versions before IE10. The following is a browser that implements WebSocket (the final version RFC6455):
The Web world is changing with each passing day, but IE's support for new technologies is always slower, so now the share of IE is also declining year by year. According to statistics from Net Market Share in July 2016, Google's Chrome browser (48.65%) has surpassed the market share of IE (31.65%). Here is a reminder, friends who are still using the old version of IE, hurry up and upgrade.
Before WebSocket
You may have questions. WebSocket was only finalized in 2011, so how to implement real-time applications like chat rooms before? The answer is: use tcp programming. Therefore, for chat programs like QQ, Tencent needs to develop its own private SDK to implement it. If you develop a QQ chat program today, just use WebSocket directly. Browsers, client programs, server programs, and various programming languages ​​have developed ready-made WebSocket library functions that can be called directly. The underlying communication protocol and implementation details need not be considered.
The programming of HTTP and WebSocket corresponds to the seventh layer of the OSI seven-layer protocol, and the tcp programming is in the third layer. From a programming perspective, the higher the level, the simpler the coding. The principle is similar, programmers use C language to program or python programming. Python write a few sentences, c may need to write a few pages of programs.
Summary : Before web development, there was no agreement to maintain a long link. The birth of WebSocket made it from scratch, full-duplex, real-time, and high-efficiency. WebSocket caters to the needs of real-time communication.
Medical Product Machinery
Direct pressure type joint mold structure, fast clamping, slow, low pressure clamping action device, can ensure mold safety, fast speed, and increase output.
The hydraulic injection structure is special, the pressure tracking compensation device is built-in, the injection rate is fast, the injection pressure quality is stable, and the secondary injection pressure holding design makes the product high-quality and high-precision.
