JP2007188514A - Server side proxy device, client side proxy device, data transfer method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a proxy device for reducing a network load. <P>SOLUTION: The server side proxy 30 and the client side proxy 40 associate reply data with its fingerprint to register it in a fingerprint cache and the server side proxy device 30 further associates and registers a URL concerning request data corresponding to the reply data. When the reply data having the fingerprint registered in the client side proxy 40 from the server side proxy 30 is transferred, the fingerprint is transferred instead of the reply data. In addition, when the request data concerning the registered URL is received from the client side proxy 40, the server side proxy 30 replies the reply data registered by being associated with the URL to the client side proxy 40 without transferring the request data. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a server-side proxy device, a client-side proxy device, a data transfer method, and a program that perform data transfer for other devices.

  2. Description of the Related Art A client / server type information system is widely used, which includes a server that provides various services via a network and a client that requests a desired service from the server. In particular, the WORLD WIDE WEB system (or simply referred to as WEB) composed of a WEB server and a client that communicate using the HTTP protocol on the Internet is a client-server type information system that is very widely used. Normally, a server program operates on the server, and a predetermined tool (program) such as a browser operates on the client. The contents of services provided on the Internet are also diverse, providing information such as text, still images, moving images, audio (such as homepages, e-mails, digital contents, etc.) and programs via the network. Various services such as distribution or transfer services, electronic store services for selling products, reservation services for seats and rooms, mediation services for various contracts, etc., and new forms of services one after another Has appeared.

  By the way, in a client-server type information system such as WEB, whatever service is provided, the service is basically provided by data transfer between the client and the server. Is done. Therefore, the capacity (bandwidth) of the network used for communication between the client and the server tends to become a bottleneck of the entire system. Therefore, a cache technique is usually used to reduce the load on the network.

  In the case of a WEB system, browsers and the like that operate on a client often use a cache mechanism, and cache recently accessed data. In WEB, access is made by designating information or service with a name called URL, so that the cache on the client is the information that has been requested to the WEB server in the past and the data returned as a result of the service can be cached. The URL is recorded in the cache in association with the URL. In this case, if there is a request for the same URL information or service as that in the cache and it can be determined that the response data in the cache is not stale, by returning that data, Communication between can be eliminated.

  When there are a plurality of users in a corporate office LAN, a research institution LAN, or a home LAN, a proxy server may be placed between the LAN and the Internet, and a cache mechanism may be provided in the proxy server. Many. The cache in the client (for example, the browser cache) operates as a cache dedicated to the client user, while the proxy server cache on the LAN operates as a shared cache for a plurality of client users. For this reason, in the latter case, the cache is effective even when accessing a URL accessed by another person (another client) in the past.

  Now, in WEB, communication is performed between a client and a server using a protocol called HTTP. The HTTP protocol is a combination of a “request message” sent from the client to the server and a “reply message” that returns a response from the server to the client.

  The request message consists of a “request header” and a “request body”. The request header includes a URL for designating information to be accessed and a service, a method name indicating the type of access, and other various information necessary for access. The data to be sent to the server is entered in the request body. The data contained in the request body is also called “request data”.

  The reply message includes a “reply header” and a “reply body”. Information such as the status of the processing result is entered in the reply header, and data such as the requested information and the processing result of the requested service is entered in the reply body. The data contained in the reply body is also called “reply data”.

  As a request message method, there are a “GET method” for reading information on the server, a “PUT method” for writing data held by the user to the server, and a “POST method” for sending back the result of processing in response to the request. It is the main thing used to access services. In addition, a method such as DELETE is defined.

  In many cases, the request body of the request message of the GET method and the reply body of the reply message of the PUT method are empty. The request body of the POST method request message contains information used for processing on the server side as necessary, and the reply body of the POST method reply message contains data of the processing result.

  Data read from the server by the GET method can be divided into “dynamic data” generated on the server side each time it is read, and “static data” that returns data already stored on the server side as it is. Of these, the contents of dynamic data may be different each time the same URL is read, and in many cases, the server sends back a specification indicating that caching is impossible in the header of the reply message. Therefore, it is a portion of static data that is subject to caching with WEB data. This static data can be divided into “shared data” that can be referenced by an unspecified number of users and “private data” that performs access control so that only specific users can access by authenticating users. . The former shared data can be cached in any cache. However, the latter private data cannot be cached in a shared cache such as a proxy server (because private data must be authenticated and sent back by the server). However, in the case of a personal cache such as a browser, even private data can be cached.

  Since the POST method returns the result of processing on the server side, in general, the server sends back the result with a specification indicating that caching is impossible in the header of the reply message. Therefore, it is not normally subject to caching.

  Since the PUT method sends data to the server, the cache does nothing.

  The conventional WEB cache targets static content as a cache target. In the past, information and services published on the WEB were not so frequently updated, and many were published to an unspecified number of people, so the proportion of static content was very high. Cache technology was also effective in reducing network load.

