[Web Design] Ajax, Comet and websocket--turn

from http The deal.

The 1996 IETF HTTP workgroup released the 1.0 version of the HTTP protocol, and the now widely used version of the 1.1,HTTP protocol has undergone more than 17 years of development. This distributed, stateless, TCP-based request/response, which is widely used today in the Internet's popularity, seems to be progressing slowly relative to the rapid development of the Internet. From the rise of the Internet to the present, experienced the web1.0 era of portal site prevalence, and then with the advent of Ajax technology, the development of Web applications prevailing in the web2.0 era, and now moving towards web3.0 direction. The inverse HTTP protocol, developed from version 1.0 to 1.1, is a perfunctory improvement in cache handling, bandwidth optimization, and security, in addition to the default long connection. It retains a stateless, request/response pattern and never seems to realize that this should change.

Ajax--- the script sends http Request

In order for a traditional Web application to interact with a server, a form must be submitted, the server receives and processes the form, and then returns a new page, since the data for the front and back two pages is mostly the same, and the process transmits a lot of redundant data and wastes bandwidth. So Ajax technology was born.

Ajax is the abbreviation for asynchronous JavaScript and, first presented by Jesse James Garrett. This technology pioneered the browser script (JS) to send HTTP requests. The Outlook Web Access group was used in 98 and soon became part of the IE4.0, but this technology has been very small, until early 2005, Google in his goole groups, Gmail and other interactive applications such as the widespread use of this technology, So that Ajax is quickly accepted by everyone.

The advent of Ajax makes the client and server data transfer less and much faster, but also to meet the rich user experience as the characteristics of the web2.0 era of the early development of the need, but slowly also exposed his shortcomings. For example, the need for real-time update data for rich interactive applications such as instant Messaging cannot be met. This small browser-side technology is still based on the HTTP protocol, the HTTP protocol requires the request/Response mode is also immutable, unless the HTTP protocol itself has changed.

Comet--- a hack Technology

The low latency requirements of data for Web applications represented by instant messaging, the traditional polling-based approach is not enough, and it also brings a bad user experience. So a "server push" technology based on a long HTTP connection is hack out. This technique was named Comet, which was first proposed by the project manager of Dojo Toolkit, Alex Russell, in the blog post Comet:low Latency Data for the browser, and continues.

In fact, the server push very early existence, in the classic Client/server model is widely used, but the browser is too lazy, and does not provide a good support for this technology. But the advent of Ajax made it possible to make this technology available on the browser, and the integration of Google's Gmail and Gtalk first used this technology. With some key issues (such as IE loading display problems), soon this technology has been recognized, there are many mature open-source comet framework.

The following is a typical comparison between Ajax and comet data transmission, the difference is straightforward. The typical Ajax communication method is also the classic use of the HTTP protocol, in order to obtain data, you must first send a request. In a Web application where low latency requires more high, only the frequency of server requests can be increased. Unlike comet, the client maintains a long connection to the server, and the server proactively pushes the data to the client only when the data that the client needs is updated.

There are two main ways to implement Comet:

1. Ajax-based long polling (long-polling) mode

Browser issue

2. The stream (HTTP streaming) mode based on Iframe and Htmlfile

The IFRAME is an HTML tag, and the src attribute of this tag keeps a long connection request to the specified server, and the server side can keep returning the data, which is closer to the traditional server push than the first way.

In the first way, the browser calls the JS callback function directly after receiving the data, but how does it respond to the data? You can embed a JS script in the return data, such as "<script type=" Text/javascript ">js_func (" Data from server ") </script>", The server side will return the data as the parameters of the callback function, the browser after receiving the data will execute the JS script.

However, there is a clear deficiency in this way: ie, Morzilla Firefox at the bottom of the progress bar will show that the load is not completed, and the icon above IE will not stop rotating, indicating that the load is in progress. Google's geniuses use an ActiveX called "htmlfile" to solve the load display problem in IE and apply this method to the Gmail+gtalk product.

Websocket--- Solutions for the future

If the advent of Ajax is the inevitable development of the Internet, then the advent of comet technology is more revealing a helpless, just as a hack technology, because there is no better solution. Who should solve the problem of comet resolution is reasonable? Browser, HTML standard, or HTTP standard? Who should be the protagonist? Essentially, this involves data transfer, the HTTP protocol should be the first, it is time to change the lazy protocol of the request/Response mode.

