KR20020003695A - Method of keeping persistent connection in hypertext transfer protocol HTTP - Google Patents

Abstract

PURPOSE: A method for maintaining a continuous connection on a hyper text transfer protocol is provided to reduce a creating/closing time of a connection by maintaining the first created HTTP connection continuously and not creating new HTTP connection in each time for a communication with a web server. CONSTITUTION: In an HTTP connecting method comprised by transmitting a requesting signal from a client to a server and by transmitting a responding signal from the server to the client, the requesting signal includes a requesting header having a client's inherent ID and the responding signal includes a responding header having a waiting timer designated by the server. Stages of the HTTP connecting method are described as follows. The client transmits the requesting signal to the server(101). The server receives the request and stores the corresponding URL to a user DB(10)(201,203). The server transmits the responding signal to the client(205). The client receives the response from the server(103). The client and the server maintain a connection during a waiting time included in the responding header(207).

Description

Method of keeping persistent connection in hypertext transfer protocol HTTP

The present invention relates to a method for maintaining a persistent connection over HTTP, which shortens the connection creation / end time by continuously maintaining and communicating the first created HTTP connection.

A hypertext transfer protocol (HTTP) connection is required to access the Internet homepage using a web browser. HTTP is a protocol used by WWW servers to send and receive hypertext, and clients can get information by jumping to another host server that is linked over hypertext over HTTP. When using the WWW browser to access the homepage of an Internet site, you must enter a URL beginning with "http: //".

This HTTP consists of a simple structure of "request & response." That is, when a client requests a corresponding URL to move to another page, a response comes from the web server, and when such an operation is completed, the connection is disconnected. More specifically, the actions as shown in FIG. 1 occur sequentially. -Open: create an HTTP connection,-request: send an HTTP request,-response: send an HTTP response from the server to the client,-close: HTTP connection Hang up.

Conventionally, the client makes an HTTP connection every time and then reconnects to the web server, thereby slowing down the page movement speed and pushing the information to the visitor. In particular, such a problem may be a serious problem when accessing a web server from a mobile communication terminal.

In the present invention, HTTP connection is maintained for a certain waiting time for speed improvement. That is, the object of the present invention is not to create a new HTTP connection each time to communicate with the web server, but to maintain a continuous connection on HTTP, which shortens the connection creation / end time by continuously maintaining and communicating the first created HTTP connection. To provide a way.

1 is a conceptual diagram illustrating a conventional HTTP connection method

2 is a conceptual diagram illustrating an HTTP access method according to the present invention;

3A is a process flow diagram illustrating an overview of the present invention.

FIG. 3B is a detailed process flowchart of FIG. 3A

4 is a configuration diagram of a user DB

5 is an example of the screen configuration of the first page

Fig. 6 is a system diagram showing an example in which the present invention is used in case of request relay.

Definition of Terms

(1) Request header: A header additionally transmitted when a client according to the present invention sends a connection request to a server. It has an ID that can identify a user as a value. (Eg, "Connection: Persistent (ID = value)"), where value is the ID of the client, for example, a telephone number or a unique serial number when the client is a mobile terminal device. .)

(2) Response header: A header additionally transmitted when the server according to the present invention sends a connection response to the client, and is transmitted only when the client sends the request header. The wait time is the value. (E.g., "Connection: Persistent (timeout = value)", where value is the maximum time to maintain a connection and the unit can be set in seconds.)

(3) Latency: The time designated as the value of the response header by the server supporting the persistent connection according to the present invention. The client and server according to the invention must maintain a connection during this time.

(4) User DB (10): A database for storing bookmarks for a user in a persistent connection according to the present invention. From this DB, the user browses to the last browsed location and constructs the first page.

(5) first page: The first page provided to assist a user to continue browsing from a location previously browsed when an access request from a client is first received.

(6) primary server: A server that directly receives requests from clients.

(7) Secondary server: A server that receives a request redirected from a primary server instead of immediately receiving a client's request.