However, as a system in which a user accesses information and services on a server via a network using a WEB browser, such as a WEB-based ASP (Application Service Provider), a conventional cache technology as described below. The data that cannot be handled is increasing.
-Since the user is authenticated and the user who can access is restricted, there is much private data.
-Many dynamic data are generated by referring to the backend database.
-In many cases, the POST method is used for form processing and search.
-The PUT method is often used to share information within a group.
As a result, the cache technology alone has not functioned effectively as a technique for reducing the load on the network.

  The present invention has been made in consideration of the above circumstances, and includes a server-side proxy device, a client-side proxy device, data, and a cache-side / compression technology that can further reduce the load on the network connecting the proxy devices. An object is to provide a transfer method and a program.

  The present invention relates to requested data transmitted from each of a plurality of client devices to a plurality of server devices and relayed to a client-side proxy device in charge of proxying access to each of the plurality of server devices. A plurality of request messages each including the URL of the request are received, transferred to the server device that is the destination of the request message among the plurality of servers, and transmitted from the server device to the client device as a response to the request message. A server-side proxy device that transfers a reply message to a client-side proxy device that is a proxy for the client device that is the destination of the reply message, the reply message being a response to a request message transferred from the client-side proxy device Receiving means for receiving a reply message that is a reply to a request message transferred from a client-side proxy device among the plurality of client-side proxy devices; Generating a fingerprint of data mounted on the message body of the reply message, and generating a fingerprint that is a fingerprint of the data mounted on the message body of the reply message; Holding means for holding the fingerprint as a fingerprint cache in association with the data that was the source of the fingerprint and the URL of the data; and A determination means for determining whether or not the fingerprint is held in the fingerprint cache, and the determination means determines that the fingerprint is held in the fingerprint cache; When the determination means determines that the fingerprint is not held in the fingerprint cache, the fingerprint is associated with the data. A first transmission means for adding the reply message to the client device and transmitting the reply message to the client-side proxy device, and being included in the request message transferred from the client-side proxy device. When the URL of the requested data is held in the fingerprint cache, a reply message in which the data held in the fingerprint cache in association with the URL is loaded in the message body is sent to the client device. And a second transmission means for transmitting to the client side proxy device.

  Further, the present invention receives a plurality of request messages each including URLs of requested data transmitted from a plurality of client devices to a plurality of server devices, and accesses the server device that is the destination of the request message. A reply message sent to the client device from the server device via the server-side proxy device as a reply to the request message as a reply to the request message. A client-side proxy device that transfers to a device, the reply message being a reply to a request message transmitted from the client device and a fingerprint of data mounted in a message body of the reply message; A finger that is received from the proxy device and is generated from data that is mounted in a message body of a reply message that is a response to a request message transmitted from one of the plurality of client devices Receiving means for receiving a print from the server-side proxy device; holding means for holding the fingerprint as a fingerprint cache in association with the data received with the fingerprint and the URL of the data; A determination means for determining whether or not a fingerprint is held in the fingerprint cache; and when the determination means determines that the fingerprint is held in the fingerprint cache; A reply message in which data associated with the client is loaded in a message body is transmitted to the client device, and the determination unit determines that the fingerprint is not held in the fingerprint cache. A first transmission means for associating a print with data loaded in the message body of the reply message and adding it to the fingerprint cache and transmitting the reply message to the client device; and transmitting from the client device When the URL of the requested data included in the requested message is held in the fingerprint cache, the data held in the fingerprint cache in association with the URL is messaged. And a second transmission means for transmitting a reply message mounted on the sage body to the client device.

  The present invention relating to the apparatus is also established as an invention relating to a method, and the present invention relating to a method is also established as an invention relating to an apparatus. Further, the present invention relating to an apparatus or a method has a function for causing a computer to execute a procedure corresponding to the invention (or for causing a computer to function as a means corresponding to the invention, or for a computer to have a function corresponding to the invention. It is also established as a program (for realizing) and also as a computer-readable recording medium on which the program is recorded.

  According to the present invention, the reply message including the reply data that retains the correspondence between the reply data included in the reply message and the fingerprint between the server-side proxy device and the client-side proxy device. With respect to, by transferring the corresponding fingerprint instead of transferring the reply data, the amount of transfer data between the proxy devices can be reduced.

  For example, even if the reply message of the GET method is private data, it can be compressed between fingerprints and transferred between proxy devices. Further, for example, even if the reply message of the GET method is dynamic data, if the content is the same, it can be compressed by a fingerprint and transferred between proxy devices. Further, for example, even in the case of the POST method, if the result is the same data, the data can be compressed between fingerprints and transferred between proxy devices.

  According to the present invention, in addition to holding the reply data included in the received reply message and the fingerprint in association with each other, the proxy device includes a URL related to the request data corresponding to the reply message; By storing the fingerprint in association with the request data, if the URL related to the request data is stored when the request data is received, the received request data is not transferred and the request data is transferred. A reply message including reply data held in association with the fingerprint to be sent can be returned.

  ADVANTAGE OF THE INVENTION According to this invention, the load of the network which connects between proxy apparatuses can be reduced more.

  Hereinafter, embodiments of the invention will be described with reference to the drawings.

  In the following, a case where the WAN is the Internet and the client is connected to the user office LAN and the HTTP protocol is used will be described as an example. Even if the client is installed in a home LAN other than the office, for example, it can be applied even if a protocol other than the HTTP protocol is used.

  FIG. 31 shows a basic configuration example of a computer network system to which the present invention is applied. In this configuration example, a wide area network (WAN) 14 such as the Internet or a dedicated line is connected between a local area network (LAN) 12 in the ASP server center 2 and a local area network (LAN) 16 in the user office 4. The server 20 in the ASP server center 2 and the client 50 in the user office 4 can communicate with each other via the LAN 12, the WAN 14, and the LAN 16. One or more servers are connected to the ASP server center LAN, and one or more clients are connected to the user office LAN.

  The WEB-based ASP provides services based on various application programs from the server 20 installed in the server center 2 via the WAN 14, and the user uses the WEB browser on the client installed in the office 4. Access the service.

  In such a usage mode, the effective communication capacity (bandwidth) of the network connecting the user office LAN 16 and the server center LAN 12, particularly the wide area network 14 such as the Internet, is the server center LAN 12 or the user office LAN 16. Lower than that, which becomes a bottleneck in performance, causing a communication delay, resulting in a problem that the response performance of the application is lowered.

  Therefore, in this embodiment, as shown in FIG. 1, two modules, a server-side proxy 30 and a client-side proxy 40, are installed at both ends of the wide area network 14 that connects the server center LAN 12 and the user office LAN 16. By performing fingerprint compression (FP compression) described later between them to reduce the amount of communication data, the bottleneck of the wide area network is eliminated.

  The server 20, the server side proxy 30, the client side proxy 40, and the client 50 of this embodiment all operate software (server program, server side proxy program, client side proxy program, client program) on the computer. Can be realized. In this case, an OS having a desired function of the computer, driver software, software for packet communication, encryption software, etc., or hardware such as a communication interface device, an external storage device, an input / output device, etc. is mounted or connected as necessary Is done. In this case, it is preferable to use a graphical user interface (GUI) for inputting information from the user or the administrator or presenting information to the user.

  On the client 50 used by the user to use the service, a program such as a WEB browser operates according to the purpose. A user uses a service by, for example, issuing a request message to a server that provides a desired service such as information transfer or order reception from the WEB browser, receiving a reply message, or repeating this appropriately. . Of course, instead of general-purpose software such as a WEB browser, other software such as dedicated software for using a specific service may be used. Further, the client may be not a general-purpose computer but a mobile phone terminal having an Internet function, for example.

  A predetermined server program runs on the server 20 and provides services specific to the server site to the user of the client 20.

  As shown in FIG. 1, the server-side proxy 30 is connected to both the intra-server center LAN 12 and the WAN 14 and can be installed and operated so as to operate as a transparent proxy. Further, as shown in FIG. 2, it can be installed on the LAN 12 in the server center. Further, as shown in FIG. 3, the server-side proxy 30 can be implemented so as to be built in the server 20.

  Similarly, as shown in FIG. 1, the client-side proxy 40 can be installed and implemented so as to connect to both the intra-user office LAN 16 and the WAN 14 and operate as a transparent proxy. Further, as shown in FIG. 2, it can be installed on the LAN 16 in the user office. Further, as shown in FIG. 3, the function of the client side proxy 40 can be implemented in a browser or the like that operates on the client 50. Alternatively, the client-side proxy 40 for personal use may be operated on the client 50 that operates such as a browser.

  Note that the server-side proxy 30 and the client-side proxy 40 may have the same form as shown in FIGS. 1 to 3 or different forms.

  Both the server side proxy 30 and the client side proxy 40 of this embodiment have a cache mechanism called a fingerprint cache (FP cache). The fingerprint cache records and manages data exchanged by the HTTP protocol by a name called a fingerprint (FP).

  As illustrated in FIG. 4, the fingerprint is determined by a predetermined calculation method (hash function in the example of FIG. 4) from the contents of data exchanged by the HTTP protocol (content in the example of FIG. 4). It ’s a short number. This numerical value may be a variable length, but a fixed-length numerical value is easier to handle from the viewpoint of ease of processing.

  As a method for calculating the fingerprint, a well-known hash function such as MD-5 or SHA-1 can be used. These hash functions are used for digital signatures on data, and when given data is converted into a 128-bit number for MD-5 and a 160-bit number for SHA-1. can do. The feature of these hash functions is that if two data X1 and X2 are given and the data X1 and the data X2 are the same, the hash value calculated for the data X1 and the hash value calculated for the data X2 However, when two different data A and B are given, the hash value calculated for data A and the hash value calculated for data B are different with a very high probability. (In principle, the hash values calculated for two different data A and B may be the same, but the probability is small enough to be ignored in practice).

  As shown in FIG. 5, the fingerprint cache (60 in the figure) of the server-side proxy 30 and the client-side proxy 40 has a data body (61 in the figure) exchanged in the past by the HTTP protocol. The fingerprint value (62 in the figure) calculated from the above is recorded and managed as a name.

  For example, when transferring data from the server-side proxy 30 to the client-side proxy 40 using the HTTP protocol, the server-side proxy 30 calculates a fingerprint of the data, and the data corresponding to the fingerprint is stored in the fingerprint cache. Then, since the data (data having the same content) has been transferred in the past, the corresponding fingerprint value is transferred without transferring the data. The client-side proxy 40 that has received the fingerprint can reproduce the data to be transferred by extracting the data corresponding to the fingerprint value from the fingerprint cache. By using this method (ie, data compression-> data transfer-> data decompression), it is only necessary to send the fingerprint value if it is the same data that was sent in the past. Can do. Of course, the same applies when transferring data from the client-side proxy 40 to the server-side proxy 30.

  For the purpose of explanation, in the data transfer between the server side proxy 30 and the client side proxy 40, the fingerprint compression means that the message body data is replaced with the fingerprint by using the fingerprint cache to compress the transfer information amount. It shall be called (FP compression).

  Note that, between the server-side proxy 30 and the client-side proxy 40, all messages are subject to FP compression (ie, subject to processing for replacing data with fingerprints using the fingerprint cache). However, for example, in order to exclude the application to the one that cannot be expected to have the effect of the fingerprint cache, the message that satisfies the predetermined condition is excluded from the application target of the FP compression (always do not perform the FP compression). Transfer).

  The predetermined condition in this case is, for example, that predetermined information is described in the message header. Specifically, for example, information indicating a GET method and information indicating a request are described in a message header. Another example of the predetermined condition is that the data to be transferred is null or has a very short size. Of course, there are various other variations. A plurality of conditions may be used in combination.

  Next, an inter-proxy message format (for a message to which FP compression is applied) when data is transferred between the server-side proxy 30 and the client-side proxy 40 will be described with reference to FIGS. .

  Messages that are not subject to FP compression may be transferred between proxies in the message format (when received by the proxy on the FP compression side (transmission side)) without doing anything for FP compression. Absent. Alternatively, the proxy on the FP compression side (transmission side) can transfer the message header, for example, with information that makes it possible to identify that the message is not subject to FP compression.

  When data is transferred between the server-side proxy 30 and the client-side proxy 40, the message to which FP compression is applied includes a message (a message at the time of compression) in which data is FP-compressed and replaced with a fingerprint. There are messages that are not FP-compressed and data is loaded (messages at the time of non-compression).

  The uncompressed message format is used when data included in the message is not registered in the fingerprint cache. On the other hand, the message format at the time of compression is used when data included in the message is registered in the fingerprint cache.

  On the decompression side (reception side), the data can be registered in the fingerprint cache when the uncompressed format message is received.

  FIG. 6 shows an example of the message format. (A) is an uncompressed message, and (b) is a compressed message.

  In (a), data is placed on the message body, and in (b), a fingerprint (FP) is placed on the message body instead of data. Further, in this example, identification information that enables identification of the presence or absence of FP compression is described in the message header (in the compression proxy), and whether or not FP compression is performed based on this identification information (in the decompression proxy) (For example, 0 means no compression, 1 means compression). The identification information may be special information used between proxies, or may be information that uses or uses a field originally present in a normal HTTP message header.

  At the time of non-compression, in the example of FIG. 6A, the message does not include the fingerprint, but the message body may include the fingerprint in addition to the data, or as illustrated in FIG. As described above, a fingerprint may be included in the message header. In this way, when the fingerprint cache is registered for the data on the decompression side, it is possible to save time and effort for obtaining the fingerprint from the data again by using the fingerprint.

  If there is a message that is not subject to FP compression, the decompression side (reception side) determines whether the message is subject to FP compression depending on whether or not the identification information is included in the message header. It is also possible to determine whether the message is not applicable. Also, identification information may be provided in a header of a message that is not subject to FP compression, and three types of messages may be identified based on the identification information (for example, 01 is not applicable, and 10 is applicable (applicable). And) no compression, 11 (applicable and) with compression).

  Here, FIG. 32 shows a specific example of the message in the format of FIG. 6A, and FIG. 33 shows a specific example of the message in the format of FIG. 6B. “Fingerprint-Mode:...” In the header of each figure corresponds to identification information, and “6E39... 0128” in the body in FIG. 33 corresponds to a fingerprint.

  FIG. 34 shows a specific example of the message in the format of FIG. “Fingerprint:...” In the header corresponds to the fingerprint.

  FIG. 8 shows another example of the message format. (A) is an uncompressed message, and (b) is a compressed message. In (a), data is put on the message body, and in (b), the message body is null. In this example, the fingerprint (FP) is described in the message header in both (a) and (b). The identification information that can identify the presence or absence of FP compression is the same as in the above example.

  In this case, there is also a method of using the same message format (format not including the fingerprint) as shown in FIG.

  If there is a message that is not subject to FP compression, the proxy on the compression side (transmission side) always applies a finger to the message header that is subject to FP compression, in addition to the method based on the identification information described above. In the case of a configuration describing a print, the decompression side (reception side) can also determine whether or not a fingerprint is included in the message header.

  Here, FIG. 35 shows a specific example of the message in the format of FIG. 8A, and FIG. 36 shows a specific example of the message in the format of FIG. 8B.

  FIG. 9 shows still another example of the message format. (A) is an uncompressed message, and (b) is a compressed message. In (a), data is put on the message body, and in (b), the message body is null. In this example, the fingerprint (FP) is described in the message header in both (a) and (b). However, in this example, identification information that enables identification of the presence or absence of FP compression is not used.

  In this example, the presence or absence of FP compression can be identified based on whether or not the message body is null. However, if a message that is not subject to FP compression and whose message body is null may exist, for example, depending on whether or not a fingerprint (FP) exists in the message header, FP compression Identify whether the message is a compressed message as an application target or a message body that is not a target of FP compression and the message body is null (or information indicating whether the message header is an application target of FP compression or not. May be provided).

  Note that there is a method of using a format that does not describe a fingerprint in a message as shown in FIG. In this case, the presence or absence of FP compression can be identified by whether or not the fingerprint is included in the message header. However, if there is a message that is not subject to FP compression, for example, information indicating whether the message is subject to FP compression or not may be provided in the message header.

  Here, FIG. 37 shows a specific example of the message in the format of FIG. 9A, and FIG. 38 shows a specific example of the message in the format of FIG. 9B.

  FIG. 39 shows a specific example of the message in the format of FIG.

  In the following, the present embodiment will be described in detail with a focus on the case where the reply data is transferred from the server-side proxy 30 to the client-side proxy 40 when the reply data is FP compressed / decompressed.

  FIG. 11 shows a configuration example of the server-side proxy 30 of this embodiment, and FIG. 12 shows a configuration example of the client-side proxy 40 of this embodiment. 11 and 12 mainly show the configuration when data is transferred from the server-side proxy 30 to the client-side proxy 40. FIG.

  As shown in FIG. 11, the server-side proxy 30 includes a receiving unit 31 that performs processing for receiving a transfer message from the intra-server center LAN 12 or the wide area network 14, and performs FP compression on the data included in the transfer message. A processing unit 32 for performing processing, a transmission unit 33 for performing processing for transmitting a transfer message to the LAN 12 in the server center or the wide area network 14, and a finger for associating and storing the fingerprint and the original data A print cache (FP cache) 34 is provided. The processing unit 32 also includes a fingerprint (FP) compression determination unit 321 for determining whether or not the data included in the transfer message is to be compressed, and a finger for performing search and registration with respect to the fingerprint cache 34. A print cache (FP cache) management unit 322 and a fingerprint (FP) compression processing unit 323 for performing processing such as replacing data included in the transfer message with a corresponding fingerprint are included.

  As shown in FIG. 12, the client side proxy 40 includes a receiving unit 41 that performs processing for receiving a transfer message from the LAN 16 in the user office or the wide area network 14, and performs FP decompression on the data included in the transfer message. Processing unit 42 for performing processing, transmitting unit 43 for performing processing for transmitting a transfer message to the user office LAN 16 or the wide area network 14, and a finger for storing fingerprints in association with the original data A print cache (FP / cache) 44 is provided. Further, the processing unit 42 searches the fingerprint (FP) compression determination unit 421 and the fingerprint cache 34 for determining whether or not the data included in the transfer message is to be compressed and whether or not the transfer message is subjected to FP compression. Fingerprint cache (FP cache) management unit 422 for performing registration and registration, and fingerprint (FP) decompression processing for performing processing such as decompressing original data from the fingerprint included in the FP compressed transfer message Part 423.

  Note that the compression-side FP compression determination unit 321 and the decompression-side FP compression determination unit 421 check whether the message satisfies a predetermined condition as described above, thereby converting the data included in the message into the FP. It is determined whether or not to apply compression (when all messages are to be applied to FP compression, the FP compression determination unit 321 on the compression side and the corresponding part of the procedure example shown below are unnecessary, and decompression is performed. The corresponding determination part of the FP compression determination unit 421 on the side and the corresponding part of the procedure example shown later are unnecessary). In addition, the decompression-side FP compression determination unit 421 determines whether or not the data subjected to FP compression application is FP compressed. In the following, description will be focused on the case of transferring a message to which FP compression is applied (when it is determined that FP compression is to be applied, or when all messages are to be applied to FP compression).

  FIG. 13 shows an example of the processing procedure of the server side proxy 30 when the reply message is transferred from the server side proxy 30 to the client side proxy 40. Although FIG. 13 describes the processing when one reply message is received, the processing illustrated in FIG. 13 is actually performed on all reply messages received by the server-side proxy 30.

  The server side proxy 30 receives a reply message from the server 20 by the receiving unit 31 (step S1).

  The FP compression determination unit 321 checks and determines whether the reply data of the reply message is for FP compression (step S2). If it is determined that the reply data is not subject to FP compression (step S2), the received reply message is transferred from the transmission unit 33 to the client side proxy 40 (step S9).

  If it is determined in step S2 that the reply data of the reply message is for FP compression, the FP cache management unit 322 calculates a fingerprint value of the reply data (step S3), The fingerprint cache 34 is searched using the fingerprint value as a key (step S4).

  If a set of the fingerprint value and the corresponding data is registered in the fingerprint cache 34 (step S5), the FP compression processing unit 323 sends the received reply message to the fingerprint Using the value of FP, the FP compression format is used (for example, FIG. 8B) and transmitted from the transmission unit 33 to the client side proxy 40 (step S6). At this time, the value of the field (Content-Length: field) indicating the data length in the reply header is set according to the format at the time of FP compression as necessary.