The answer is given in the new generation of HTML standard HTML5, which provides a network technology WebSocket for full-duplex communication between browsers and servers. From the WebSocket draft, WebSocket is a completely new, independent protocol, based on the TCP protocol, which is compatible with the HTTP protocol and does not fit into the HTTP protocol, just as part of the HTML5. The script is then given another ability: to initiate a websocket request. We should be familiar with this approach, because Ajax is doing it, and the difference is that Ajax initiates HTTP requests.

Unlike the HTTP protocol's different request/response modes, WebSocket has a handshake (Opening handshake) process before the connection is established, and there is a handshake (Closing handshake) process before closing the connection. Once the connection is established, both sides can communicate in two directions.

Opening handshake

Client Initiates connection handshake request

Get/chat http/1.1

Host:server.example.com

Upgrade:websocket

Connection:upgrade

sec-websocket-key:dghlihnhbxbszsbub25jzq==

Origin:http://example.com

Sec-websocket-protocol:chat, Superchat

Sec-websocket-version:13

Server-side response:

http/1.1 101 Switching protocols

Upgrade:websocket

Connection:upgrade

sec-websocket-accept:s3pplmbitxaq9kygzzhzrbk+xoo=

Sec-websocket-protocol:chat

"Upgrade:websocket" indicates that this is a special HTTP request, the purpose of which is to upgrade the client and server-side communication protocols from the HTTP protocol to the WebSocket protocol.

"Sec-websocket-key" is a browser base64 encrypted key

The "sec-websocket-accept" server side appends a magical string "258eafa5-e914-47da-95ca-c5ab0dc85b11" to the received Sec-websocket-key key, The result is Sha-1 hashed and then Base64 encrypted back to the client.

"Sec-websocket-protocol" indicates the optional sub-protocol provided by the client request, and the supported sub-Protocol selected on the server side, and the "Origin" server side is used to differentiate the unauthorized WebSocket browser

"http/1.1 101 Switching Protocols" In 101 is the status code returned by the server, all non-101 status codes indicate that handshake is not complete.

Data Framing

The WebSocket protocol transmits data through serialized packets. Fields such as opcode, payload length, payload data are defined in the packet protocol. The specific packet format is as follows:

FIN: Identifies whether the last packet for this message, accounting for 1 bit

RSV1, RSV2, RSV3: For extended protocols, typically 0, each accounting for 1bit

Opcode: Packet type (frame type), accounting for 4bits

0x0: Identifies an intermediate packet

0x1: Identifies a text type packet

0x2: Identifies a binary type packet

0x3-7: Reserved

0x8: Identifies a disconnect type packet

0x9: Identifies a ping type packet

0xA: Represents a Pong type packet

0xb-f: Reserved

Payload length:payload data of length, accounting for 7bits, if this value equals 126, then 16bits is used to represent Payload length, if this value equals 127, then 64bits is used to represent Payload Length

Payload Data: Application layer

Closing handshake

Compared to the opening handshake,closing handshake is much simpler, the active-closed party sends a closed type of packet to the other, and after the other party receives the packet, it replies to a packet of the same type, closing the completion.

The shutdown type packet complies with the packet protocol, opcode for 0x8,payload data can be used to carry the shutdown reason or message.

Although the current WebSocket agreement is still in the draft phase, but the browser has already started to support, the following is a different browser compatibility list:

Feature	Chrome	Firefox (Gecko)	Internet Explorer	Opera	Safari
Version-76 Support Obsolete	6	4.0 (2.0)	Not supported	11.00 (Disabled)	5.0.1
Protocol version 7 support Obsolete	Not supported	6.0 (6.0) Moz	Not supported	Not supported	Not supported
Protocol Version Support Obsolete	14	7.0 (7.0) Moz	HTML5 Labs	?	?
STANDARD-RFC 6455 Support	16	11.0 (11.0)	10	12.10	6.0

From the browser support point of view, WebSocket still has a long way to go, especially in China, the IE6 still prevails in the country, even after websocket standardization, the demise of the old version of the browser will take a long time, so at this stage comet is still the best solution.

[web Design]ajax, Comet and websocket--turn