(8) real server: The server located at the end of the request line that actually handles the client's request.

Summary of the invention

In the present invention, it is a basic idea to reuse a connected socket connection to increase communication speed by reducing overhead of socket connection request, connection request reception, and connection. To do this, the connection must be maintained after the HTTP transaction is completed and reused for the next transaction. According to the present invention, as in the conventional method illustrated in FIG. 1, the client does not create a new HTTP connection each time and communicates with the web server, but maintains the first HTTP connection that is created.

This concept is shown in FIG. After the socket is opened between the client and the server, the request and response are made and the socket is closed only after a certain waiting time. The request and response transactions can occur multiple times between opening and releasing the socket. That is, according to the present invention, since the operation of opening and releasing the socket every time is eliminated, the communication overhead can be greatly reduced and the communication speed can be increased. However, not all servers and all clients are aware of the connection method according to the present invention, so the client or server to which the present invention is applied needs to inform the peer. This information is communicated to the other party via HTTP headers.

The present invention basically relates to an HTTP connection method in which a client sends a request signal to a server and a server sends a response signal to the client. The request signal includes a request header having a unique ID of the client, and the response signal includes a response header having a waiting time specified by the server. In the present invention, the client may be a mobile phone terminal and the unique ID of the request header may be a phone number or a serial number (serial number) of the terminal. In addition, the waiting time of the response header of the server may be set in seconds within a range of 2 minutes.

Referring to Figure 3a, a method for maintaining a persistent connection over HTTP in accordance with the present invention

Transmitting, by the client, a request signal including the request header to the server [101],

The server receives the request [201] and stores the URL in the user DB 10 [203],

Transmitting, by the server, a response signal including the response header to the client [205],

The client receiving a response from the server [103],

The client and server are configured to maintain the connection for the waiting time included in the response header [207].

In the above configuration, before the client transmits the request signal to the server [101], it may further include checking whether there is data in the socket buffer [105] and if there is data, clearing the socket buffer [107]. In the step of receiving a response signal transmitted from the server, the client receives the content data from the server [103], a step of checking whether the stop button is selected or the content is terminated [109], and the stop button is selected. If the content is not finished and the content is not finished, the method may continuously receive the content data [110], and if the stop button is selected or the content is finished, processing the received data [111] may be included (see FIG. 3B).

According to the present invention, when a new request occurs before the waiting time, the client sends a re-request signal to the server, and when the user exits the browser from the client, the server disconnects immediately without waiting for the waiting time. It is done.

According to the present invention, when the connection between the client and the server is terminated, the last successfully browsed URL is stored in the user DB 10. The user DB 10 includes at least a user ID (connection_name) and A bookmark (connection_bookmark) field is included (see FIG. 4).

According to the present invention, when the client first attempts to connect, the method may further include searching for the last browsing position of the user stored in the user DB 10 and transmitting a search result to the client. At least the URL of the site that the user recently requested and the URL of the site that the user bookmarked. However, if the location that the user first attempts to connect to is the same as the location of the bookmark stored in the user DB 10, the user directly connects to the corresponding URL without transmitting the first page.

Detailed Description of the Invention

As a detailed description of the above-described outline, a process of the persistent connection method over HTTP according to the present invention will be described.

1. Client's Request

When the client sends a request to the server, it should add a request header as shown in FIG. 3A to inform the server that the client supports the persistent connection according to the present invention [101]. When the client is a mobile communication terminal (hereinafter referred to as "terminal"), it is preferable to set the value of this request header to a value that can distinguish itself from other terminals.

In FIG. 3A, a unique ID can be obtained by using the telephone number of the terminal as a value of the request header. That is, the request sent from the client to the server has the terminal telephone number as a value, such as "Connection: Persistent (ID = 820162011234)". This ID can be used when managing the bookmark of the terminal on the server side.

When the terminal becomes a client, there are the following items to be considered when implementing the terminal.