On the other hand, as a result of the search in step S4, if the set of the fingerprint value and the corresponding data is not registered in the fingerprint cache 34 (step S5), the following two operations are performed.
(1) In the FP compression processing unit 323, the received reply message is converted into a format at the time of non-FP compression (eg, using the fingerprint value as necessary) (for example, FIG. 8A) and transmitted. The data is transmitted from the unit 33 to the client side proxy 40 (step S7).
(2) The FP cache management unit 322 associates the fingerprint value with the reply data (using the fingerprint value as a key) and registers it in the fingerprint cache 34 (step S8).

  Note that either of (1) and (2) may be performed first or in parallel.

  Next, FIG. 14 shows an example of the processing procedure of the client side proxy 40 when the reply message is transferred from the server side proxy 30 to the client side proxy 40. FIG. 14 describes the processing when one request message is received, but actually, the processing illustrated in FIG. 14 is performed for all the request messages received by the client side proxy 40.

  The client side proxy 40 receives a reply message from the server side proxy 30 by the receiving unit 41 (step S11).

  The FP compression determination unit 421 checks and determines whether the reply data of the reply message is for FP compression (step S12). If it is determined that the reply data is not subject to FP compression (step S12), the received reply message is transferred from the transmitter 43 to the client 50 (step S20).

  If it is determined in step S12 that the reply data of the reply message is for FP compression, the FP compression determination unit 421 further checks to determine whether the reply data is FP compressed (step). S13).

  If it is determined in step S13 that the reply data of the reply message is FP-compressed (for example, in the case of FIG. 8B), the FP cache management unit 422 determines the fingerprint of the reply data. A value is obtained (step S14), and the fingerprint cache 44 is searched using the fingerprint value as a key (step S15).

  When the FP decompression processing unit 423 adds data corresponding to the fingerprint value retrieved from the fingerprint cache 34 to the received reply message and uses special information between proxies. After deleting the information, the information is transmitted from the transmission unit 43 to the client 50 (step S16). At this time, if necessary, the value of the field (Content-Length: field) indicating the data length in the reply header is set to the length of the data corresponding to the value of the fingerprint.

