Patent Application
20110238975
This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2010-068719, filed on Mar. 24, 2010, the entire contents of which are incorporated herein by reference.
The embodiment described below relates to the technology of a user of a terminal device over a communication network.
Presently, a communication network represented by the Internet has become widespread in the world, and various services for a user, as a client, of a terminal device connected to the communication network have been provided using a server.
The server for providing a service generates a session according to a message received from the terminal device, and provides the service for the user of the terminal device. The session corresponds to a unit of providing the service from the server to one terminal device. The server which has generated the session inserts a session ID as an identifier for identification of the generated session into a message as a response to the terminal device, and transmits the message to the terminal device. After the terminal device has received the message into which the session ID is inserted, it transmits a message into which the session ID is inserted to the server. Thus, the server can continue providing services based on the session ID in the message received from the terminal device.
Normally, it is anticipated that a large number of users use a service provided over a communication network. The more users use the service, the heavier the load of the server becomes. Therefore, the provider normally adopts the system configuration for performing load balancing in which a plurality of servers are prepared, and one of the servers is allocated as a server for providing a service for a user of a terminal device. A relay device for relaying data for the load balancing is normally referred to as an SLB (server load balancer).
The relay device stores the information about the relationship between the session ID and the server holding the session to which the session ID is assigned. Thus, when the relay device receives a message into which the session ID is inserted, it confirms whether or not it stores the information having the session ID, and determines a server to which a message is to be allocated depending on the confirmation result. The determined server to which the message is to be allocated is specified if the information having the session ID is stored. If the information having the session ID is not stored, a server is selected by an autonomous allocation algorithm such as a round robin algorithm etc. Thus, by determining a server to which a message is to be allocated, the relay device realizes a uniqueness guarantee by which a related message transmitted from the same terminal device is allocated to the same server. The function of realizing the uniqueness guarantee is referred to as a uniqueness guarantee function (or a session maintaining function). The information for use in realizing the uniqueness guarantee is hereinafter referred to as “uniqueness guarantee information”.
Recently, the concealment of a message is desired to protect against the leak of information related to privacy. The security of the concealment is normally realized by encrypting data. As the communication protocol for encrypting and communicating data, an SSL (secure socket layer) is widely used.
A message transferred over a communication network is basically configured by “header+payload”. A header includes necessary information for transfer of a message (packet), and a payload includes information to be practically transferred. In an HTTP message using the HTTP, an IP header (Internet protocol) and a TCP (transmission control protocol) header are stored as headers as illustrated in
An IP header stores a source IP address indicating the source of a message, and a destination IP address indicating the destination of the message. A TCP header stores a source port number indicating the subaddress of the source IP address, and a destination port number indicating the subaddress of the destination IP address.
The location in a message in which a session ID is stored is normally defined for each communication protocol. In the HTTP message, the location in which the session ID is stored is a cookie field of the HTTP header. Therefore, when a relay device receives an HTTP message from a terminal device, it confirms the data of the cookie field of the HTTP header, and determines the server for transferring the HTTP message.
As illustrated in
In the communication of a message using the SSL, an SSL session ID as an identification number is assigned by the establishment of the communication (session) using the SSL. It is not desired that the SSL session ID is used in realizing the uniqueness guarantee because the SSL session is established independently of the session of a server. That is, it is not guaranteed that an SSL session is necessarily maintained while the session of a server is maintained. Therefore, conventionally the uniqueness guarantee is realized by decoding a payload.
The load of a relay device increases by decoding the payload of a received HTTP message. The increase of the load incurs disadvantages such as the degradation of the quality of a service with a longer time taken to transfer a message, an increasing number of required relay devices, etc. Accordingly, it is important to suppress the growth of a load in a relay device.
In a system according to the present invention, an information processing device confirms the presence/absence of session data received from a server, the information processing device generates connection data when there is session data, the information processing device extracts session data and connection data at a route control device, the route control device extracts a server address of a server based on the received session data, the route control device transmits the connection data and the server address to a relay device, the information processing device encrypts transmission data and session data to be transmitted to the server thereby generating encryption data when the information processing device receives a notification of the completion of the relay setting of the relay device from the route control device, the information processing device transmits a message including a connection data and encryption data to the relay device, the relay device extracts a server address based on the connection data in the received message, and the relay device transmits the message to the extracted server address.
When the aspect of the embodiment is applied, the uniqueness guarantee can be realized without decrypting the payload of a message during a relaying process.
The object and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the claims.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, as claimed
The embodiments of the present invention are described below in detail with reference to the attached drawings.
Each server 3 provides a service for a user of the terminal device 1 as a client by executing a server application 31 which is an application program. The relay device 2 relays a message between the terminal device 1 and the server 3. When a message 101 is received from the terminal device 1, the server 3 to which the message 101 is to be transferred is determined, and the message 101 is transferred to the determined server 3.
Each server 3 generates a session by receiving the message 101 from the terminal device 1 through the relay device 2. In this case, the server 3 assigns to the generated session a session ID as an identifier for identification of the session. The session ID is inserted into a message 302. When the terminal device 1 continuously uses the service, it transmits the message 101 into which the session ID is inserted. Thus, the server 3 confirms whether or not the session ID is included in the message 101 received from the terminal device 1, and generates a session when the session ID is not included. Hereafter, just for convenience, the message 101 including no session ID, that is, the message which triggers the generation of a session, is referred to as a “initial message” and assigned a reference numeral of 101a. The message 101 including the session ID is assigned a reference numeral of 101b. The message 101 refers to the initial message 101a or the message 101b. A message for which it is not necessary to designate a source is assigned no reference numeral.
The terminal device 1 is a computer (information processing device having a communication function such as a mobile telephone, a PDA, a personal computer (PC), etc. The terminal device 1 stores a client application 12 as a program which enables a service provided by the server 3 to be used. The user of the terminal device 1 can use the service provided by the server 3 by executing the client application 12.
The server 3 and the terminal device 1 transmits a message after encrypting the payload of the message to guarantee the concealment of the message. The identifier of a session such as a session ID etc. is normally stores in the payload. Therefore, the relay device 2 cannot confirm the session ID without decoding the payload of a received message. If the session ID cannot be confirmed, the uniqueness guarantee for the transfer of the message 101b to the server 3 cannot be realized. However, the decoding process increases the load of the relay device 2. Thus, the present embodiment realizes the uniqueness guarantee without directing the relay device 2 to perform the decoding process.
The route control device 4 provides the relay device 2 with the information which realizes the uniqueness guarantee (expressed by “relay setting information”) without decoding a payload. The relay setting information is generated using the information provided from the server 3 and the terminal device 1. The system of generating the relay setting information and the system of enabling the relay using the relay setting information are concretely described below with reference to
The terminal device 1 which executes the client application 12 is provided with a client side application session information notification unit 11 and a communication unit 13. The communication unit 13 has the function of communicating a message through a LAN. The communication unit 13 encrypts and decodes the payload of the message 101.
As illustrated in
The L2 (layer 2) header is a header for transmission of data using a MAC (media access control address) address (Ethernet address) as a unique ID number of the equipment which can be connected to the Ethernet (LAN). The L2 header stores a source MAC address (Source MAC) and a destination MAC address (Destination MAC). The L3 and L4 headers are, for example, an IP header and a TCP header in the HTTP message in
The client application 12 manages a session ID table 15 storing a session ID. Each entry (record) of the session ID table 15 stores a session ID and a destination IP address. A destination IP address is associated with a session ID because the destination IP address is stored together with the session ID in the message 101. Since the message 101 is transferred to the server 3 through the relay device 2, the destination IP address is the IP address of the relay device 2.
Upon receipt of the response message 302 (transmitted to the terminal device 1 as a message 202 from the relay device 2) from the server 3, the client application 12 extracts a session ID from the message 302, and searches the session ID table 15. If an entry stored in the session ID table 15 cannot be extracted by the retrieval, one entry is added to the session ID table 15. The added entry stores the session ID and the source IP address (including the source port number in this example) in the message 302. The source IP address is stored as a destination IP address.
When transmitting the message 101, the client application 12 searches the session ID table 15 using the destination IP address (including the port number in this example) of the message 101 as a key, thereby confirming whether or not there is an entry storing the destination IP address. If it is confirmed that a corresponding entry exists, the session ID of the entry, it is reported together with the destination IP address, and the source IP address (including the port number in this example) to the client side application session information notification unit 11. The corresponding entry exists only when the message 101b is transmitted.
The client side application session information notification unit 11 notifies the route control device 4 of the session ID, the source IP address and port number, and the destination IP address and port number reported from the client application 12 as session information. The source IP address and port number and the destination IP address and port number are reported together with the session ID because the data can be used for identification of the connection (correspondence) for which the uniqueness guarantee is to be realized. Therefore, the combination of a source IP address and port number and a destination IP address and port number is hereinafter referred to as a “connection ID”. In the present embodiment, the IP address and port number of the terminal device 1 is used as a source IP address and port number, and the URL of the server application 31 expressed by the Host and Request-URL field is used as a destination IP address and port number.
The message 101 can be transmitted using a communication protocol other than the TCP. The communication protocol can be, for example, a UDP (user datagram protocol). Thus, in
The client application 12 manages the session ID table 15 storing a session ID. Each entry (record) of the session ID table 15 stores the session ID and the destination IP address as illustrated in
The relay device 2 changes the source MAC address of the L2 header of the message 101 received from the terminal device 1 into its own MAC address, and changes the destination MAC address into the MAC address of the server 3. It also changes the destination IP address and port number of the L3 and L4 headers into the IP address and port number of the server 3. A message 201 generated by performing the above-mentioned changes is transmitted. In this case, the server 3 which stores the destination IP address and port number in the L3 and L4 headers is selected by the autonomous allocation algorithm such as the round robin algorithm etc. if the received message 101 is the initial message 101a. If it is not the initial message 101a, the server 3 has an established session. The method of determining the server 3 having an established session is described later in detail.
Upon receipt of the message 201 from the relay device 2, the server 3 decodes the payload of the message 201, and transmits the result to the server application 31. The server application 31 confirms whether or not there is a session ID in the payload, newly establishes a session if there is no session ID, and assigns a session ID to the session. It also generates and stores necessary information for providing a continued service.
In the present embodiment, a session table 35 is used in storing a session ID and information. Each entry (record) of the session table 35 stores necessary information (hereinafter referred to as “session-related information”) in providing a session ID and a service (performing a process by the server application 31). When the server 3 receives the message 201b without a session ID, the server application 31 updates the corresponding session-related information as necessary.
The server application 31 generates the message 302 storing the data requested by the received message 201 and the session ID in the payload, and transmits the message to the relay device 2.
Upon receipt of the message 302 from the server 3, the route control device 4 changes the source MAC address of the L2 header into its own MAC address, and changes the destination MAC address into the MAC address of the terminal device 1. It also changes the source IP address and port number of the L3 and L4 headers into its own IP address and port number. By performing the changes, it generates the message 202 as illustrated in
When the server application 31 newly generates a session, a server side application session information notification unit 32 of the server 3 notifies the route control device 4 of the session ID and the IP address and port number of the server 3 from which the service of the server application 31 is available (hereinafter expressed by a “server IP address”). The notification is performed by generating and transmitting a message 301 as illustrated in
The route control device 4 includes a server side application session information collection unit 41, a client side application session information collection unit 42, a relay setting generation unit 43, and a setting unit 44. The message 301 received from the server 3 is processed by the server side application session information collection unit 41, and the session information stored in the message 301 is extracted. Similarly, the message 102 received from the terminal device is processed by the client side application session information collection unit 42, and the session information stored in the message 102 is extracted. The session information extracted by the server side application session information collection unit 41 and the client size application session information collection unit 42 is output to the relay setting generation unit 43.
The relay setting generation unit 43 specifies the correspondence of the session information collected by the session information collection units 41 and 42 by the session ID. Thus, the server IP address and the connection ID assigned the same session ID are associated with each other. The relay setting information is generated by associating a server IP address with a connection ID. The generated relay setting information is output to the setting unit 44.
The relay setting generation unit 43 manages the generation of the relay setting information using a setting management table 45. Each entry (record) of the setting management table 45 can store a session ID in addition to the associated server IP address and connection ID as illustrated in
When the setting unit 44 receives the relay setting information from the relay setting generation unit 43, it generates a message 401 for notifying the relay device 2 of the relay setting information, and transmits the message to the relay device 2. The message 401 is configured as illustrated in
The message 401 transmitted from the route control device 4 is processed by a setting acceptance unit 24 of the relay device 2. The setting acceptance unit 24 extracts the relay setting information from the message 401, and stores the extracted relay setting information in a relay setting table 25.
Each entry of the relay setting table 25 stores the relay setting information, that is, a connection ID and a server IP address as illustrated in
In addition to the setting acceptance unit 24, the relay device 2 includes a relay unit 21, a load balancing unit 22, and a relay setting record unit 23. These units 21 through 23 perform the following operations.
The relay unit 21 refers to the relay setting table 25 and realizes the relay of a message between the terminal device 1 and the server 3. When the message 101 is received from the terminal device 1, the source and destination IP addresses and port numbers are extracted from the L3 and L4 headers, and the relay setting table 25 is searched using as a key the combination of the extracted IP addresses and port numbers. If an entry storing the combination as a connection ID is extracted by the search, that is, the message 101 is the message 101b, the destination IP address and port number of the L3 and L4 headers are changed into the server IP address of the entry. The source and destination MAC addresses of the L2 header of the message 101b are respectively changed into the MAC address of its own, and the MAC address of the server 3 having the server IP address. By these changes, the message 201b is generated, and the message is transmitted to the server 3. If no entry is extracted, the message 101 is regarded as the initial message 101a, and is output to the load balancing unit 22.
The load balancing unit 22 selects the server 3 as a destination of the initial message 101a by the autonomous allocation algorithm, and stores the IP address and port number of the selected server 3 as the destination IP address and port number of the L3 and L4 headers, thereby generating the message 201a. The source MAC address of the L2 header is changed into the MAC address of its own, and the destination MAC address is changed into the MAC address of the selected server 3. The generated message 201a is transmitted to the server 3, and the relay setting record unit 23 is notified of the source and destination IP addresses and port numbers of the L3 and L4 headers of the initial message 101a, and the IP address and port number of the selected server 3.
The relay setting record unit 23 stores in the relay setting table 25 the source and destination IP address and port number reported by the load balancing unit 22 as a connection ID, and the IP address and port number of the server 3 as a server IP address. When the initial message 101a is received from the terminal device 1 as described above, the IP addresses and port numbers are reported from the load balancing unit 22. Thus, the relay setting record unit 23 adds one entry to the relay setting table 25, and the IP addresses and port numbers are stored as the relay setting information in the added entry.
Upon receipt of the message 302 from the server 3, the relay unit 21 rewrites the address and generate the message 202 as in the case when the message 101b is received. The source IP address and port number of the L3 and L4 headers of the message 302 are changed into its own IP address and port number, and the source and destination MAC addresses of the L2 header are respectively changed into their own MAC addresses and the MAC address of the terminal device 1. By these changes, the message 202 is generated and transmitted to the terminal device 1.
The terminal device 1, the relay device 2, the server 3, and the route control device 4 are operated by directing a computer to execute a dedicated program. The terminal device 1 is realized by directing the computer to execute the client application 12. The server 3 is realized by directing the computer to execute the server application 31. The relay device 2 is realized by executing a program for enabling the relay of a message (hereinafter referred to as a “relay program”), and the route control device 4 is realized by executing a program for setting the relay setting information in the relay device 2 (hereinafter referred to as a “route control program”). With reference to
The computer illustrated in
The CPU 61 controls the entire computer.
The memory 62 is semiconductor memory such as RAM etc. for temporarily storing a program or data stored in the external storage device 65 (or a portable record medium 70) when a program is executed and data is updated, etc. The CPU 61 reads the program to the memory 62 and executes the program, thereby controlling the entire processing.
The input device 63 enables data to be input through an operation device such as a keyboard, a mouse, etc. It can be an interface connectable to an operation device or includes an operation device and an interface. The operation of a user on an operation device is detected, and the detection result is reported to the CPU 61. The operation device can be a console etc.
The output device 64 is, for example, a display device, or a display control device connected to a display device. The external storage device 65 is, for example, a hard disk device, and is mainly used for storing various data and programs.
The medium drive device 66 is to access an optical disk, an magneto optical disk, or a portable record medium 70 such as a memory card etc. The network connection device 67 is to communicate with an external device over a communication network.
The dedicated program is recorded on the external storage device 65 or the portable record medium 70, or acquired by the network connection device 67 over a communication network. When it is assumed that the dedicated program is stored in the external storage device 65, each component of the terminal device 1, the relay device 2, the server 3, and the route control device 4 is realized by a combination of components of the computer as follows. The combination is read when it is assumed that the terminal device 1, the relay device 2, the server 3, and the route control device 4 are connected to the same communication network (LAN).
The client side application session information notification unit 11 of the terminal device 1 is realized by, for example, the CPU 61, the memory 62, the external storage device 65, the network connection device 67, and the bus 68. The session ID table 15 is stored in, for example, the external storage device 65, and is read to the memory 62 as necessary, and referenced or updated.
The relay unit 21, the load balancing unit 22, and the setting acceptance unit 24 of the relay device 2 are realized by, for example, the CPU 61, the memory 62, the external storage device 65, the network connection device 67, and the bus 68. The relay setting record unit 23 is realized by, for example, the CPU 61, the memory 62, the external storage device 65, and the bus 68. The relay setting table 25 is stored in, for example, the external storage device 65, read to the memory 62 as necessary, and referenced or updated.
The server side application session information notification unit 32 of the server 3 is realized by, for example, the CPU 61, the memory 62, the external storage device 65, the network connection device 67, and the bus 68. The session table 35 is stored in, for example, the external storage device 65, read to the memory 62 as necessary, and referenced or updated.
The server side application session information collection unit 41, the client side application session information collection unit 42, and the setting unit 44 of the route control device 4 are realized by, for example, the CPU 61, the memory 62, the external storage device 65, the network connection device 67, and the bus 68. When the communication network for connecting the route control device 4 to the terminal device 1 is different from the communication network for connecting the route control device 4, the relay device 2, and the server 3, the necessary connection devices for realizing the session information collection units 41 and 42 are different from one another. To be practical, the client side application session information collection unit 42 is realized using a necessary connection device 68 instead of the network connection device 67.
The relay setting generation unit 43 is realized by, for example, the CPU 61, the memory 62, the external storage device 65, and the bus 68. The setting management table 45 is stored in, for example, the external storage device 65, read to the memory 62 as necessary, and referenced or updated.
The client application 12 as the dedicated program of the terminal device 1 realizes a request transmitting process F11 for transmitting the message 101 as any request. To process the message (message 202) transmitted as a response to the message 101, a client application 12 is realized.
The relay program as a dedicated program of the relay device 2 realizes a setting accepting process F21, a primary signal requesting process F22 and a primary signal response process F23. The setting accepting process F21 is performed to register the relay setting information transmitted from the route control device 4 in the relay setting table 25. The setting acceptance unit 24 is realized by performing the setting accepting process F21. The primary signal requesting process F22 is to process the message 101 received from the terminal device 1. A part of the relay unit 21, the load balancing unit 22, and the relay setting record unit 23 are realized by performing the primary signal requesting process F22. The primary signal response process F23 is performed to process the message 302 transmitted as a response from the relay device 2. The remaining part of the relay unit 21 is realized by performing the primary signal response process F23.
The server application 31 as a dedicated program of the server 3 realizes server processing F31 for processing the message 201 transferred from the terminal device 1 through the relay device 2.
The route control program as a dedicated program of the route control device 4 realizes a server side session information collecting process F41 and a client side session information collecting process F42. The server side session information collecting process F41 is performed for processing the message 301 transmitted from the server 3. The client side session information collecting process F42 is performed for processing the message 102 transmitted from the terminal device 1 and setting the relay setting information in the relay device 2. The server side application session information collection unit 41 is realized by performing the server side session information collecting process F41. The client side application session information collection unit 42, the relay setting generation unit 43, and the setting unit 44 are realized by performing the client side session information collecting process F42.
Each process in
Described first in detail are the request transmitting process F11 and the response acquiring process F12 performed by the terminal device 1 using the client application 12.
First, in step S111, the client application 12 searches the session ID table 15 (
In step S113, the client application 12 determines the connection for transmitting a message (request). When the connection is determined, the URL specified by the user as a destination IP address and port number, the IP address preset in the terminal device 1 as a source IP address is selected, and one available port number is selected as a source port number. In the next step S114, the client application 12 passes the determined source IP address and port number, destination IP address and port number, and session ID as session information to the client side session information notifying process as an argument. In the next step S115, the client application 12 performs the notifying process.
The notifying process is to notify the route control device 4 of the session information. The generation of the message 102 illustrated in
In step S117 to which control is passed as a result of the determination in step S112, the client application 12 determines the connection for transmitting a message as in step S113. In the next step S118, the client application 12 establishes a connection with the relay device 2, and generates and transmits the message 101 by encrypting the payload. Then, it terminates the request transmitting process.
First in step S121, the client application 12 receives the message 202 received by the terminal device 1. In the next step S122, the client application 12 decodes the payload of the message 202, and confirms whether or not a session ID is stored in the HTTP header. When it is confirmed that no session ID is stored in the HTTP header, it is determined, thereby terminating the response acquiring process. On the other hand, when it is confirmed that a session ID is stored in the HTTP header, it is determined, and control is passed to step S123.
In step S123, the client application 12 extracts the session ID of the HTTP header, and the source IP address and port number (expressed by the “URL” in
In the terminal device 1, the above-mentioned request transmitting process F11 and response acquiring process F12 are performed by the client application 12. When a service provided by the server 3 is used, the session information is reported to the route control device 4 by updating the session ID table 15 and generating and transmitting the message 102.
Next, the server processing F31 by the server 3 is described below in detail.
First in step S311, the server application 31 receives the message 201 received by the server 3. In the next step S312, the server application 31 decodes the payload of the message 201. In the next step S313, the server application 31 confirms whether or not a session ID has been extracted from the cookie field of the HTTP header. If no session ID is extracted from the HTTP header, then it is determined, and control is passed to step S318. On the other hand, if a session ID can be extracted from the HTTP header, it is determined and control is passed to step S314.
In step S314, the server application 31 searches the session table 35 (
The message 302 is generated by exchanging the source and the destination of the L2 through L3 headers of the received message 201, and storing the session ID in the Set-cookie field (refer to
In step S318 to which control is passed when it is determined in step S313 that no session ID can be extracted, the server application 31 generates session-related information and a session ID, and registers the data in the session table 35. The registering process is performed by adding one entry and storing the data in the added entry. In the next step S319, the server application 31 passes control to the server side session information notifying process (subprogram) as a subroutine process.
The subprogram acquires the IP address of the server 3 when control is passed from the server application 31, and notifies the route control device 4 of the address and the session ID. The notification is realized by generating the message 301 as illustrated in
Described below in detail are the server side session information collecting process F41 and the client side session information collecting process F42 executed by the route control device 4 using the route control program.
First in step S411, the route control program collects from the payload of the received message 301 (
The registration of the session information is practically performed by searching the setting management table 45 using the session ID of the session information as a key, and confirming whether or not there is an entry extracted by the search. If an entry can be extracted, the entry is stored in the session information. If no entry is extracted, one entry is added, and the session information is stored in the added entry.
First in step S421, the route control program collects the session information, that is, the session ID and the connection ID from the payload of the received message 102 (
In step S423, the route control program generates relay setting information by combining the acquired IP address and connection ID. In the next step S424, the route control program generates the message 401 (
Thus, the setting completion notification to the terminal device 1 is transmitted after setting the relay setting information in the server 3. Therefore, the message 101b transmitted from the terminal device 1 after the reception of the setting completion notification is transferred to the server 3 to which the message is to be transferred by the relay device 2.
As described above, the client side session information collecting process F42 realizes the client side application session information collection unit 42, the relay setting generation unit 43, and the setting unit 44 of the route control device 4. To be more concrete, the client side application session information collection unit 42 is realized by performing the processes in steps S421 and S426. The relay setting generation unit 43 is realized by performing the processes in steps S422 and S423. The setting unit 44 is realized by performing the process in step S424.
Finally, the setting accepting process F21, the primary signal requesting process F22, and the primary signal response process F23 performed by the relay device 2 using the relay program are described below in detail.
First in step S211, the relay program acquires the message (expressed as a “relay setting distribution message” in
In step S213, the relay program overwrites the extracted entry with the IP address of the relay setting information. On the other hand, in step S214, the relay program adds one entry, and stores the relay setting information in the added entry, that is, stores the connection ID as a key and the IP address of the server 3 combined with the connection ID. After updating the relay setting table 25 by performing the process in step S213 or S214, control is passed to step S215, and the relay program returns to the route control device 4 a setting completion notification as a message reporting the completion of the settings of the relay setting information. After returning the notification, the setting accepting process is terminated.
First in step S221, the relay program waits for the reception of the message 101 from the terminal device 1. Upon receipt of the message 101, control is passed to step S222, and the relay program extracts the connection ID, that is, the source IP address and port number and the destination IP address and port number, from the L3 and L4 headers of the received message 101. After the extraction, control is passed to step S223.
In step S223, the relay program searches the relay setting table 25 using the extracted connection ID as a key, and determines the search result. If an entry storing the connection ID cannot be extracted as a result of the search, it is determined as “not hit”, and control is passed to step S226. On the other hand, if such an entry can be extracted, it is determined as “hit”, and control is passed to step S224.
In step S224, the relay program writes the destination server address (IP address and port number) of the extracted entry as the destination IP address and port number of the L3 and L4 headers of the received message 101, thereby generating the message 201. In the next step S225, the relay program transmits the generated message 201 to the server 3. Then, the primary signal requesting process F22 is terminated.
The message 201 generated in step S224 has the MAC address of the relay device 2 as a source MAC address of the L2 header, and the MAC address of the server 3 to which the message is transferred as a destination MAC address as illustrated in (b) in
In step S226 to which control is passed when it is determined as “not hit” in step S223, the server 3 to which the message 101 (101a) is transferred according to the load balancing algorithm is selected. In the next step S227, the relay program adds one entry to the relay setting table 25, and records the connection ID and the IP address of the selected server 3 in the added entry as the relay setting information. Then, control is passed to step S224.
As described above, a part of the relay unit 21, the load balancing unit 22, and the relay setting record unit 23 of the relay device 2 are realized by performing the primary signal requesting process F22. To be more concrete, a part of the relay unit 21 is realized by performing the processes in steps S221 through S225. The load balancing unit 22 is realized by performing the processes insteps S226, S224, and S225. The relay setting record unit 23 is realized by performing the process in step S227.
First in step S231, the relay program waits for the reception of the message 302 from the server 3. Upon receipt of the message 302, control is passed to step S232, an the relay program generates the message 302 (
In generating the message 202, the MAC addresses of the relay device 2 and the terminal device 1 are stored respectively as the source and destination MAC addresses L of the L2 header of the received message 302. The source IP address and port number of the L3 and L4 headers is changed into the IP address and port number of the relay device 2. Thus, the message 202 is generated from the message 302.
It is preferable that the session ID is unknown to the third party because the third party who knows the session ID can pretend to be a user of the terminal device 1 as a holder of the session ID. Thus, when the session information including the session ID is reported to the route control device 4 by the message 102, it is necessary to guarantee the concealment of the message 102. Therefore, the second embodiment has been devised to guarantee the concealment of the message 102.
To guarantee the concealment of the message 102, the second embodiment is different in the following points from the first embodiment. The different points are described concretely below with reference to
The client side application session information notification unit 11 of the terminal device 1 according to the second embodiment includes an application session ID encryption unit 11a as illustrated in
The message 102 transmitted from the terminal device is processed by the client side application session information collection unit 42 of the route control device 4. The client side application session information collection unit 42 acquires the session information by decoding the session information of the received message 102, and passes the acquired session information to the relay setting generation unit 43. Thus, the relay setting generation unit 43 generates relay setting information and passes it to the setting unit 44 as in the first embodiment. The session information is decoded in the client side session information collecting process F42 whose flowchart is illustrated in
In the second embodiment, the terminal device 1 transmits the message 102 obtained by encrypting the session information, and the route control device 4 decodes the session information of the message 102 and sets the relay setting information in the relay device 2. Therefore, the leak of the session information can be more effectively suppressed than in the first embodiment.
As in the server 3, the server side application session information notification unit 32 is provided with an application session ID encryption unit 32a as illustrated in
In the second embodiment, the route control device decodes the session information, but it is not always necessary to decode it because when the same data is encrypted by the terminal device 1 and the server 3 under the same rules, the data after the encryption are all the same. Thus, for the session information (for example, it can be configured by a session ID only), the encrypted data can be used instead of the session information if the location of the encrypted data can be specified in advance. When the decoding process is thus avoided, the cost of decoding data can be reduced.
In the first and second embodiments, a notification of session information from the terminal device 1 to the route control device 4 is transmitted by the control of the client application 12. In the third embodiment, a notification of session information is transmitted by the control of software other than the client application 12.
In the third embodiment, only the terminal device 1 is different in the terminal device 1 from the first embodiment. Therefore, the explanation below is concentrated on the terminal device 1. The components also used in the first embodiment are assigned the same reference numerals as in the first embodiment although their operations are different. The session ID of an application is expressed by a “session ID”, and the ID of an SSL session is expressed by an “SSL session ID” for discrimination.
As illustrated in
The message 101 is transmitted after an establishment of a connection (TCP connection) to the relay device 2. The establishment of the connection is performed by transmitting a SYN packet (packet with an SYN flag) for a request of the establishment. An SSL session is established after the establishment of the connection. In the present embodiment, the hook unit 112 is directed to hook the SYN packet as a predetermined message. Thus, the substitute response and request unit 111 and the hook unit 112 control the timing of practically transmitting a message requested by the client application 12 for the transmission the message, acquire the session information, and notify the route control device 4 of the acquired session information. By controlling the timing of transmitting the requested message, the substitute response and request unit 111 are substitutes for transmitting a response to the client application 12. The operations are described below mainly on the substitute response and request unit 111 and the hook unit 112.
Before transmitting the message 101, the client application 12 requests to establish an SSL session (hereinafter referred to as an “SSL communication path”) as a provisional communication path by specifying the destination IP address and port number to which the message 101 is to be transmitted. Upon receipt of the request, the substitute response and request unit 111 generates a temporary connection ID (hereinafter referred to as a “provisional connection ID”) and a temporary SSL session ID (hereinafter referred to as a “provisional SSL session ID”), and the generated IDs are returned as a response.
The generated provisional connection ID and the provisional SSL session ID are not always used in a practical transmission. Therefore, the substitute response and request unit 111 stores the results of generating the provisional connection ID and the provisional SSL session ID in a connection ID mapping table 124 and a SSL session ID mapping table 125 respectively. The connection ID mapping table 124 is prepared to specify the correspondence between a provisional connection ID and a practical connection ID (hereinafter referred to as an “actual connection ID”). As illustrated in
After receiving a provisional connection ID and a provisional SSL session ID as a response, the client application determines that the SSL communication path has been established, and requests to transmit the message 101 using the received IDs. The message 101 stores the provisional connection ID in the L3 and L4 headers. Upon receipt of a request to transmit the message 101 from the client application 12, the substitute response and issue unit 111 extracts as provisional connection IDs the source and destination IP addresses and port numbers stored in the L3 and L4 headers of the message 101. Next, it searches the SSL session ID mapping table 125 using the extracted provisional connection IDs as keys, extracts an entry storing the provisional connection ID, and confirms whether or not an actual connection ID is stored in the entry. If no actual connection ID is confirmed, it is determined that an SSL communication path (including a TCP connection) is not practically established, and the message 101 is stored, and a request to establish an SSL communication path is issued to the communication unit 13. The message 101 is stored using a message buffer table 123. An entry of the table 123 stores the provisional connection ID, the message 101 body, or a pointer as data indicating the storage location of the message 101 as illustrated in
At the request for the SSL communication path, the communication unit 13 generates and outputs a SYN packet as a message requesting the relay device 2 to establish an SSL communication path. Thus, the substitute response and issue unit 111 directs the hook unit 112 to hook the SYN packet. On the other hand, if the actual connection ID is conformed, the substitute response and issue unit 111 passes the message 101 to the communication unit 13, and requests to transmit the message 101.
The direction to hook the SYN packet is issued by specifying the destination IP address and port number of the L3 and L4 headers of the packet. The hook unit 112 registers the destination IP address and port number specified by the substitute response and issue unit 111 in a hook target list (table) 122. Thus, upon receipt of the message from the communication unit 13, the hook unit 112 extracts the destination IP address and port number of the L3 and L4 headers of the message, and confirms whether or not the extracted destination IP address and port number has been registered in the hook target list 122. By the confirmation, a message including the destination IP address and port number registered in the hook target list 122 is hooked.
The connection ID stored as the source and destination IP addresses and port numbers in the L3 and L4 headers of the message passed from the communication unit 13 to the hook unit 112 is an actual connection ID. Therefore, when the hook unit 112 hooks a message, it extracts the connection ID of the hooked message, and notifies the client side application session information notification unit 11 of the extracted connection ID as an actual connection ID. After the notification, the hook is released, and the hooked message is transmitted.
After directing the hook unit 112 to hook the message, the substitute response and issue unit 111 acquires an actual connection ID and an actual SSL session ID from the communication unit 13 which is requested to transmit the message. The acquired actual connection ID is stored in the entry extracted from the SSL session ID mapping table 125 using the provisional connection ID as a key. The acquired actual SSL session ID is stored in the entry extracted from the SSL session ID mapping table 125 using the provisional SSL session ID specified by the client application 12 as a key. Thus, the correspondences between the provisional connection ID and the actual connection ID, and between the provisional SSL session ID and the actual SSL session ID are established.
The message passed from the client application 12 to the substitute response and issue unit 111 has not been encrypted. Under the situation, in the present embodiment, when no actual connection ID is stored in the entry extracted from the SSL session ID mapping table 125 using a provisional connection ID as a key, it is confirmed whether or not the session ID is stored in the message. Only when the session ID is stored, the substitute response and issue unit 111 directs to hook the message. The session ID is reported together with the destination IP address and port number to the client side application session information notification unit 11 before directing the hook.
As described above, after the substitute response and issue unit 111 notifies the client side application session information notification unit 11 of the session ID and the destination IP address and port number, the hook unit 112 notifies the client side application session information notification unit 11 of the actual connection ID. Upon receipt of the notification of the actual connection ID, the client side application session information notification unit 11 notifies the route control device 4 of the session information. For the notification of the session information, a session information management table 121 is managed.
When the hook unit 112 transmits a hooked message (SYN packet), a TCP connection and an SSL communication path are established with the relay device 2. The establishment is performed by the control of the communication unit 13, and the communication unit 13 notifies the substitute response and issue unit 111 of the establishment of the SSL communication path. When the notification is transmitted, an actual connection ID and an actual SSL session ID are acquired.
As described above, the substitute response and issue unit 111 and the hook unit 112 adjust the collection of the session information to be reported to the route control device 4, and the transmission timing of the message required to report the collected session information. Thus, the client application 12 which is not provided with a special function is available. Accordingly, the substitute response and issue unit 111 and the hook unit 112 realize the terminal device 1 according to the present embodiment by being loaded into a conventional terminal device.
The terminal device 1 according to the third embodiment executes, in addition to the client application 12, the program for realizing the client side application session information notification unit 11 (hereinafter referred to as a “session information notifying program”), and the program for realizing the hook unit 112 (hereinafter referred to as a “hook program”).
The communication unit 13 is realized by an OS (operating system). A program such as an application etc. can be executed based on the operation of the OS. Therefore, the OS, that is, the communication unit 13, is a program executed by the terminal device 1, and the detailed description is omitted here. The session information notifying program, the substitute response program, and the hook program are provided as, for example, middleware.
The client application 12 performs a request transmitting process F121 and the response acquiring process F12. The request transmitting process F121 is a process for transmitting the message 101 as a request. The response acquiring process F12 is a process performed on the message (message 102) transmitted as a response to the message 101, and the contents are basically the same as those according to the first embodiment (
The substitute response program realizes a communication path establish request response process F1111, a substitute request process F1112, a substitute response process F1113, and a connection delete request process F1114. The communication path establish request response process F1111 is a process corresponding to the request to establish an SSL communication path performed by the client application 12. The substitute request process F1112 is a process corresponding to the request to transmit the message 101 performed by the client application 12 after the request to establish an SSL communication path. The substitute response process F1113 is a process of transmitting to the client application 12 a message (message 202) received as a response to the transmission of the message 101. The established TCP connection is released by the disconnection procedure from the side where there is no data to be transmitted. When the release is performed, a FIN packet (a message with a FIN flag for requesting a disconnection) is transmitted. The connection delete request process F1114 is a process for receiving a FIN packet. When the message 101 is transmitted, the server 3 transmits the message 302, and the terminal device 1 normally receives the FIN packet through the relay device 2.
A session information notifying program realizes a session information storing process F111 and a session information notifying process F112. The session information storing process F111 is a process for storing the session information reported from the substitute response and issue unit 111. The session information notifying process F112 is a process for notifying the route control device 4 of the session information.
Each process illustrated in
First, the request transmitting process F121 realized by the client application 12 is described in detail with reference to the flowchart illustrated in
First in step S3301, the client application 12 generates the message 101 at an instruction of the user. In the next step S3302, the session ID table 15 (
In step S3305, the client application 12 determines whether or not the information about the SSL communication path for transmission of the message (request) 101 has been distributed. As described above, the information returned by the substitute response and issue unit 111 to the client application 12 at the request to establish an SSL communication path is a provisional connection ID and a provisional SSL session ID. Therefore, when there are valid provisional connection ID and provisional SSL session ID, the determination is YES, control is passed to step S3306, and the client application 12 transmits the generated message 101 together with the provisional SSL session ID to the substitute response and issue unit 111. Then, the request transmitting process is terminated. On the other hand, if there is no valid provisional connection ID or provisional SSL session ID, the determination is NO, and control is passed to step S3307.
In step S3307, the client application 12 requests the substitute response and issue unit 111 to establish an SSL communication path. In the next step S3308, the client application 12 waits for the response to the establish request, that is, a provisional connection ID and a provisional SSL session ID, from the substitute response and issue unit 111. After the acquisition of the response, control is passed to step S3306.
The message 101 in step S3306 and the request to establish an SSL communication path in step S3307 are transmitted to the substitute response and issue unit 111. However, the message 101 and the request to establish the path are processed by the client application 12 as if they were issued to the communication unit 13. Thus, the client application 12 has no special function for the substitute response and issue unit 111.
Described next in detail are the communication path establish request response process F1111, the substitute request process F1112, the substitute response process F1113, and the connection delete request process F1114 realized by the substitute response program.
First, in step S3401, the substitute response program acquires a destination IP address and port number from the request to establish an SSL communication path. In the next step S3402, the substitute response program generates a provisional connection ID, adds an entry to the connection ID mapping table 124, and stores the generated provisional connection ID in the entry. The provisional connection ID is the IP address of the terminal device 1 and the port number selected from the available port numbers as the source IP address and port number and the acquired destination IP address and port number. After storing the provisional connection ID, control is passed to step S3403.
In step S3403, a provisional SSL session ID is generated, and an entry storing the generated provisional SSL session ID is added to the SSL session ID mapping table 125. In the next step S3404, the generated provisional connection ID and provisional SSL session ID are returned to the client application 12 as a response. Then, the communication path establishment request response process is terminated.
First in step S3501, the substitute response program acquires a provisional connection ID from the L3 and L4 headers of the message 101 received as a request to transmit a message from the client application 12. In the next step S3502, it is determined whether or not an actual connection ID has been acquired by searching the connection ID mapping table 124 using the acquired provisional connection ID as a key. If the entry extracted by the search stores an actual connection ID, it is determined that the actual connection ID has been acquired, and control is passed to step S3503. If the extracted entry stores no actual connection ID, it is determined that an actual connection ID has not been acquired, control is passed to step S3505.
In step S3503, the substitute response program acquires an actual SSL session ID by searching the SSL session ID mapping table 125 using the provisional SSL session ID from the client application 12 as a key. In the next step S3504, the substitute response program acquires the message 101 in the request to transmit a message, and sets the message 101 as a message to be transmitted. After the setting, the substitute request process F1112 is terminated.
In step S3505 to which control is passed when it is determined in step S3502 that an actual connection ID has not been acquired, the substitute response program determines whether or not a session ID has been acquired from the message 101. If the HTTP header of the message 101 stores a session ID, it is determined that a session ID has been acquired, and control is passed to step S3506. If a session ID is not stored in the message 101, it is determined that a session ID has not been acquired, and control is passed to step S3510.
In step S3506, the substitute response program adds to the message buffer table 123 an entry storing a provisional connection ID extracted from the message 101, and the message 101, or its pointer. In the next step S3507, the substitute response program acquires the destination IP address and port number of the provisional connection ID. In the next step S3508, the substitute response program notifies the client side application session information notification unit 11 of the acquired destination IP address and port number together with the session ID, and the response is acquired. After acquiring the response, control is passed to step S3509.
In step S3509, the substitute response program performs a hook setting by notifying the hook unit 112 of the destination IP address and port number acquired in step S3507. In the next step S3510, the substitute response program passes the destination IP address and port number to the communication unit 13, and issues a request to establish an SSL communication path. In the next step S3511, the substitute response program acquires a response including an actual connection ID and an actual SSL session ID, and stores the actual connection ID and the actual SSL session ID.
The actual connection ID is stored by writing the actual connection ID in an entry storing the provisional connection ID passed from the client application 12 in the connection ID mapping table 124. The actual SSL session ID is similarly stored by writing the actual SSL session ID in an entry storing the provisional connection ID passed from the client application 12 in the SSL session ID mapping table 125.
After storing the actual connection ID and the actual SSL session ID, control is passed to step S3512. In step S3512, the substitute response program acquires the message 101 stored in step S3506. The message 101 is acquired by extracting a provisional connection ID by searching the connection ID mapping table 124 using the acquired actual connection ID as a key, and extracting the message 101 itself or a pointer by searching the message buffer table 123 using the provisional connection ID as a key. After the thus acquired message 101 is set as a message to be transmitted, the substitute request process F1112 is terminated.
As described above, the session information is reported to the route control device 4 when an actual connection ID is generated on condition that an SSL communication path is not maintained in the present embodiment because it is assumed that the time required to maintain an SSL communication path is shorter than the time required to maintain a session. That is, although an established SSL communication path is available, it is possible that a session is maintained in the server 3.
First in step S3601, the substitute response program issues a request to transmit a message to the communication unit 13. In the next step S3602, the substitute response program acquires a response from the communication unit 13. The response includes the message 202. After acquiring the response, control is passed to step S3603.
In step S3603, the substitute response program acquires a provisional connection ID by searching the connection ID mapping table 124 using the actual connection ID stored in the L3 and L4 headers as a key. In the next step S3604, the substitute response program acquires a provisional SSL session ID by searching the SSL session ID mapping table 125 using the actual SSL session ID as a key. In the next step S3605, the substitute response program returns a response to the client application 12. Then, the substitute response process F1113 is terminated.
As described above, the established TCP connection is started by transmitting a FIN packet (message with a FIN flag requesting a disconnection) from the side where there is no data to be transmitted. The side which has received the FIN packet transmits the FIN packet when there becomes no data to be transmitted, and the connection is released when the communication of the packet is completed. Since the terminal device 1 is the side which requests data, the FIN packet is a trigger for a disconnection. The connection delete request process F1114 is a process performed to receive the FIN packet. The flowchart in
First in step S3701, the substitute response program receives a request to delete a TCP connection. The reception of the delete request corresponds to acquiring a FIN packet from the communication unit 13.
After receiving the delete request, control is passed to step S3702, and the substitute response program extracts an entry by searching the connection ID mapping table 124 using the actual connection ID stored in the L3 and L4 headers of the FIN packet as a key, and deletes the entry from the table 124. In the next step S3703, the substitute response program returns the delete completion response to the communication unit 13 to notify that the actual connection has been deleted. Then, the connection delete request process F1114 is terminated.
The thus established TCP connection is released each time the communication of data between the terminal device 1 and the server 3 terminates. Therefore, regardless of whether or not the SSL communication path is maintained, the establishment of the TCP connection is performed when the message 101 is transmitted.
The TCP connection is released in a predetermined procedure. Therefore, the hook unit 112 prepares a connection management table not illustrated in the attached drawings to determine the timing of outputting the FIN packet to the substitute response and issue unit 111. The management table stores an actual connection ID and (the data indicating) the state of the connection in each entry as illustrated in
Finally, the session information storing process F111 and the session information notifying process F112 realized by the session information notifying program are described below in detail.
First, in step S3801, the session information notifying program acquires the session information notified from the substitute response program, that is, the destination IP address and port number and the session ID. In the next step S3802, the session information notifying program stores the notified session information in the session information management table 121. The information is stored by searching the session information management table 121 using, for example, a session ID as a key, extracting an entry by the search, and storing the session information in the extracted entry. If no entry is extracted, one entry is added, and the session information is stored in the added entry. Thus, after the session information is stored, the session information storing process F111 is terminated.
The hook unit 112 hooks the SYN packet specified by the substitute response program performing the process in step S3509 in
First in step S3901, the session information notifying program acquires the actual connection ID notified from the hook unit 112. In the next step S3902, the session information notifying program acquires the destination IP address and port number from the actual connection ID. In the next step S3903, the session information notifying program searches the session information management table 121 using the acquired destination IP address and port number as a key, and acquires a session ID from an entry extracted by the search. The entry stores the source IP address and port number acquired from the actual connection ID. Then, control is passed to step S3904.
In step S3904, the session information notifying program notifies the route control device 4 of the acquired actual connection ID and the session ID as session information. The notification is performed by generating and transmitting the message 102 (
In step S3906, the session information notifying program deletes the entry storing the session information reported to the route control device 4 from the session information management table 121. In step S3907, the session information notifying program returns to the hook unit 112 a response to the notification of the actual connection ID. Then, the session information notifying process F112 is terminated. After the acquisition of the response, the hook unit 112 transmits the hooked SYN packet.
In the third embodiment, a program (for example, middleware) is prepared in addition to the client application 12, and the substitute response and issue unit 111 and the hook unit 112 are prepared. The function of realizing them can be loaded into the client application 12. In this case, session information can be reported to the route control device 4 without generating a provisional connection ID and/or provisional SSL session ID. In the present embodiment (first through third embodiments), session information is reported from the terminal device 1 not only when the message 101 is transmitted, but also when the response of the initial message 101a is received. Other variations are available.
All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions, nor does the organization of such examples in the specification relate to a showing of the superiority and inferiority of the invention. Although the embodiments of the present invention have been described in detail, it should be understood that the various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2010-068719 | Mar 2010 | JP | national |