The terminal must always send a request header. This also applies when communicating with a server that does not support the present invention, and all requests from the terminal must include a request header even after connecting to the server.

-The ID value of the request header must be unique for each terminal. Even if the header is composed of a telephone number, the value of the request header should always be set. If it is decided not to transmit a phone number, the value of the request header is determined using the unique ID (manufacture number, serial number, etc.) of the terminal.

-1) When the server sends a response header, it must maintain the connection for the duration specified in the response header (strictly, from the moment the terminal processes the response header to the latency). 2) After the connection is made, if a new request occurs after the waiting time, the terminal must disconnect and try to connect again. 3) If a new request occurs before the waiting time, but the connection is inadvertently disconnected, the connection must be reconnected as if the first connection was attempted without being treated as an error.

In the case of the terminal, the implementation of the above three rules can be complicated.If the above three rules cannot be implemented due to the characteristics of the terminal, the connection is maintained indefinitely regardless of the waiting time. Whether the time expires or unintentionally terminates the connection, it is also desirable to retry the connection, such as when attempting to connect for the first time without treating it as an error.

-When the user exits the browser on the terminal, the server is disconnected "on the fly" so that the server does not wait for the waiting time.

2. Response from the server

The server receiving the request from the client processes the request [201] so that the server receiving the request including the request header sends a response [205], indicating that the server is also a server supporting the persistent connection according to the present invention. Should be included in the response. In this case, the response header value sets the time in seconds to wait for the next request from the client. Therefore, as shown in FIG. 3A, a header such as "Connection: Persistent (timeout = 120)" may be included (in this case, it is necessary to maintain a connection with the client for 120 seconds (= 2 minutes)).

The wait time may vary depending on the server and client settings, but in general, the terminal disconnects if there is no communication for 2 minutes, so it should not exceed 2 minutes.

If the server according to the present invention does not execute the present invention, 0 may be input in the response header value. That is, the header "Connection: Persistent (timeout = 0)" may be used to mean that the server supports the persistent connection according to the present invention, but is currently disabled.

When implementing a server supporting continuous access according to the present invention, the following matters should be considered.

The server always sends a response header when the client's request header is received. In case of error and return error number to client, response header should be sent.

Set the wait time in seconds for the value of the response header. This value cannot exceed 120.

You must maintain the connection for the waiting time set in the response header, and at the same time prepare to receive new requests from clients.

-The server immediately disconnects the moment it detects that the client has disconnected and stops the persistent connection according to the invention.

As a result, the server should check for the following conditions during latency: 1) Does the client send a new request, 2) Does the client disconnect, 3) Does the wait expire?

When a client's request is redirected to another server (secondary server), the request header must also be relayed. In this case, the primary server can be a client to the secondary server.

The response headers cannot be stored in cache memory.

3. keep connection

Clients and servers that send and receive requests and responses via the header are obliged to maintain the connection for the amount of time (wait time) specified in the value of the response header included in the response. If the request comes back within the waiting time, the client can resend the request to the maintaining server.

4. User DB (10) and First Page

The server supporting the persistent connection according to the present invention should be provided with the user DB 10 including the field name as shown in FIG. 4 in order to store the last browsed location of the client. Connection_name and Connection_bookmark in the field names of FIG. 4 must be included and may include more fields for additional functions.

Whenever the server processes the client's request, the server should store the URL in the user DB 10, and when the connection is terminated, the URL that has been successfully browsed must be stored in the user DB 10 above.

When the client attempts to connect for the first time, the user browses the last browsing position of the user from the user DB 10 and transmits the first page 20 as shown in FIG. From the first page 20, the user can continue to navigate the Internet from a previously browsed location. 5, "Persistent Connection Enabled" according to the present invention (Persistent Connection Enabled), "The site page you recently requested is http://www.kipo.go.kr", "You are http: / /www.x.com bookmarked "is shown as an example.