On the other hand, if it is determined in step S13 that the reply data of the reply message is not FP compressed (for example, in the case of FIG. 8A), the following two operations are performed.
(1) When using special information between proxies in the FP decompression processing unit 423, after deleting the information from the received reply message, the information is transmitted from the transmission unit 43 to the client 50 (step S18).
(2) The FP cache management unit 422 calculates the fingerprint value of the reply data (step S17), associates the fingerprint value with the reply data (using the fingerprint value as a key). ) And is registered in the fingerprint cache 34 (step S19).

  Note that either of (1) and (2) may be performed first or in parallel.

  By the way, in step S14, the fingerprint is described in the message. However, in step S17, when a fingerprint is described in the message, a method for obtaining the fingerprint from the message, and when no fingerprint is described in the message, a hash function or the like is used based on the reply data. There is a method of calculating a fingerprint value. Even when the fingerprint is described in the message, a method of calculating the fingerprint value based on the reply data is also possible. Further, step S14 / step S17 may be performed between step S12 and step S13, and step S17 may be performed between step S18 and step S19.

  Further, the determination in step S12 and the determination in step S13 may be performed simultaneously.

  When the request message is transferred from the client-side proxy 40 to the server-side proxy 30, when the fingerprint cache is not used, the server-side proxy 30 uses the client-side proxy as illustrated in FIG. The request message may be received from 40 (step S21) and transmitted to the server 20 (step S22). Similarly, as illustrated in FIG. 16, the client-side proxy 40 may receive a request message from the client 50 (Step S23) and transmit it to the server-side proxy 30 (Step S24).

  Hereinafter, data transfer using the fingerprint cache will be described more specifically with reference to FIG. 17 (during registration, that is, during non-FP compression) and FIG. 18 (during FP compression).

  First, referring to FIG. 17, an operation when transferring data not registered in the fingerprint cache from the server-side proxy 30 to the client-side proxy 40 and registering the fingerprint cache will be described.

  (1) It is assumed that the browser or the like on the client 50 issues a POST method request message to the server 20 with the URL “/A.cgi”, for example. First, a browser or the like is set so that a request message to the server 20 is sent to the client-side proxy 40.

  (2) The client-side proxy 40 that has received the request message from the client 50 transfers the request message to the server-side proxy 30.

  (3) The server-side proxy 30 that has received the request message transfers the request message to the server 50.

  (4) After processing the request message, the server 20 sends the reply message back to the server-side proxy 30.

  (5) Upon receiving the reply message, the server-side proxy 30 first calculates the fingerprint of the reply data included in the received reply message, and checks whether the data having the fingerprint name is in the fingerprint cache 34. . If it is not included, the first data (in the case of the configuration that the fingerprint cache registration once may be deleted or invalidated later, the fingerprint cache once registered or deleted or invalidated, Therefore, the data is entered (registered) in the fingerprint cache 34 with the fingerprint as a name.

  (6) The server side proxy 30 transfers the reply message to the client side proxy 40. As described above, when the fingerprint value calculated from the reply data is sent in the reply header or the like, the trouble of calculating the fingerprint again by the client side proxy 40 can be saved.

  (7) Since the client-side proxy 40 that has received the reply message is the first data, it registers the reply data in the fingerprint cache 44. As described above, the fingerprint is calculated from the reply data, or the fingerprint put in the reply header or the like by the server side proxy is taken out and this is entered as a name.

  (8) The client-side proxy 40 deletes the information used only between the server-side proxy 30 and the client-side proxy 40 (such as a fingerprint value in the reply header). After that, a reply message is sent back to the client 50 (such as a browser operating on the client 50).

  In the server-side proxy 30, the fingerprint cache registration (5) may be performed after the operation (6). In the client side proxy 40, the fingerprint cache registration of (7) may be performed after the operation of (8).

  Next, with reference to FIG. 18, an operation in the case of transferring the data registered in the cache by performing the operation of FIG. 17 from the server side proxy 30 to the client side proxy 40 will be described.

  (1) to (4) are the same as (1) to (4) in the operation described with reference to FIG.

  (5) Upon receiving the reply message from the server 50, the server-side proxy 40 first calculates the fingerprint of the reply data that the received reply message has, and whether the data having the fingerprint name is in the fingerprint cache 34 Find out. If it is, it is data that has been sent in the past (data registered in the fingerprint cache), so (for example, put the fingerprint value in the reply header and empty the reply body as described above) ) Reply body data is replaced with fingerprints.

  (6) The server side proxy 30 transfers the reply message in which the reply body is replaced with the fingerprint to the client side proxy 40.

  (7) Upon receiving the reply message, the client-side proxy 40 detects that the reply data has been replaced with the fingerprint, and uses the specified fingerprint (for example, in the reply header as described above) The corresponding data is taken out from the print cache 44 and is put into the reply body.

  (8) Then, the client-side proxy 30 (in the case of a configuration in which information used only between the server-side proxy 30 and the client-side proxy 40 such as a fingerprint value exists in the reply header or the like) After deleting), a reply message is sent back to the client (such as a browser operating on the above).

  By the way, the fingerprint caches of the server-side proxy 30 and the client-side proxy 40 have upper limits on their capacities, and therefore, garbage collection is performed according to a predetermined algorithm, for example, erasing old data or data that is unlikely to be used. preferable.

  However, in this case, even if the fingerprint cache 34 of the server-side proxy 30 is held, data that has been deleted in the fingerprint cache 44 of the client-side proxy 40 can be generated. In (7), the client side proxy 40 tried to extract the data to replace the reply data from the fingerprint cache 44 based on the fingerprint, but there is a fingerprint and data pair corresponding to the fingerprint cache 44. May not. In such a case, for example, the client-side proxy 40 requests the server-side proxy 30 to send the specified fingerprint data, and the requested server-side proxy 30 receives the specified fingerprint. It is sufficient to provide a mechanism for fetching the data from the fingerprint cache 34 and sending it back.

  On the other hand, when there is data already deleted in the fingerprint cache 34 of the server side proxy 30 but still in the fingerprint cache 44 of the client side proxy 40, refer to FIG. In the operation (7) described above, when the fingerprint / reply data is registered in the fingerprint cache 44 in the client side proxy 40, the fingerprint / reply data registered at that time is overwritten. Also good.

