Server push details

Server push)

The basic idea of push technology is to change the browser's active query information to the server's active sending information. The server sends a batch of data, the browser displays the data, and ensures the connection with the server. When the server needs to send a batch of data again, the browser displays the data and keeps the connection. In the future, the server can still send batch data, and the browser will continue to display the data, and so on.

Client pull (client pull)

In the client drag technology, the server sends a batch of data and inserts instructions in the HTTP response or document header flag, let the browser "load the data again within five seconds" or "load data to a URL within 10 seconds ". When the specified time is reached, the client performs the operation as instructed by the server, refreshes the current data, or transfers new data.

In fact, the push and pull technologies are very different, but the goal is almost the same, in order to provide end users with the latest information conveniently.

In server push technology, HTTP connections remain until the server knows that it has ended sending data and sending an end signal, or the client has interrupted the connection. In the client drag technology, HTTP connections are not maintained. On the contrary, the client is notified of how to create a new connection and what data to obtain when a connection is established.

In server push, what's amazing is the mime in the multipart/mixed format. It can make a message (or HTTP Response) contain many data items and drag them on the client, what's amazing is that the HTTP Response Header (or equivalent HTML element) can tell the client what action to perform after the specified delay.

Server push is generally more efficient than client drag because it does not have to create new connections for subsequent data. Because the connection is always maintained, even if there is no data transmission, the server must be willing to allocate these TCP/IP ports, this is a serious problem for servers with a limited number of TCP/IP ports.

Client drag efficiency is low, because this must create a new connection for each data transfer. However, it does not have to always maintain the connection.

In practice, it usually takes a considerable amount of time to establish an HTTP connection, as many as one second or even more. Therefore, in terms of performance, server push is more attractive to end users, especially when information needs to be updated frequently.

Another advantage of server push over client dragging is that server push is relatively easy to control. For example, the server maintains a connection for each push, but it can close any of the connections at any time without setting specialAlgorithm. In the same situation, client dragging requires a lot of trouble. It needs to establish a connection with the server every time, and the server matches the client dragging request with a specific end user in order to process the situation, requires a very troublesome algorithm.

If the CGI pushed by the server is implementedProgramIt is written in Shell scripting language, and sometimes there are some problems. For example, if the client end user breaks the connection, the shell program usually cannot notice it, which will waste resources for no use, to solve this problem, you can use Perl or C to write these CGI programs so that the user can stop running when the connection is interrupted.

As mentioned above, connections are always maintained among multiple responses in server push so that the server can send more data at any time. One obvious benefit is that the server can fully control the time and frequency of data update. In addition, this method is highly efficient because the connection is always maintained. The disadvantage is that maintaining the connection will waste resources on the server. Server push is easy to interrupt.

Next, let's talk about the server push technology.
When the server responds to a request, HTTP uses the mime Message format to encapsulate data. Generally, an HTTP response can only contain one data block. However, there is a mechanism for mime to use one message (or HTTP Response) to represent multiple data blocks. This mechanism is a standard MIME type of "multipart/mixed. The general format of multipart/mixed packets is as follows:
Content-Type: multipart/mixed; boundary = thisrandomstring
-- Thisrandomstring
Content-Type: text/plain
The data of the first object.
-- Thisrandomstring
Content-Type: text/plain
The data of the second object.
-- Thisrandomstring --

The preceding message includes two data blocks, both of which are "text/plain ". The two short-term messages (--) after the last "thisrandomstring" indicate that the packet ends and there is no data.

For server push, a multipart/X-mixed-replace variant of the multipart/mixed type is used. Here, "x-" indicates the lab type. "Replace" indicates that each new data block replaces the previous data block. That is to say, the new data is not appended to the old data, but replaced by it.