If the first attempted connection by the user is the same as the location of the bookmark stored in the user DB 10, there is no need to transmit the first page 20 of FIG.

5. request redirection

The HTTP request may be relayed in the same manner as shown in FIG. In FIG. 6, the form relayed from proxy server A-1 to A-4 is called local redirection, and the form relayed to another proxy server, proxy server array B, is externally relayed. It is called (extern redirection). In this case, proxy server A-4 or proxy server string B becomes the secondary server. If relaying occurs as shown in Fig. 6, proxy server A-1 should act as a client to another proxy server. To this end, proxy server A-1 must send the request headers together during request relay (internal relay). The persistent connection between the primary server and the secondary server may be processed in the same manner as the persistent connection between the client and the primary server.

However, tasks such as accessing the user DB 10 or creating the first page 20 must be performed by the primary server (proxy server A-1 in FIG. 6, that is, a server directly receiving a request). do. Basically, the present invention is made between a client and a server that receives the client's request directly.

The order in which the connections are released depends on the situation. If the persistent connection is established between the client and the primary server, and the persistent connection is established again between the primary and secondary servers, the order of disconnection is as follows.

(1) When the waiting time has expired (Here, it is assumed that the waiting time of the primary server matches the waiting time of the secondary server. Even if the waiting time of the primary server and the secondary server is different, the persistent connection related to the client is Is managed by the primary server only, so no problem occurs.)

A) The secondary server terminates the connection. The secondary server waits first after returning a response, so it expires first.

B) The primary server disconnects from the client. The connection with the secondary server is terminated.

C) Later, when the client tries to send a request, it detects that the connection has been lost. The client will then try to establish a connection again.

(2) Client terminates browsing and disconnects

A) The client disconnects.

B) The primary server detects that the client has disconnected and disconnects. It also disconnects from the secondary server.

C) The secondary server detects the disconnection of the primary server and disconnects.

6. Cache Policy in Application of the Invention

In the case of writing a cache manage module in connection with the present invention, the following matters should be noted.