In the operation (5) described with reference to FIG. 18, the server-side proxy 30 obtains the fingerprint of the reply data. If the fingerprint is in the fingerprint cache 34, the same data as the reply data is obtained. Processing is performed assuming that the fingerprint is paired with the fingerprint and stored in the fingerprint cache 34. In practice, this method is sufficient if the same fingerprint is not generated from different data, but an error that occurs when the fingerprints of different data accidentally become the same value with a very small probability. There is also a way to get rid of. In this case, when the fingerprint obtained from the reply data is in the fingerprint cache 34, the data paired with the fingerprint and stored in the fingerprint cache 34 is compared with the ply data. Whether or not they are the same may be determined. At this time, if it is determined that data having the same fingerprint but different contents is registered, a method exemplified below can be considered.
The fingerprint is not used anymore (the data giving the fingerprint will not be cached thereafter).
Prioritize the previously registered fingerprint / data (other data giving the same fingerprint value as the fingerprint being registered will not be cached during the registration).
Prioritize the fingerprint / data that is currently registered (the fingerprint / data being registered will be updated one after another by other data giving the same value fingerprint).

  By the way, the server-side proxy 30 or the client-side proxy 40 of the present embodiment is provided with a URL / fingerprint correspondence table (URL / FP table) to be described later, and by using this together with the fingerprint cache, the proxy server The shared cache can be operated as well. Whether or not this function is provided for each server-side proxy 30 and for each client-side proxy 40 can be determined.

  First, the client side proxy 40 provided with the above functions will be described.

  FIG. 19 shows a configuration example of the client side proxy 40 in this case. This client-side proxy 40 has a URL / fingerprint table (URL / FP table) 45 that holds the correspondence between the URL accessed in the past and the fingerprint of the reply data in addition to the configuration / function of FIG. And a URL cache processing unit 424.

  In addition to the URL and fingerprint, the URL / FP table 45 also includes information such as the MIME type entered in the reply header when accessed with the URL, and a time stamp used to determine the validity period. Also record. The URL / FP table 45 records information necessary only when the conventional shared cache can be cached.

  FIG. 20 shows an example of the processing procedure of the client side proxy 40 when the reply message is transferred from the server side proxy 30 to the client side proxy 40.

  The processing procedure in this case is the same as the procedure in FIG. 14 except that it is added after steps S16 and S19 in the procedure in FIG. 14, and in FIG. 20, after steps S16 and S19 in the procedure in FIG. The part of the processing procedure is shown. Here, the description will focus on the part added to the procedure described in FIG.

  The client-side proxy 40 transmits a reply message to the client 50 by the transmission unit 43 (step S16 or S18), and then checks whether the reply message is a cache target in the URL cache processing unit 424. Judgment is made (step S27). If it is determined that the URL is to be cached, the URL cache processing unit 424 associates the URL, the fingerprint, information necessary for constructing the reply header, etc. (using the URL as a key) with the URL / FP. Register in the table 45 (step S28). If it is determined not to be cached, nothing is done.

  The determination in step S27 and the registration in the URL / FP table in step S28 may be performed between step S13 and step S16 or S19.

  Note that the method for determining whether or not the received reply message at the time of registration is a cache target may be the same as the conventional method at the time of registration (for example, the reply data of the GET method and its header) That are not described as information that cannot be cached).

  Next, FIG. 21 shows an example of a processing procedure related to the operation of the shared cache of the proxy server in the client side proxy 40 when the request message received from the client 50 is transferred from the client side proxy 40 to the server side proxy 30.

  The client side proxy 40 receives a request message from the client 50 by the receiving unit 41 (step S31).

  The URL cache processing unit 424 checks and determines whether the reply message for the request message is a cache target (step S32). It should be noted that the method for determining whether or not it is a cache target at the time of response may be the same as the conventional method at the time of response (for example, whether or not the reception request message is of the GET method).

  If it is determined that the request data is not cacheable (step S32), the received request message is transferred from the transmission unit 43 to the server side proxy 30 (step S38).

  If it is determined in step S32 that the reply message for the request message is to be cached, the URL cache processing unit 424 further extracts the URL specified in the request message (step S33). The URL / FP table 45 is searched using the URL as a key (step S34).

  If the fingerprint of the reply data corresponding to the URL is not cached (step S35), the received request message is transferred from the transmission unit 43 to the server side proxy 30 (step S38). At this time, the time stamp of the currently held data is written in the If-Modified-Since header of the request message and transferred to the server-side proxy 30, and the currently held data from the server-side proxy 30 is valid. When the reply message is received, the process may be performed to go to step S37.

  Further, even if the fingerprint of the reply data corresponding to the URL is registered (step S35), it is determined that the data is invalid based on the information for determining the validity period held together. If so (step S36), the received request message is transferred from the transmission unit 43 to the server-side proxy 30 (step S38).

  On the other hand, the fingerprint of the reply data corresponding to the URL is registered (step S35), and it is determined that the data is valid based on the information for determining the validity period held together. If so (Step S36), the URL cache processing unit 424 obtains information necessary for constructing reply data from the URL / FP table 45, and uses the fingerprint of the reply data corresponding to the URL as a key in the fingerprint cache. 44 is searched to obtain reply data, a reply message is generated based on the data, and is transmitted from the transmission unit 43 to the client 50 (step S37).

  Hereinafter, the operation of the shared cache will be described more specifically with reference to FIG. 22 (during response).

  (1) It is assumed that the browser or the like on the client 50 issues a GET method request message to the server 20 with the URL “/C.html”, for example.

  (2) When a request is received with a new URL, if the URL is listed in the URL / FP table 45, the validity period is determined in the same manner as in the conventional shared cache. The URL / FP table 45 is retrieved from the fingerprint / cache table 44, the data having the name is extracted from the fingerprint cache 44 as reply data, and the MIME / etc. Reply header is constructed from the URL / FP table 45. The necessary information is taken out and a reply header is created.

  (3) The created reply message is sent back to the client 20 (such as a browser operating on the client 20).

  Even in the case of a request message having an If-Modified-Since header that requests to send data only when the contents of the cache have been updated after the specified time, the update is first made with reference to the URL / FP table. If it can be determined that it has not been performed, a reply message is created and returned, and if not, the information of If-Modified-Since can be rewritten to the server again to go to listen.

  Next, the server side proxy 30 provided with the cache function will be described.

  Although the cache function of the client-side proxy 40 has been described above, the server-side proxy 30 can be similarly implemented.

  In this case, the message transfer source client 50 and the message transfer destination server side proxy 30 for the client side proxy 40 are respectively connected to the client side proxy 40 (transfer source) and the server 20 (transfer destination) for the server side proxy 30. Thus, the configuration and procedure related to the cache are the same.

  FIG. 23 shows a configuration example of the server side proxy 30 in this case. The server-side proxy 30 further includes a URL / fingerprint table (URL / FP table) 35 that holds correspondence between URLs accessed in the past and fingerprints of reply data in addition to the configuration / function of FIG. And a URL cache processing unit 324.

  FIG. 24 shows an example of the processing procedure of the server side proxy 30 when the reply message is transferred from the server side proxy 30 to the client side proxy 40.

  The processing procedure in this case is the same as the procedure in FIG. 13 except that it is added after steps S6 and S8 in the procedure in FIG. 13, and in FIG. 24, after steps S6 and S8 in the procedure in FIG. The part of the processing procedure is shown. Here, the description will focus on parts that are different from the procedure described in FIG.

  After the server-side proxy 30 transmits a reply message to the client-side proxy 40 by the transmission unit 33 (step S6 or S8), the URL cache processing unit 324 indicates that the reply data of the reply message is to be cached. Whether or not is determined (step S39-2). If it is determined that the URL is to be cached, the URL cache processing unit 324 associates the URL, the fingerprint, information necessary for constructing the reply header, and the like (using the URL as a key) with the URL / FP. Register in the table 35 (step S39-3). If it is determined not to be cached, nothing is done.

  Of course, as described above, this procedure can be variously modified.

  FIG. 25 shows an example of a processing procedure related to the operation of the shared cache of the proxy server in the server side proxy 30 when the request message received from the client side proxy 40 is transferred from the server side proxy 30 to the server 20.

  The processing procedure in this case is basically the same as the procedure in FIG. In S37 of FIG. 21, reply data is created and transferred to the client 50. In S47 of FIG. 25 corresponding to this, reply data is created in a format (for example, FIG. 8B) at the time of FP compression. It is transferred to the client side proxy 40.

  As described above, the configuration in which the server side proxy also has the URL / FP table table to perform the cache processing works effectively when one server side proxy is used by a plurality of client side proxies. In other words, if cacheable data requested by a client-side proxy is already being accessed by another client-side proxy, it is also cached by the server-side proxy. Complete.

  In the above description, the URL / FP table table is provided separately from the fingerprint cache. However, the URL / FP table table may be integrated with the fingerprint cache.

  In the example described so far, when the reply data is transferred from the server side proxy 30 to the client side proxy 40, the reply data is the same as the data registered in the fingerprint cache. Although the network traffic is reduced by transferring the corresponding fingerprint instead of the reply data, the FP compression is further applied to the case where the request data is transferred from the client side proxy 40 to the server side proxy 30. It is possible. Note that FP compression can be applied only when request data is transferred from the client-side proxy 240 to the server-side proxy 230.

  In addition, when FP compression is applied only to the request data transfer, FP compression is applied only to the reply data transfer, or FP compression is applied to the request data transfer and the reply data transfer. The configuration related to the shared cache function for the reply data corresponding to the URL specified by the message can be provided only in the client side proxy, only in the server side proxy, or in both proxies.

  When FP compression is applied to request data transfer from the client side proxy 40 to the server side proxy 30, the roles of the server side proxy 30 and the client side proxy 40 for the reply data described above may be reversed. Is applied to both data transfers, the server-side proxy 30 includes a fingerprint decompression processing unit in the processing unit 32 in addition to the configuration of FIG. 11, and the client-side proxy 40 adds to the configuration of FIG. Further, the processing unit 42 may be provided with a fingerprint compression processing unit.

  In any proxy, the fingerprint compression processing unit and the fingerprint decompression processing unit may be combined into a fingerprint (FP) compression / decompression processing unit.

  In addition, the server-side proxy 30 and the client-side proxy 40 may provide a fingerprint cache for request data transfer independently of a fingerprint cache for reply data transfer, but the same fingerprint is used for reply data transfer and quest data transfer. A cache may be shared.

  FIG. 26 shows a configuration example of the proxy (server side proxy, client side proxy) in this case.

  FIG. 27 shows an example of a processing procedure of the client side proxy 40 when a request message is transferred from the client side proxy 40 to the server side proxy 30.

  The client side proxy 40 receives a request message from the client 50 by the receiving unit 41 (step S51).

  The FP compression determination unit 421 checks and determines whether or not the request data of the request message is for FP compression (step S52). If it is determined that the request data is not subject to FP compression (step S52), the received request message is transferred from the transmission unit 43 to the server side proxy 30 (step S59).

  If it is determined in step S52 that the request data of the request message is for FP compression, the FP cache management unit 422 calculates the fingerprint value of the request data (step S53) The fingerprint cache 44 is searched using the fingerprint value as a key (step S54).

  If the set of the fingerprint value and the corresponding data is registered in the fingerprint cache 44 (step S55), the FP compression / decompression processing unit 425 sends the received request message to the The fingerprint value is used to format in FP compression (for example, FIG. 8B) and transmitted from the transmission unit 43 to the server side proxy 30 (step S56).