The following is the actual "multipart/X-mixed-Replace" type:
Content-Type: multipart/X-mixed-replace; boundary = thisrandomstring
-- Thisrandomstring
Content-Type: text/plain
Data of the first object
-- Thisrandomstring
Content-Type: text/plain
The data of the second (last) object.
-- Thisrandomstring --
The key to using this technology is that the server does not push the entire "multipart/X-mixed-Replace" packet, but the data block after each transmission.
The HTTP connection is always maintained, so the server can push new data at the desired speed and frequency. The browser only needs to wait in the current window between the two data blocks, users can even do other things in other windows. When the server needs to send new data, it only sends data blocks from the source (ABC input method does not have that word * & ^ $ #) transmission pipeline, update the window corresponding to the client.

In server push technology, "multipart/X-mixed-Replace" messages are composed of unique boundaries that divide each data block. Each data block has its own header, so it can specify the content type and other information related to the object. Because the "multipart/X-mixed-Replace" feature is that each new data block replaces the previous data object, the browser always displays the latest data object.
The "multipart/X-mixed-Replace" message does not end. That is to say, the server can always maintain the connection and send the required data. If the user no longer displays data streams in the browser window, or connects the browser to the server (for example, the user presses the "stop" button), the server push will be interrupted. This is a typical way for people to use server push.

when the browser finds the Content-Type header or reaches the end of the header, the previous document in the browser window is cleared and the next document is displayed. When the next message boundary is found, the current data block (document) is deemed to have ended.
in short, the data pushed by the server is composed of a group of header labels (usually including "Content-Type"), data itself, and delimiter (Message boundary. When the browser sees the delimiter, it remains unchanged until the next data block arrives.

program the above concepts to get the actual server push program. For example, the following Unix shell program enables the browser to display the process list on the server every 5 seconds:
#! /Bin/sh
echo "HTTP/1.1 200"
echo "Content-Type: multipart/X-mixed-replace; boundary = -- thisrandomstring -- "
echo" "
echo" -- thisrandomstring -- "
while true
DO
echo" Content-Type: text/html "
echo" "
echo" h2processes on this machine updated every 5 seconds/H2 "
echo" Time: "
date
echo" p "
echo" plaintext "
PS-El
echo" -- thisrandomstring -- "
SL Eep 5
done
note that the boundary setting is sent before the sleep statement, which ensures that the browser clears its buffer and displays the latest received data.
NCSA httpd users cannot use spaces in the content type, including boundary parameters. NCSA httpd can only use a string without spaces as the content type. If there is a space in the content type line (except for spaces after the colon), any text after the space will be deleted.
The following example is correct:
Content-Type: multipart/X-mixed-replace; boundary = thisrandomstring
the following example does not work properly, because it contains spaces in the middle:
Content-Type: multipart/X-mixed-replace; boundary = thisrandomstring
another advantage of server push is that it can be applied to a single inline image. Documents including images can be updated by the server at regular or periodic intervals. The implementation is very simple: you only need to direct the src attribute of the IMG element to the URL that pushes a series of images.

If the server pushes a Single Inline image, the image in the document will be replaced by the newly pushed image again and again, and the document itself does not need to change (assuming that the document is not pushed to the server ). In this way, limited animations on Web pages can be replaced by static images.

Client drag

One simple way to drag a client is to automatically reload the document at a fixed period. For example, consider the following HTML document:
<Meta HTTP-EQUIV = "refresh" content = 1>
<Title> document one </title>
<H1> This is document one! </H1>
Here's some text. <p>
If you load it into a browser that supports dynamic documents (Netscape 1.1 or above, Internet Explorer and mosaic also support client dragging), it will reload itself once every second.
The meta element simulates the HTTP Response Header in the HTML document, so it can tell the browser to use its own information as an HTTP response. The meta tag in the above example is equivalent:
Refresh: 1
In this way, the HTTP header tells the browser to update the document every second. If the latency is 12 seconds, the following command is used:
<Meta HTTP-RQUIV = "refresh" content = 12>
It is equivalent:
Refresh: 12

I am also lazy to write down the drag of the client. Please use the following to learn how to enable the client to automatically apply for data from other URLs:
<Meta HTTP-EQUIV = "refresh" content = "12; url = http://icools.yeah.net/">
Note that the URL here cannot use relative paths and must all be specified.

The time interval can be set to 0, so that the browser loads new data as quickly as possible after the current document is displayed!

 

Http://www.it315.org/articles/web/web1.htm

Server push