By default, the request / response header belongs to the "hop-by-hop" header specified in HTTP / 1.1. Therefore it cannot be stored in the cache. (Also, it can't be retransmitted in the case of request relay. However, as mentioned above, the primary server can transmit to establish a persistent connection with the secondary server. In this case, the request header sent from the client can be used as it is. If necessary, proxy server A-1 could be added to this rule, for example, if a new rule for persistent connections is established by some agreement between proxy server string A and proxy server string B. You will have to rewrite and send the correct request header.)

-The ID included in the request header is a unique value that distinguishes the terminal or the user, so it can be used as a hash value for storing in a private cache.

-The server supporting the persistent connection method according to the present invention should add a response header even when the page requested by the client is read from the cache.

The client may not store the response header included in the response signal in the cache.

(1) Since the creation / end time of HTTP connection is eliminated, the overhead of socket connection between client and server can be reduced, which can benefit from speed and stability. It is especially effective in the case of terminal equipment with slow CPU processing speed connected to slow transmission network.

(2) As in PC communication, visitors who are currently connected can be identified. In other words, you can see when a user visited and when they left and what page they viewed.

(3) It is also possible to analyze the behavior of the visitor to push the information desired by the visitor. In other words, if you are mainly visiting only movie-related pages, you can immediately push movie-related event information from the web server.

Claims (18)

In the HTTP connection method in which the client sends a request signal to the server and the server sends a response signal to the client, The request signal includes a request header having a unique ID of the client, the response signal includes a response header having a waiting time specified by the server, and the HTTP access method includes Transmitting, by a client, a request signal including the request header to a server; The server receives the request and stores the URL in the user DB (10), Transmitting, by a server, a response signal including the response header to a client; The client receiving a response from the server, A method for maintaining a persistent connection over HTTP, comprising the step of maintaining a connection between the client and server for the latency included in the response header. The method of claim 1, further comprising checking whether there is data in the socket buffer and clearing the socket buffer if there is data, before the client sends the request signal to the server. The method of claim 1, wherein the client receives the response signal sent from the server Receiving content data from a server, Checking whether the stop button is selected or the content has ended, Continuously receiving content data when the stop button is not selected and the content is not terminated, and processing the received data when the stop button is selected or the content is terminated. The method of claim 1, wherein if a new request occurs before the waiting time, a re-request signal is transmitted from the client to the server. The method of claim 1, wherein if the user exits the browser on the client, the server immediately disconnects without waiting for a wait time. The method of claim 1, wherein the last successfully browsed URL is stored in the user DB when the connection between the client and the server is terminated. The method of claim 1 or 6, wherein the user DB (10) includes at least an ID (Connection_name) and a bookmark (Connection_bookmark) field of the user. The method of claim 6, wherein when the client attempts to connect for the first time, the server maintains a persistent connection on HTTP, which further includes searching for the last browsing position of the user stored in the user DB 10 and transmitting a search result to the client. Way. The method of claim 8, wherein the search result is an initial page that includes at least the URL of a site that the user recently requested and the URL of the site that the user bookmarked. The method according to claim 8, wherein if the first attempted connection by the user is the same as the location of the bookmark stored in the user DB 10, the user is connected to the corresponding URL without transmitting a search result. Way. The method according to any one of claims 1 to 6 and 8 to 10, wherein the client is a mobile telephone terminal and the unique ID of the request header is a telephone number of the terminal. 8. The method of claim 7, wherein the client is a mobile telephone terminal and the unique ID of the request header is the telephone number of the terminal. The system according to any one of claims 1 to 6 and 10, wherein a plurality of servers exist so that a persistent connection is established between the client and the primary server, and a persistent connection is configured again between the primary server and the secondary server. The continuous connection between the primary server and the secondary server proceeds in the same manner as the steps between the client and the primary server according to any one of claims 1 to 6 and 8 to 10, A method for maintaining a persistent connection over HTTP, characterized in that the primary server performs the task of accessing the user DB. The system of claim 7, wherein a plurality of servers exist such that a persistent connection is configured between the client and the primary server, and a persistent connection is configured again between the primary server and the secondary server. The persistent connection between the primary server and the secondary server proceeds in the same way as the step between the client and the primary server in claim 7 A method for maintaining a persistent connection over HTTP, characterized in that the primary server performs the task of accessing the user DB. 10. The method of claim 8 or 9, wherein the task of creating the first page is performed by a primary server. In claim 13, After the wait time expires, the secondary server terminates the connection, the primary server disconnects from the client, then terminates the connection with the secondary server, and the client is disconnected when it tries to send a request. Disconnection step of detecting a loss; If the client terminates browsing and disconnects, the client disconnects, the primary server detects that the client has disconnected, disconnects, and disconnects from the secondary server. A method of maintaining a persistent connection over HTTP that includes an additional disconnection step that includes detecting and disconnecting a server. In claim 14, After the wait time expires, the secondary server terminates the connection, the primary server disconnects from the client, then terminates the connection with the secondary server, and the client is disconnected when it tries to send a request. Disconnection step of detecting a loss; If the client terminates browsing and disconnects, the client disconnects, the primary server detects that the client has disconnected, disconnects, and disconnects from the secondary server. A method of maintaining a persistent connection over HTTP that includes an additional disconnection step that includes detecting and disconnecting a server. In claim 15, After the wait time expires, the secondary server terminates the connection, the primary server disconnects from the client, then terminates the connection with the secondary server, and the client is disconnected when it tries to send a request. Disconnection step of detecting a loss; If the client terminates browsing and disconnects, the client disconnects, the primary server detects that the client has disconnected, disconnects, and disconnects from the secondary server. A method of maintaining a persistent connection over HTTP that includes an additional disconnection step that includes detecting and disconnecting a server.