On the other hand, as a result of the search in step S54, if the set of the fingerprint value and the corresponding data is not registered in the fingerprint cache 44 (step S55), the following two operations are performed.
(1) In the FP compression / decompression processing unit 425, the received request message is converted into a non-FP compression format (using the fingerprint value as necessary) (for example, FIG. 8A). Then, the data is transmitted from the transmission unit 43 to the server side proxy 30 (step S57).
(2) The FP cache management unit 422 associates the fingerprint value with the request data (using the fingerprint value as a key) and registers it in the fingerprint cache 44 (step S58).

  Note that either of (1) and (2) may be performed first or in parallel.

  Next, FIG. 28 shows an example of a processing procedure of the server side proxy 30 when a request message is transferred from the client side proxy 40 to the server side proxy 30.

  The server side proxy 30 receives a request message from the client side proxy 40 by the receiving unit 31 (step S61).

  The FP compression determination unit 321 checks whether or not the request data of the request message is for FP compression (step S62). If it is determined that the request data is not subject to FP compression (step S62), the received request message is transferred from the transmission unit 33 to the server 20 (step S70).

  If it is determined in step S62 that the request data of the request message is subject to FP compression, the FP compression determination unit 321 further checks whether or not the request data is FP compressed (step S62). S63).

  If it is determined in step S63 that the request data of the request message is FP-compressed (for example, in the case of FIG. 8B), the FP cache management unit 322 determines the fingerprint of the request data. A value is obtained (step S64), and the fingerprint cache 34 is searched using the fingerprint value as a key (step S65).

  When the FP compression / decompression processing unit 325 adds data corresponding to the fingerprint value retrieved from the fingerprint cache 34 to the received reply message and uses special information between proxies After the information is deleted, it is transmitted from the transmission unit 33 to the server 20 (step S66).

On the other hand, if it is determined in step S63 that the request data of the request message is not FP compressed (for example, in the case of FIG. 8A), the following two operations are performed.
(1) When using special information between proxies in the FP compression / decompression processing unit 325, after deleting the information from the received reply message, the information is transmitted from the transmission unit 33 to the server 20 (step S68). ).
(2) The FP cache management unit 322 obtains the fingerprint value of the request data (step S67), associates the fingerprint value with the request data (using the fingerprint value as a key). ) And is registered in the fingerprint cache 34 (step S69).

  Note that either of (1) and (2) may be performed first or in parallel.

  As described above, in step S67, when a fingerprint is described in the message, a method for obtaining the fingerprint from the message, and when no fingerprint is described in the message, a hash function is obtained based on the request data. There is a method of calculating a fingerprint value by, for example. Even when the fingerprint is described in the message, a method of calculating the fingerprint value based on the request data is also possible. Further, step S64 / step S67 may be performed between step S62 and step S63, and step S67 may be performed between step S68 and step S69.

  Further, the determination in step S62 and the determination in step S63 may be performed simultaneously.

  If the request data is replaced with the fingerprint in this way, for example, when uploading the same file to the server many times, it is only necessary to send the fingerprint for the second and subsequent times. It can be reduced.

  Of course, in this case, the above-described configuration related to the shared cache function for the reply data corresponding to the URL specified by the request message transmitted by the client can be implemented for the server-side proxy and the client-side proxy. A configuration example of the proxy (server side proxy, client side proxy) in this case is shown in FIG. The operations of the server side proxy and the client side proxy in this case are the same as those already described.

  In the present embodiment, the request message transferred from the client-side proxy to the server-side proxy and the reply message transferred from the server-side proxy to the client-side proxy have been shown. If both the device that sends the request message and the device that sends the reply message, or the device that sends both the request message and the reply message are connected, of course, it is transferred from the client side proxy to the server side proxy. Request messages and reply messages, and request messages and reply messages that are forwarded from the server-side proxy to the client-side proxy. It is also such that the target only request message transmitted from the request message and the server side proxy is transferred to the side proxy to the client side proxy.

  By the way, the description has so far been focused on the one-to-one communication between one server-side proxy and one client-side proxy. Of course, the scope of the present invention is not limited to the server-side proxy and client-side proxy. The system is not limited to a one-to-one communication system, a server-side proxy and a client-side proxy communicate one-to-many, a server-side proxy and a client-side proxy communicate many-to-one, Alternatively, the present invention can be applied to a system in which a server-side proxy and a client-side proxy communicate many-to-many. For example, as shown in FIG. 30, a client-side proxy installed in a plurality of user offices, a personal proxy used by a mobile user, or the like can be implemented so as to share and use the server-side proxy.

  In the past, the entire data included in one message was subject to FP compression (target registered in the fingerprint cache). For example, the data included in one message is a set of data in a predetermined unit. In the case of the configuration, it is also possible to configure that only a part of unit data included in one message is subject to FP compression (target to be registered in the fingerprint cache).

