Shulou(Shulou.com)06/02 Report--

Editor to share with you what are the differences between websocket and socket, I believe that most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

Difference: Socket is the API of TCP/IP network, a layer abstracted to facilitate the use of TCP or UDP, and a set of interfaces between the application layer and the transmission control layer, while WebSocket is a typical application layer protocol.

Introduction and principle of WebSocket

WebSocket protocol is a new protocol of HTML5. It implements full-duplex communication (full-duplex) between browser and server. The initial handshake needs to be done with a HTTP request.

Objective: instant messaging to replace polling

Instant messaging on the website is very common, such as web QQ, chat system and so on. According to the previous technical capability, it is usually solved by polling and Comet technology.

HTTP protocol is a non-persistent, one-way network protocol. After establishing a connection, the browser is only allowed to send a request to the server before the server can return the corresponding data. When instant messaging is needed, the browser sends a Request request to the server by polling at a specific time interval, such as 1 second, and then returns the latest data to the browser. The most obvious disadvantage of this method is that it needs to send requests constantly, and the Header of HTTP request is usually very long, which costs a lot of money to transmit a very small amount of data, which is very uneconomical and takes up a lot of broadband.

Disadvantages: it will lead to too many unnecessary requests, waste traffic and server resources, and waste a certain amount of traffic on the same header information for each request and reply.

However, the emergence of WebSocket can make up for this shortcoming. In WebSocket, only the server and browser need to shake hands through HTTP protocol, and then establish a separate communication channel of TCP for data transmission.

Principle

WebSocket is also an application layer protocol like HTTP, but it is a two-way communication protocol based on TCP.

Connection process-handshake process

1. Browser and server establish TCP connection and three-way handshake. This is the basis of communication, the transmission control layer, if it fails, it will not be executed later.

2. After the TCP connection is successful, the browser transmits information such as the version number supported by WebSocket to the server through the HTTP protocol. (HTTP handshake before start)

3. After receiving the handshake request from the client, the server also uses HTTP protocol to give back the data.

4. When the message of successful connection is received, the transmission communication is carried out through the TCP channel.

The similarities of the relationship between WebSocket and HTTP

1. They are all based on TCP, and they are all reliable transport protocols.

two。 They are all application layer protocols.

Differences

1. WebSocket is a two-way communication protocol that simulates Socket protocol and can send or receive messages in both directions. The HTTP is unidirectional.

2. WebSocket needs to shake hands to establish a connection.

contact

When WebSocket establishes a handshake, the data is transmitted through HTTP. But after it is established, the HTTP protocol is not needed for real transmission.

The relationship between WebSocket and Socket

Socket is not really a protocol, but a layer abstracted to facilitate the use of TCP or UDP. It is a set of interfaces between the application layer and the transport control layer.

Socket is the middle software abstraction layer for the communication between the application layer and the TCP/IP protocol family, and it is a group of interfaces. In the design pattern, Socket is actually a facade pattern, which hides the complex TCP/IP protocol family behind the Socket interface. For users, a simple set of interfaces is all, allowing Socket to organize the data to comply with the specified protocol.

When two hosts communicate, they must connect through Socket, and Socket uses TCP/IP protocol to establish TCP connection. The TCP connection depends more on the underlying IP protocol, while the connection of the IP protocol depends on lower levels such as the link layer.

WebSocket is a typical application layer protocol.

Difference

Socket is the transport control layer protocol and WebSocket is the application layer protocol.

The relationship between HTML5 and WebSocket

WebSocket API is part of the HTML5 standard, but that doesn't mean WebSocket has to be used in HTML, or only in browser-based applications.

In fact, many languages, frameworks, and servers provide WebSocket support, such as:

* C-based libwebsocket.org

* Socket.io based on Node.js

* ws4py based on Python

* WebSocket++ based on C++

* Apache's support for WebSocket: Apache Module mod_proxy_wstunnel

* Nginx supports WebSockets: NGINX as a WebSockets Proxy, NGINX Announces Support for WebSocket Protocol, WebSocket proxying

* lighttpd's support for WebSocket: mod_websocket

WebSocket mechanism

The following is a brief introduction to the principle and operation mechanism of WebSocket.

WebSocket is a new protocol of HTML5. It realizes full-duplex communication between browser and server, which can better save server resources and bandwidth and achieve real-time communication. It is based on TCP and transmits data through TCP like HTTP, but the biggest difference between it and HTTP is:

WebSocket is a two-way communication protocol. After establishing a connection, both WebSocket server and Browser/Client Agent can actively send or receive data to each other, just like Socket.

WebSocket requires TCP-like clients and servers to shake hands before they can communicate with each other.

The interaction between the traditional HTTP client and the server in non-WebSocket mode is shown in the following figure:

Figure 1. Traditional HTTP request response client-server interaction diagram

The interaction between the client and the server using WebSocket mode is shown below:

Figure 2.WebSocket request response client server interaction diagram

As can be seen from the comparison of the above figure, compared with the traditional HTTP mode that requires the client to establish a connection with the server for each request-reply, WebSocket is a communication mode similar to Socket's TCP persistent connection. Once the WebSocket connection is established, the subsequent data is transmitted in the form of frame sequence. Before the client disconnects the WebSocket connection or the Server disconnects, the client and server do not need to re-initiate the connection request. In the case of massive concurrency and large interactive load between the client and the server, it greatly saves the consumption of network bandwidth resources and has obvious performance advantages, and the client sends and receives messages on the same persistent connection. The real-time advantage is obvious.

Let's take a look at the difference between WebSocket communication and traditional HTTP through the message of interaction between client and server:

On the client side, new WebSocket instantiates a new WebSocket client object, and connecting the server WebSocket URL,WebSocket client object similar to ws://yourdomain:port/path automatically parses and recognizes the WebSocket request, thus connecting the server port and performing the handshake process. The client sends data in a similar format:

List 1.WebSocket client connection message

GET / webfin/websocket/ HTTP/1.1Host: localhostUpgrade: websocketConnection: UpgradeSec-WebSocket-Key: xqBt3ImNzJbYqRINxEFlkg==Origin: http://localhost:8080Sec-WebSocket-Version: 13 http://localhost:8080Sec-WebSocket-Version: 13

You can see that the WebSocket connection message initiated by the client is similar to the traditional HTTP message. The "Upgrade:websocket" parameter value indicates that this is a WebSocket type request. "Sec-WebSocket-Key" is a base64-encoded ciphertext sent by the WebSocket client, which requires that the server must return a corresponding encrypted "Sec-WebSocket-Accept" reply, otherwise the client will throw a "Error during WebSocket handshake" error and close the connection.

The format of the data returned by the server after receiving the message is similar:

List 2.WebSocket server response message

HTTP/1.1 101MOpvWFB3y3FE8 = HTTP/1.1 101MOpvWFB3y3FE8 =

The value of "Sec-WebSocket-Accept" is calculated by the server using the same key as the client and returned to the client. "HTTP/1.1 10101server" means that the server accepts the client connection of the WebSocket protocol. After such request-response processing, the WebSocket connection of the client server shakes hands successfully, and then the TCP communication can be carried out.

In terms of development, WebSocket API is also very simple, we just need to instantiate WebSocket, create a connection, and then the server and client can send and respond messages to each other. In the following WebSocket implementation and case analysis section, you can see the detailed WebSocket API and code implementation.

WebSocket implementation

As mentioned above, the implementation of WebSocket is divided into two parts: the client and the server. The client (usually the browser) sends out a WebSocket connection request, and the server responds to achieve an action similar to the TCP handshake, thus forming a HTTP persistent connection fast channel between the browser client and the WebSocket server. The subsequent direct data transmission between the two is no longer necessary to initiate the connection and the corresponding.

The following is a brief description of WebSocket server API and client API.

WebSocket server API

WebSocket server has been basically supported by API in accordance with the JEE JSR356 standard specification among all major application server manufacturers. The following is a list of some common commercial and open source application servers' support for WebSocket Server:

Table 1.WebSocket server support

Manufacturer's application server notes IBMWebSphereWebSphere 8.0 + support, previous version 7.x combined with MQTT support similar HTTP persistent connection Oracle WebLogicWebLogic 12c support, 11g and 10g versions support similar HTTP persistent connection Microsoft IISIIS 7.0 + support ApacheTomcatTomcat 7.0.5 + support, 7.0.2X and 7.0.3X support through custom API support

JettyJetty 7.0 + support

Here we use the Tomcat7.0.5 version of the server-side sample code to illustrate the WebSocket server-side implementation:

JSR356's WebSocket specification uses javax.websocket.* 's API, and you can use the @ ServerEndpoint annotation for a normal Java object (POJO) as the endpoint of the WebSocket server. The code example is as follows:

Listing the 3.WebSocket server API example

@ ServerEndpoint ("/ echo") public class EchoEndpoint {@ OnOpen public void onOpen (Session session) throws IOException {/ / the following code is omitted.} @ OnMessage public String onMessage (String message) {/ / the following code is omitted.} @ Message (maxMessageSize=6) public void receiveMessage (String s) {/ / the following code is omitted.} @ OnError public void onError (Throwable t) {/ / the following code is omitted.} @ OnClose public void onClose (Session session CloseReason reason) {/ / the following code is omitted.}}

Code interpretation:

The concise code above establishes a WebSocket server. The annotation annotation endpoint of @ ServerEndpoint ("/ echo") means that the WebSocket server is run on the ws:// [Server IP or domain name]: [Server port] / websockets/echo access endpoint, and the client browser can initiate a HTTP persistent connection to the WebSocket client API.

Classes that use ServerEndpoint annotations must have a public no-argument constructor, and the @ onMessage annotated Java method is used to receive incoming WebSocket information, either in text format or in binary format.

OnOpen is called when a new connection is established for this endpoint. Parameters provide more details on the other end of the connection. Session indicates that two WebSocket endpoints talk to the other end of the connection, which can be understood as a concept similar to HTTPSession.

OnClose is called when the connection is terminated. The parameter closeReason encapsulates more details, such as why a WebSocket connection is closed.

For more advanced customizations such as @ Message annotations, the MaxMessageSize attribute can be used to define the maximum message byte limit. In the sample program, if more than 6 bytes of information is received, an error is reported and the connection is closed.

Note: in the early days, different application servers supported different ways of WebSocket. Even from the same vendor, there were slight differences among different versions. For example, versions of Tomcat servers above 7.0.5 are implemented by standard JSR356 specifications, while versions of 7.0.2x/7.0.3X use custom API (WebSocketServlet and StreamInbound, the former is a container to initialize the WebSocket environment). The latter is used to specifically handle WebSocket requests and responses, as detailed in the case study section), and Tomcat7.0.3x is different from the definition of the createWebSocketInbound method of 7.0.2x by adding a HttpServletRequest parameter so that more information about the WebSocket client can be obtained from the request parameter, as shown in the following code:

Listing 4.Tomcat7.0.3X version WebSocket API

Public class EchoServlet extends WebSocketServlet {@ Overrideprotected StreamInbound createWebSocketInbound (String subProtocol,HttpServletRequest request) {/ / the following code is omitted. Return new MessageInbound () {/ / the following code is omitted.} protected void onBinaryMessage (ByteBuffer buffer) throws IOException {/ / the following code is omitted.} protected void onTextMessage (CharBuffer buffer) throws IOException {getWsOutbound (). WriteTextMessage (buffer); / / the following code is omitted.}};}}

Therefore, to select the Server end focus of WebSocket, you need to choose its version. In general, the newer version of WebSocket supports the standard JSR specification API, but you should also consider the ease of development and portability of the old version of the program. As in the customer case described below, the WebSocketServlet implementation of version 7.0.3X of Tomcat is used because the customer requires a unified application server version, rather than the @ ServerEndpoint annotation endpoint of JSR356.

WebSocket client API

For WebSocket clients, mainstream browsers (including PC and mobile terminals) now support standard HTML5 WebSocket API, which means that client-side WebSocket JavaScirpt scripts have good consistency and cross-platform features. The following is a list of common browser vendors' support for WebSocket:

Table 2.WebSocket client support

Browser support ChromeChrome version 4 + support FirefoxFirefox version 5 + support IEIE version 10 + support SafariIOS 5 + support Android BrowerAndroid 4.5 + support

Client-side WebSocket API has basically been unified among all major browser vendors, so you can use the JavaScript API of the WebSocket client defined by the standard HTML5, or you can use the industry's open source framework that meets the WebSocket standard specification, such as Socket.io.

The following is a code example to illustrate the client implementation of WebSocket:

Listing the 5.WebSocket client API example

Var ws = new WebSocket ("ws://echo.websocket.org"); ws.onopen = function () {ws.send ("Test!");}; ws.onmessage = function (evt) {console.log (evt.data); ws.close ();}; ws.onclose = function (evt) {console.log ("WebSocketClosed!");}; ws.onerror = function (evt) {console.log ("WebSocketError!");}

The first line of code is applying for a WebSocket object, and the parameter is the address of the server to which you need to connect. Like the beginning of the HTTP protocol, the URL of the WebSocket protocol starts with ws://, and the secure WebSocket protocol starts with wss://.

The second line to the fifth behavior WebSocket object registers the message handler. The WebSocket object supports a total of four messages: onopen, onmessage, onclose and onerror. With these four events, we can easily and easily control WebSocket.

When the connection between Browser and WebSocketServer is successful, the onopen message will be triggered; if the connection fails, the browser will trigger the onerror message; when the Browser receives the data sent by WebSocketServer, it will trigger the onmessage message, and the parameter evt contains the data transmitted by the Server; when the Browser receives the request to close the connection sent by the WebSocketServer, it will trigger the onclose message. We can see that all operations are triggered by asynchronous callbacks, so that UI is not blocked, resulting in faster response time and a better user experience.

These are all the contents of this article entitled "what are the differences between websocket and socket". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.