Webserver Push Technology

Server push (server push)

The basic idea of push technology is to change the browser's active query information to the server to send unsolicited information. The server sends a batch of data, and the browser displays the data, ensuring a connection to the server at the same time. When the server needs to send a batch of data again, the browser displays the data and remains connected. Later, the server is still able to send bulk data, the browser continues to display the data, and so on.

Client drag (client pull)

In the client drag technique, the server sends a batch of data, inserting instructions in an HTTP response or document header tag, allowing the browser to "mount the data again within 5 seconds" or "load data into a URL in 10 seconds." When the specified time is reached, the client will follow the instructions of the server, either refresh the current data, or transfer the new data.

In fact, the two technical means of push and pull are very different, but the purpose is almost consistent, is to give the user finally convenient to provide the latest information.

In server push technology, the HTTP connection is maintained until the server knows that it has ended sending data and sends an end signal, or the client interrupts the connection. In the client drag technique, the HTTP connection is not maintained, instead, the client is told to establish a new connection and to establish a connection to get what data.

In server push, the singularity is in the "multipart/mixed" format of mime, which can make a message (or HTTP response) include many data items, in the client drag, the singularity is the HTTP response header (or equivalent HTML elements), It tells the client what action to run after the specified delay time.

Server push is typically more efficient than client drag because it does not have to establish a new connection for the data that might be. Because the connection is always maintained, even if no data is transferred, the server must be willing to allocate these tcp/ipport, which is a serious problem for servers with a limited number of tcp/ipport.

The client towing efficiency is low because this must establish a new connection for transmitting data each time. But it doesn't have to stay connected at all times.

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

Another advantage of server push relative to client drag is that server push is relatively easy to control. For example, the server maintains a connection every time it pushes, but it can shut down any connection at any time without the need to set up a special algorithm on the server. And the client drag in the same situation to be a lot of trouble, it every time to establish a connection with the server, the server in order to handle the client pull request and a specific end-user matching, etc., need to use a rather cumbersome algorithm.

It is assumed that the CGI program that implements server push is written in the Shell scripting language, sometimes with some problems. For example, the client finally interrupts the connection, and the shell program usually fails to notice that it wastes resources useless, and the solution to this problem is to use Perl or C to write such CGI programs so that the user can end execution when the connection is interrupted.
As mentioned above, in server push, the connections in multiple responses are always maintained so that the server can send many other data at any time. One obvious advantage is that the server can control the time and frequency of updating data. In addition, such a method is highly efficient due to the constant connection. The disadvantage is that maintaining a connection state wastes server-side resources. Server Push-back compare easy interrupt.

And then I'll talk about server push technology.
When the server responds to a request, HTTP uses the MIME message format to encapsulate the data. Typically an HTTP response can include only one block of data. However, MIME has a mechanism that can use a single message (or HTTP response) to represent multiple blocks of data, a mechanism that becomes the standard MIME type of "multipart/mixed". multipart/mixed messages in general format such as the following:
Content-type:multipart/mixed;boundary=thisrandomstring
--thisrandomstring
Content-type:text/plain
The data for the first object.
--thisrandomstring
Content-type:text/plain
The data for the second object.
--thisrandomstring--

The above message contains two blocks of data, both of which are "Text/plain". Two short lines (-) after the last "thisrandomstring" indicate that the message ends and there is no data behind it.

For server push, use a variant of "multipart/mixed" type--multipart/x-mixed-replace. Here, "X" means the experimental type. "Replace" means that each new block of data replaces the previous block. This means that the new data is not appended to the old data, but instead.

The following are the actual "multipart/x-mixed-replace" types used:
Content-type:multipart/x-mixed-replace;boundary=thisrandomstring
--thisrandomstring
Content-type:text/plain
Data for the first object
--thisrandomstring
Content-type:text/plain
The data for the second (last) object.
--thisrandomstring--
The key to using this technique is that the server does not push the entire "multipart/x-mixed-replace" message, but the data block each time it is sent.
The HTTP connection is always maintained, so that the server can push new data at the speed and frequency that it needs, and the browser needs to wait in the current form between two blocks, and the user can even go to other forms to do something else, and when the server needs to send new data, it's just the source (ABC IME doesn't have that word * &^$#) The transport pipeline sends a data block, and the client corresponds to a form that updates itself.

In server push technology, a "multipart/x-mixed-replace" type of message consists of a unique boundary line that cuts each block of data. Each chunk has its own header, so you can specify the object-related content type and other information. Because the feature of "Multipart/x-mixed-replace" is that each new block of data replaces the previous data object, the most recent data object is always displayed in the browser.
The "multipart/x-mixed-replace" message has no end. That is, the server can always remain connected and send the required data. If a user no longer displays data streams in a browser form, or if the browser is in the middle of a connection between servers (such as a user pressing a "STOP" button), the server's push is interrupted. This is a typical way for people to use server push.

When the browser finds the "Content-type" header or arrives at the end of the header, the previous document in the browser form is cleared and the next document starts to appear. When the next message boundary is found, it is felt that the current block of data (document) has ended.
In summary, server-pushed data consists of a set of headers (usually "Content-type"), the data itself, and the cut-off (message boundary) three parts. When the browser sees the cutter, it remains in the same state until the next chunk arrives.

By programming the above concepts, we can get the actual server push program. For example, the following UNIX shell program will cause the browser to display a list of processes 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--"
Sleep 5
Done
Notice that the boundary setting is sent before the sleep statement, which ensures that the browser clears its buffer and displays the most recent data received.
NCSA httpd The user cannot use spaces in the content type, including boundary parameters. NCSA httpd can only use a string without a space character as the content type. Assume that there is a space in the content type row (except for the space after the colon), and any text after the space is deleted.
The following demo examples are correct:
Content-type:multipart/x-mixed-replace;boundary=thisrandomstring
The following example does not work properly because it has spaces in the middle:
Content-type:multipart/x-mixed-replace; Boundary=thisrandomstring
Another advantage of server push is that it can be done for a single inline image. The document containing the image can be updated by the server timing or fixed cycle. This is easy: just make the SRC attribute of the IMG element point to the URL that pushes a sequence of images.

If the server is pushed for a single inline image, the image in the document is replaced by the newly pushed image, and the document itself does not need to change (if the document is not server-pushed). In this way, a limited animation in a Web page can be replaced by a static picture.

Client drag

A simple way to use a client drag is to make the document actively reload itself on a fixed cycle. For example, consider the following HTML document:
<meta http-equiv= "Refresh" content=1>
<title>document one</title>
Here ' s some text.<p>
Suppose you load it into a browser that supports dynamic documents (more than Netscape 1.1, Internet Explorer and mosaic also support client drag), and it reloads itself once every second.
Because the meta element actually simulates an HTTP response header in an HTML document, it can tell the browser to use its own information as an HTTP response. The META tag in the previous example is equivalent to:
Refresh:1
This, in effect, is an HTTP header that tells the browser to update the document every second. Assuming that the delay is 12 seconds, then this is the directive:
<meta http-rquiv= "Refresh" content=12>
Then it is equivalent to:
Refresh:12

On the drag of the client I also lazy continue to write, about how to enable the client to voluntarily apply for other URLs of data, please use the following:
<meta http-equiv= "Refresh" content= "12; url=http://icools.yeah.net/">
Note that the URLs here cannot use relative paths and must all be specified.

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