Each function described above can be realized as software.
The present embodiment can also be implemented as a program for causing a computer to execute predetermined means (or for causing a computer to function as predetermined means, or for causing a computer to realize predetermined functions), The present invention can also be implemented as a computer-readable recording medium on which the program is recorded.

  Note that the configuration illustrated in the embodiment of the present invention is an example, and is not intended to exclude other configurations, and a part of the illustrated configuration may be replaced with another or one of the illustrated configurations. Other configurations obtained by omitting a part, adding another function or element to the illustrated configuration, or combining them are also possible. Also, another configuration that is logically equivalent to the exemplified configuration, another configuration that includes a portion that is logically equivalent to the exemplified configuration, another configuration that is logically equivalent to the main part of the illustrated configuration, and the like are possible. is there. Further, another configuration that achieves the same or similar purpose as the illustrated configuration, another configuration that achieves the same or similar effect as the illustrated configuration, and the like are possible. In addition, various variations of various components illustrated in the embodiment of the present invention can be implemented in appropriate combination. Further, the embodiment of the present invention is an invention of an invention as an individual device, an invention of two or more related devices, an invention of the entire system, an invention of components within an individual device, or a method corresponding thereto. The invention includes inventions according to various viewpoints, stages, concepts, or categories. Therefore, the present invention can be extracted from the contents disclosed in the embodiments of the present invention without being limited to the exemplified configuration.

  The present invention is not limited to the embodiment described above, and can be implemented with various modifications within the technical scope thereof.

The figure which shows the structural example of the computer network system which concerns on one Embodiment of this invention. The figure which shows the other structural example of the computer network system which concerns on the embodiment The figure which shows the further another structural example of the computer network system which concerns on the embodiment The figure for demonstrating the fingerprint used in the embodiment The figure for demonstrating the fingerprint cache used in the embodiment A diagram showing an example of a message format used in the embodiment A diagram showing another example of a message format used in the embodiment A diagram showing still another example of a message format used in the embodiment A diagram showing still another example of a message format used in the embodiment A diagram showing still another example of a message format used in the embodiment The figure which shows the structural example of the server side proxy which concerns on the same embodiment The figure which shows the structural example of the client side proxy which concerns on the same embodiment The flowchart which shows the example of a procedure of the server side proxy which concerns on the same embodiment The flowchart which shows the example of a procedure of the client side proxy which concerns on the same embodiment The flowchart which shows the example of a procedure of the server side proxy which concerns on the same embodiment The flowchart which shows the example of a procedure of the client side proxy which concerns on the same embodiment The figure for demonstrating the data transfer between the server side proxy and client side proxy which concern on the embodiment The figure for demonstrating the data transfer between the server side proxy and client side proxy which concern on the embodiment The figure which shows the other structural example of the client side proxy which concerns on the same embodiment The flowchart which shows the other example of a procedure of the client side proxy which concerns on the same embodiment The flowchart which shows the other example of a procedure of the client side proxy which concerns on the same embodiment The figure for demonstrating the data transfer between the client and the client side proxy which concern on the embodiment The figure which shows the other structural example of the server side proxy which concerns on the same embodiment The flowchart which shows the other example of a procedure of the server side proxy which concerns on the same embodiment The flowchart which shows the other example of a procedure of the server side proxy which concerns on the same embodiment The figure which shows the further another structural example of the proxy in the same embodiment The flowchart which shows the further another example of a procedure of the client side proxy which concerns on the same embodiment The flowchart which shows the further another example of a procedure of the server side proxy which concerns on the same embodiment The figure which shows the further another structural example of the proxy in the same embodiment The figure which shows the further another structural example of the computer network system which concerns on the embodiment Diagram for explaining a conventional computer network system The figure which shows the specific example of the message of the format of Fig.6 (a) The figure which shows the specific example of the message of the format of FIG.6 (b). The figure which shows the specific example of the message of the format of FIG. The figure which shows the specific example of the message of the format of Fig.8 (a) The figure which shows the specific example of the message of the format of FIG.8 (b) The figure which shows the specific example of the message of the format of Fig.9 (a) The figure which shows the specific example of the message of the format of FIG.9 (b) The figure which shows the specific example of the message of the format of FIG.

Explanation of symbols

  2 ... ASP server center, 4 ... user office, 12 ... ASP server center LAN, 14 ... WAN, 16 ... user office LAN, 20 ... server device, 30 ... server side proxy device, 40 ... client side proxy device, 50 ... Client device 31,41 ... Receiving unit 32,42 ... Processing unit 33,43 ... Sending unit 34,44 ... Fingerprint cache 35,45 ... URL / FP table 321,421 ... FP compression determination unit , 322, 422... Fingerprint cache management unit, 323... FP compression processing unit, 423... FP decompression processing unit, 324, 424... URL cache processing unit, 325, 425.

Claims (14)

URLs of requested data transmitted from each of a plurality of client devices to a plurality of server devices and relayed to a client-side proxy device in charge of proxying access to each of the plurality of server devices. A plurality of request messages are received and transferred to the server device that is the destination of the request message among the plurality of servers, and a reply message transmitted from the server device to the client device as a reply to the request message A server-side proxy device that forwards to a client-side proxy device that is a proxy for the client device that is the reply message destination;
A reply message, which is a response to a request message transferred from the client side proxy device, is received from the server device, and further, a request transferred from one of the plurality of client side proxy devices. A receiving means for receiving a reply message which is a reply to the message;
Fingerprint generating means for generating a fingerprint of data mounted on the message body of the reply message, and further generating a fingerprint which is a fingerprint of the data mounted on the message body of the reply message;
Holding means for holding the generated fingerprint as a fingerprint cache in association with the data that was the source of the fingerprint and the URL of the data;
Determining means for determining whether the fingerprint is held in the fingerprint cache;
When the determination means determines that the fingerprint is held in the fingerprint cache, the fingerprint is sent to the client-side proxy device as the client device instead of the data. When the determination means determines that the fingerprint is not held in the fingerprint cache, the fingerprint is associated with the data and added to the fingerprint cache, and the reply message is added. First transmitting means for transmitting to the client-side proxy device as addressed to the client device;
When the URL of the requested data included in the request message transferred from the client side proxy device is held in the fingerprint cache, the data held in the fingerprint cache in association with the URL A server-side proxy device, comprising: a second transmission unit configured to transmit a reply message including a message body to the client-side proxy device as addressed to the client device.   The first transmission means sends the reply data to the client apparatus together with the fingerprint when the determination means determines that the fingerprint is not held in the fingerprint cache. The server-side proxy device according to claim 1, wherein the server-side proxy device transmits to the client-side proxy device.   The first transmission means, when the determination means determines that the fingerprint is not held in the fingerprint cache, and when the reply data is not Null, 2. The server-side proxy device according to claim 1, wherein the server-side proxy device is associated with certain reply data, added to the fingerprint cache, and transmitted to the certain client-side proxy device as the certain client device. .   The server-side proxy device according to claim 1, wherein the receiving means is connected to the server device via a local area network.   5. The server-side proxy device according to claim 1, wherein the request message is a request message of a GET method. 6. A server that receives a plurality of request messages each including a URL of requested data transmitted from each of a plurality of client devices to a plurality of server devices, and takes charge of access to the server device that is the destination of the request message The client side that forwards the reply message sent to the client device from the server device via the server side proxy device as a reply to the request message to the client device that is the destination of the reply message. A proxy device,
A reply message that is a response to the request message transmitted from the client device and a fingerprint of data mounted in a message body of the reply message are received from the server-side proxy device, and the plurality of client devices Receiving means for receiving from the server-side proxy device also a fingerprint generated from some data mounted in a message body of a reply message, which is a reply to a request message transmitted from a client device,
Holding means for holding the fingerprint as a fingerprint cache in association with the data received together with the fingerprint and the URL of the data;
Determining means for determining whether the fingerprint is held in the fingerprint cache;
When the determination unit determines that the fingerprint is held in the fingerprint cache, a reply message in which data associated with the fingerprint is loaded in a message body is transmitted to the client device. When the determination means determines that the fingerprint is not held in the fingerprint cache, the fingerprint is associated with the data loaded in the message body of the reply message in the fingerprint cache. First transmitting means for adding and transmitting the reply message to the client device;
When the URL of the requested data included in the request message transmitted from the client device is held in the fingerprint cache, the data held in the fingerprint cache in association with the URL is messaged A client-side proxy device, comprising: a second transmission unit that transmits a reply message mounted on a body to the client device. A fingerprint generating unit that generates a fingerprint of reply data that is a response to the request data transmitted from the client device and is received from the server device via the server-side proxy device;
The client side proxy device according to claim 6, wherein the holding unit holds the fingerprint and the reply data in association with each other as a fingerprint cache.   The first transmission means, when the determination means determines that the fingerprint is not held in the fingerprint cache, and when the reply data is not Null, 7. The client side proxy device according to claim 6, wherein the reply data is added to the fingerprint cache in association with the reply data, and the reply data is transmitted to the client device.   7. The client side proxy device according to claim 6, wherein the first transmission unit and the second transmission unit are connected to the client device via a local area network.   10. The client side proxy device according to claim 6, wherein the request message is a request message of a GET method. URLs of requested data transmitted from each of a plurality of client devices to a plurality of server devices and relayed to a client-side proxy device in charge of proxying access to each of the plurality of server devices. A plurality of request messages are received and transferred to the server device that is the destination of the request message among the plurality of servers, and a reply message transmitted from the server device to the client device as a reply to the request message A server-side proxy device data transfer method for transferring to a client-side proxy device that is a proxy for a client device that is a reply message destination,
A reply message that is a response to the request message transferred from the client side proxy device is received from the server device;
Generating a fingerprint of the data mounted in the message body of the reply message;
The generated fingerprint is stored as a fingerprint cache in association with the data that was the source of the fingerprint and the URL of the data,
Receiving a reply message that is a reply to a request message transferred from a client-side proxy device among the plurality of client-side proxy devices;
Generating a fingerprint that is a fingerprint of some data carried in the message body of the reply message;
Determining whether the fingerprint is held in the fingerprint cache;
If it is determined in the determination that the fingerprint is held in the fingerprint cache, the fingerprint is sent to the client device instead of the data to the client-side proxy device. Send
When the determination determines that the fingerprint is not held in the fingerprint cache, the fingerprint is associated with the data and added to the fingerprint cache, and the reply message is added. To the client-side proxy device as addressed to the client device,
When the URL of the requested data included in the request message transferred from the client side proxy device is held in the fingerprint cache, the data held in the fingerprint cache in association with the URL A data transfer method characterized by transmitting a reply message having a message body mounted to the client side proxy device to the client device. A server that receives a plurality of request messages each including a URL of requested data transmitted from each of a plurality of client devices to a plurality of server devices, and takes charge of access to the server device that is the destination of the request message The client side that forwards the reply message sent to the client device from the server device via the server side proxy device as a reply to the request message to the client device that is the destination of the reply message. A proxy device data transfer method comprising:
Receiving from the server-side proxy device a reply message that is a reply to the request message sent from the client device and a fingerprint of the data mounted in the message body of the reply message;
Holding the fingerprint as a fingerprint cache in association with the data received with the fingerprint and the URL of the data;
The server-side proxy device receives a fingerprint generated from data or a data mounted in a message body of a reply message, which is a response to a request message transmitted from a client device of the plurality of client devices. And
Determining whether the fingerprint is held in the fingerprint cache;
If it is determined in the determination that the fingerprint is held in the fingerprint cache, a reply message in which data associated with the fingerprint is loaded in a message body is transmitted to the client device. And
If it is determined in the determination that the fingerprint is not held in the fingerprint cache, the fingerprint is associated with the data loaded in the message body of the reply message. Add to the cache and send the reply message to the client device;
When the URL of the requested data included in the request message transmitted from the client device is held in the fingerprint cache, the data held in the fingerprint cache in association with the URL is messaged A data transfer method, comprising: transmitting a reply message mounted on a body to the client device. URLs of requested data transmitted from each of a plurality of client devices to a plurality of server devices and relayed to a client-side proxy device in charge of proxying access to each of the plurality of server devices. A plurality of request messages are received and transferred to the server device that is the destination of the request message among the plurality of servers, and a reply message transmitted from the server device to the client device as a reply to the request message A program for causing a computer to function as a server-side proxy device that transfers to a client-side proxy device that is a proxy for a client device that is a destination of a reply message,
A reply message, which is a response to a request message transferred from the client side proxy device, is received from the server device, and further, a request transferred from one of the plurality of client side proxy devices. A receiving function for receiving a reply message or a reply message;
A fingerprint generation function for generating a fingerprint of data mounted on the message body of the reply message, and further generating a fingerprint that is a fingerprint of the data mounted on the message body of the reply message;
A holding function for holding the generated fingerprint as a fingerprint cache in association with the data that was the source of the fingerprint and the URL of the data;
A determination function for determining whether the fingerprint is held in the fingerprint cache;
When the determination function determines that the fingerprint is held in the fingerprint cache, the fingerprint is sent to the client-side proxy device as the client device instead of the data. When the determination function determines that the fingerprint is not held in the fingerprint cache, the fingerprint is associated with the data and added to the fingerprint cache and the reply message is added. A first transmission function for transmitting to the client-side proxy device as addressed to the client device;
When the URL of the requested data included in the request message transferred from the client side proxy device is held in the fingerprint cache, the data held in the fingerprint cache in association with the URL A program for causing a computer to realize a second transmission function for transmitting a reply message having a message body addressed to the client side proxy device to the client device. A server that receives a plurality of request messages each including a URL of requested data transmitted from each of a plurality of client devices to a plurality of server devices, and takes charge of access to the server device that is the destination of the request message The client side that forwards the reply message sent to the client device from the server device via the server side proxy device as a reply to the request message to the client device that is the destination of the reply message. A program for causing a computer to function as a proxy device,
A reply message that is a response to the request message transmitted from the client device and a fingerprint of data mounted in a message body of the reply message are received from the server-side proxy device, and the plurality of client devices A receiving function for receiving from the server-side proxy device also a fingerprint generated from some data mounted in a message body of a reply message, which is a reply to a request message transmitted from a client device,
A holding function for holding the fingerprint as a fingerprint cache in association with the data received together with the fingerprint and the URL of the data;
A determination function for determining whether the fingerprint is held in the fingerprint cache;
When the determination function determines that the fingerprint is held in the fingerprint cache, a reply message having data associated with the fingerprint printed in a message body is transmitted to the client device, When the determination function determines that the fingerprint is not held in the fingerprint cache, the fingerprint is associated with the data loaded in the message body of the reply message in the fingerprint cache. A first transmission function for adding and transmitting the reply message to the client device;
When the URL of the requested data included in the request message transmitted from the client device is held in the fingerprint cache, the data held in the fingerprint cache in association with the URL is messaged A program for causing a computer to realize a second transmission function for transmitting a reply message mounted on a body to the client device.

Images