WO2011096307A1 - プロキシ装置とその動作方法 - Google Patents

プロキシ装置とその動作方法 Download PDF

Info

Publication number
WO2011096307A1
WO2011096307A1 PCT/JP2011/051421 JP2011051421W WO2011096307A1 WO 2011096307 A1 WO2011096307 A1 WO 2011096307A1 JP 2011051421 W JP2011051421 W JP 2011051421W WO 2011096307 A1 WO2011096307 A1 WO 2011096307A1
Authority
WO
WIPO (PCT)
Prior art keywords
connection
proxy
server
mask
cpu
Prior art date
Application number
PCT/JP2011/051421
Other languages
English (en)
French (fr)
Inventor
昌治 森本
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to JP2011552737A priority Critical patent/JPWO2011096307A1/ja
Publication of WO2011096307A1 publication Critical patent/WO2011096307A1/ja
Priority to US13/200,820 priority patent/US8612611B2/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/12Protocol engines

Definitions

  • the present invention relates to a proxy device that includes a multi-core CPU and performs parallel processing.
  • the proxy device is provided between the client and the server, and relays the client side connection and the server side connection.
  • the client side connection is a connection between the client and the proxy device.
  • the server side connection is a connection between the server and the proxy device.
  • an apparatus provided with a multi-core CPU is increasing. Then, an architecture and a mounting method for operating the multi-core CPU more efficiently have been proposed.
  • parallelism is important for obtaining high scalability using a multi-core CPU.
  • synchronization processing between cores affects processing performance. Therefore, the proxy device also needs to be controlled so that synchronization between CPU cores does not occur.
  • the proxy device When the proxy device handles the two processes of the client side connection and the server side connection as two sessions, there is almost no data that should be shared between multiple sessions. Therefore, it is known that the most effective method for parallelization in such communication is a method of dividing a CPU core that performs processing for each session. Hereinafter, such a method is referred to as session distribution.
  • Patent Document 1 discloses that in a security gateway that performs NAT (Network Address Translation) processing, a dispatcher that determines the allocation of resources to be processed is the same CPU core for packets transmitted through two connections, a client side connection and a server side connection. A technique for selecting a proxy address for a server-side connection to be processed is disclosed.
  • NAT Network Address Translation
  • a proxy device that terminates a TCP (Transmission Control Protocol) connection.
  • TCP Transmission Control Protocol
  • Such a proxy device is realized as a user space application using a socket.
  • a thread that performs proxy processing in the proxy device (hereinafter referred to as a proxy thread) establishes a TCP connection from the client and acquires a socket related to this connection. Subsequently, the proxy thread acquires data from the socket and executes predetermined processing such as data inspection, processing, or determination of the presence or absence of a cache. Thereafter, the proxy thread generates a socket related to the connection on the server side, establishes a connection with the server, and transmits data to the socket.
  • a proxy thread establishes a TCP connection from the client and acquires a socket related to this connection. Subsequently, the proxy thread acquires data from the socket and executes predetermined processing such as data inspection, processing, or determination of the presence or absence of a cache. Thereafter, the proxy thread generates a socket related to the connection on the server side, establishes a connection with the server, and transmits data to the socket.
  • the system When realizing session distribution in such a proxy device, the system generates as many proxy threads as the number of CPU cores. The system permanently assigns each proxy thread on the CPU core. In this way, two socket processes related to a client side connection and a server side connection related to a certain session are executed by a proxy thread operating on the same CPU core.
  • the socket information of the client side connection is added to the listen socket queue when the connection can be established.
  • the proxy thread calls the accept function to establish a connection.
  • the socket corresponding to the connection to be established is removed from the queue and the connection is established.
  • the CPU core that processes a client-side connection is determined when the connection is established.
  • the server side connection is established after the proxy thread establishes the client side connection, the two connections of the client side connection and the server side connection related to a certain session are fixedly allocated on the same CPU core. It is processed by the proxy thread.
  • Such an RSS-mounted NIC has a function of calculating a hash value based on information included in the header of the received packet and determining a CPU core to be interrupted based on the hash value.
  • the kernel thread performs the protocol processing for the received packet, and the processing until the packet data is registered in the corresponding socket buffer can be performed by one CPU core.
  • the kernel thread can be processed in parallel for each connection, and high scalability utilizing the multi-core CPU can be obtained.
  • the first problem is that a CPU core that operates a kernel thread that performs processing for a connection and a CPU core that operates a proxy thread are not necessarily the same. This is because when a proxy thread establishes a connection, a proxy thread operating in a CPU core other than the CPU core in which the kernel thread operates may call the accept function first to establish the connection. Because there is.
  • proxy thread Once a proxy thread fixedly assigned to another CPU core establishes a connection, the proxy thread then processes the connection. Since the CPU core on which the proxy thread and the kernel thread operate is different, high-speed processing utilizing the CPU cache cannot be realized.
  • the second problem is that the information contained in the headers of the packets belonging to the two connections of the client side connection and the server side connection is different, so even if an RSS-equipped NIC is used, the packets transmitted over the two connections are the same CPU It is not necessarily processed by a kernel thread that runs on the core.
  • a third-vendor product is usually used as the RSS-installed NIC provided in the proxy device.
  • Third-party vendor products often do not know the algorithm for determining the CPU core to be interrupted by the RSS-mounted NIC. Therefore, as in the technique disclosed in Patent Document 1, the RSS-mounted NIC performs server-side connection processing so that packets on the client-side connection and packets on the server-side connection can be assigned to the same CPU core. It is difficult to select the CPU core address.
  • the proxy thread is connected to the kernel thread that operates on another CPU core in the packet reception processing on the two connections. Synchronization is required. In general, since the processing cost is higher in the synchronization processing between different CPU cores than in the same CPU core, the parallelism of the processing is lowered. Further, since they are not the same CPU core, the cache locality is lowered and the performance is deteriorated.
  • the subject of the present invention is to realize a parallel proxy device capable of processing kernel processing and proxy processing related to a session within the same CPU core.
  • the proxy device corresponds to a multi-core CPU having a plurality of CPU cores, an extended listen socket having a plurality of queues provided corresponding to each of the plurality of CPU cores, and a plurality of CPU cores.
  • the first connection establishment request packet reception process with the client assigned to the corresponding CPU core is performed, and the establishment waiting socket including the information of the first connection is selected from the plurality of queues.
  • the establishment waiting socket is registered, the first connection is established based on the establishment waiting socket. And a plurality of proxy threads.
  • the proxy method of the present invention corresponds to a multi-core CPU having a plurality of CPU cores, an extended listen socket having a plurality of queues provided corresponding to each of the plurality of CPU cores, and a plurality of CPU cores.
  • Request for establishing a first connection with a client assigned a process to a corresponding CPU core in a proxy device comprising a plurality of kernel threads provided in correspondence with each CPU core and a plurality of proxy threads provided corresponding to each CPU core
  • a step of receiving a packet, a step of registering an establishment waiting socket including information of the first connection in a queue corresponding to each operating CPU core from a plurality of queues, and a plurality of queues A step of referring to the queue corresponding to the CPU core corresponding to each, and a waiting for establishment And a step of establishing a first connection on the basis of the established waiting socket when Tsu bets is registered.
  • a proxy device that can process kernel processing and proxy processing related to a session on the same CPU core using a multi-core CPU.
  • FIG. 1 is a diagram illustrating a configuration of a proxy device 100 according to an embodiment of the present invention.
  • FIG. 2 is a functional block diagram of the proxy device 100 according to the embodiment of the present invention.
  • FIG. 3 is a diagram illustrating a configuration of the extended listening socket 130 according to the embodiment of the present invention.
  • FIG. 4 is a sequence diagram illustrating an operation of the proxy device 100 according to the embodiment of this invention.
  • the proxy device of the present invention is provided between a client and a server in a network, and has a function of relaying communication between the client and the server.
  • the proxy device includes a multi-core CPU (Central Processing Unit).
  • the proxy device includes a kernel thread and a proxy thread that operate on each CPU core, and further includes a queue corresponding to each CPU core in a listen socket.
  • the kernel thread finishes reception processing such as protocol processing of the received packet, the kernel thread registers a socket waiting for connection in the queue of the listen socket corresponding to the CPU core on which the kernel thread operates. Further, the proxy thread acquires a socket waiting for connection from the queue of listen sockets corresponding to the CPU core on which the proxy thread operates, and executes connection connection processing.
  • the kernel thread and the proxy thread perform socket registration processing and acquisition processing on the listen socket queue corresponding to the CPU core on which they operate. Communication of the socket with which the connection has been established is processed by the same kernel thread and proxy thread, and is therefore processed on the same CPU core.
  • the proxy device of the present invention is described as RSS including similar functions such as RSS (Receive Side Scaling, in the present invention, Receive Packet Steering) that distributes received packet reception processing to each CPU core. ) Equipped with on-board NIC (Network Interface Card).
  • the RSS-mounted NIC determines a CPU core as a distribution destination based on the header information of the received packet.
  • a predetermined mask is set in the header information referred to by the RSS-equipped NIC.
  • the RSS-mounted NIC can perform a process of determining a distribution destination CPU core based on the same information of the header information for packets received from either the client side or the server side. Therefore, processing can be assigned to the same CPU core for packets received from either the client side or the server side for one communication session.
  • the proxy device of the present invention performs processing in the same CPU core for packets received from either the client-side connection or the server-side connection in communication performed between the client and the server.
  • synchronization between CPU cores is not required, and high scalability can be realized.
  • FIG. 1 is a block diagram illustrating a configuration of the proxy device 100 according to the present embodiment.
  • the proxy device 100 according to the present embodiment includes a processing unit 10, a storage unit 20, and a communication unit 30.
  • the processing unit 10, the storage unit 20, and the communication unit 30 are connected via the bus 1 and can transmit and receive data.
  • the storage unit 20 stores a computer program and various data for realizing the function of the proxy device 100.
  • the storage unit 20 includes a main storage device and an auxiliary storage device such as a RAM (Random Access Memory), a ROM (Read Only Memory), and an HDD (Hard Disk Drive).
  • the storage unit 20 stores an operating system (hereinafter referred to as OS) 21 that controls the proxy apparatus 100 and an application program 22 that operates on the OS 21 as computer programs.
  • OS operating system
  • the processing unit 10 implements the function of the proxy device 100 by executing the computer program stored in the storage unit 20.
  • the processing unit 10 is exemplified by a multi-core CPU including a plurality of cores.
  • the processing unit 10 includes four CPU cores 11 to 14.
  • the processing unit 10 will be described as a multi-core CPU including four CPU cores 11 to 14, but the number of CPU cores is not limited to four and may be at least more than four. Absent.
  • the communication unit 30 is a communication interface with an external device in the proxy device 100.
  • the communication unit 30 includes an RSS mounted NIC 31 and an RSS mounted NIC 32.
  • the RSS-equipped NIC 31 is connected to the client 200 via a network (not shown) and can transmit and receive data.
  • the RSS-equipped NIC 32 is connected to the server 300 via a network (not shown) and can transmit and receive data.
  • FIG. 1 one client 200 and one server 300 are shown, but in reality, a large number of clients 200 and servers 300 are connected to RSS-installed NICs 31 and 32 via a network.
  • the RSS-equipped NICs 31 and 32 receive packets from the client 200 and the server 300 and determine a CPU core that performs reception processing of the packets from among the CPU cores 11 to 14 of the processing unit 10.
  • the computer program stored in the storage unit 20 is recorded in a fixed recording medium.
  • the recording medium is exemplified by a CD (Compact Disk), a flash memory (USB memory) equipped with a USB (Universal Serial Bus) interface, and the like.
  • the computer program can be distributed on such a recording medium.
  • the computer program is installed in the proxy apparatus 100 via a CD drive of the proxy apparatus 100 (not shown) or a USB interface.
  • the computer program may be stored in a downloadable manner on the HDD of an application server connected to a network (not shown). In this case, the computer program is introduced into the proxy device via the network.
  • FIG. 2 is a functional block diagram of the proxy device 100 in the present embodiment.
  • the proxy device 100 includes a proxy process 110, a kernel 120, RSS-mounted NICs 31 and 32, and mask setting holding units 35 and 36.
  • the kernel 120 performs packet reception processing.
  • the kernel 120 is a kernel of the OS 21.
  • the kernel 120 includes kernel threads 121 to 124, an extended listening socket 130, and sockets 140 to 146.
  • Kernel threads 121 to 124 are provided corresponding to the CPU cores 11 to 14, respectively. That is, the kernel thread 121 is fixedly assigned on the CPU core 11 and operates. Similarly, the kernel threads 122, 123, and 124 are fixedly allocated and operated on the CPU cores 12, 13, and 14, respectively. The kernel threads 121 to 124 perform reception processing such as protocol processing of received packets assigned to the CPUs 11 to 14, respectively.
  • FIG. 3 is a diagram showing a configuration of the extended listening socket 130 in the present embodiment.
  • the extended listen socket 130 of this embodiment includes queues 131 to 134 provided corresponding to the CPU cores 11 to 14.
  • the queues 131 to 134 store sockets processed by the kernel threads 121 to 124 operating on the corresponding CPU cores 11 to 14, respectively.
  • Sockets 140 to 146 are used for connection processing in the proxy device 100. In FIG. 2, seven sockets 140 to 146 are described. However, since the sockets 140 to 146 are generated corresponding to the number of connections processed by the proxy device 100, there are cases where none exist (zero). There may be a greater number of sockets.
  • the proxy process 10 performs proxy processing for connecting connections.
  • the proxy process 10 is an application of the OS 21.
  • the proxy process 10 includes proxy threads 111 to 114.
  • the proxy threads 111 to 114 are provided corresponding to the CPU cores 11 to 14, respectively. That is, the proxy thread 111 is fixedly assigned to the CPU core 11 and operates. Similarly, the proxy threads 112, 113, and 114 are fixedly allocated and operated on the CPU cores 12, 13, and 14, respectively.
  • the proxy threads 111 to 114 perform proxy processing on connections waiting for connection establishment stored in the queues 131 to 134 of the extended listen socket 130 corresponding to the CPU cores 11 to 14 that operate.
  • the RSS-mounted NICs 31 and 32 receive a packet from the client 200 and the server 300 and determine a CPU core that performs reception processing of the packet from the CPU cores 11 to 14 of the processing unit 10.
  • the RSS-equipped NICs 31 and 32 use the header information masked based on the mask settings 35 and 36, respectively, as a hash key.
  • the mask settings 35 and 36 held in the holding unit hold the mask setting to be performed in the header part of the packet when the RSS-equipped NICs 31 and 32 perform reception processing, respectively.
  • the mask settings 35 and 36 are given as a setting file or a command.
  • the mask setting 35 is a setting in which the RSS-mounted NIC 31 masks the transmission source port number of a packet for a packet received from a client-side connection.
  • the mask setting 36 is a setting for masking the transmission destination port number of a packet received by the RSS-mounted NIC 32 from the connection on the server side.
  • connection 500 that is a client side connection is established between the proxy thread 112 and the client 200
  • a connection 510 that is a server side connection is established between the proxy thread 112 and the server 300.
  • Connections 500 and 510 are TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) connections.
  • the client 200 is set with an IP (Internet Protocol) address “IP100”.
  • IP0 Internet Protocol
  • UDP User Datagram Protocol
  • the client 200 is set with an IP (Internet Protocol) address “IP100”.
  • IP0 Internet Protocol
  • the RSS-mounted NIC 32 is set with an IP address “IP1”.
  • the server 300 is set with an IP address “IP200”.
  • connection 500 the client 200 uses the port number “100”, and the proxy thread 112 uses the port number “0”.
  • connection 510 the server 300 uses the port number “200”, and the proxy thread 112 uses the port number “1”.
  • the packet received by the RSS-mounted NIC 31 from the connection 500 stores header information such as the packet 501. That is, the packet 501 stores the transmission destination IP address “IP0”, the transmission destination port number “0”, the transmission source IP address “IP100”, and the transmission source port number “100” as header information.
  • a packet received by the RSS-mounted NIC 32 from the connection 510 stores header information such as a packet 511. That is, the packet 511 stores the transmission destination IP address “IP1”, the transmission destination port number “1”, the transmission source IP address “IP200”, and the transmission source port number “200” as header information. Note that these settings are merely examples, and are not limited to such settings.
  • the proxy device 100 having such a configuration generally operates as follows.
  • the client 200 transmits a packet 501 for a connection request for a new connection 500.
  • the header information of the packet 501 is as shown in FIG.
  • the RSS core NIC 31 determines the CPU core to be interrupted from the CPU cores 11 to 14 based on the header information of the packet 500.
  • the RSS-equipped NIC 31 determines the CPU core 12 as an interrupt destination.
  • the kernel thread 122 operating on the CPU core 12 performs reception processing such as protocol processing of the packet 500.
  • the kernel thread 122 registers the socket related to the connection 500 in the queue 132 corresponding to the CPU core 12 among the queues 131 to 134 of the extended listen socket 130 when the connection 500 is ready for connection establishment.
  • the proxy thread 112 operating on the CPU core 12 calls the accept function in order to accept a new connection.
  • the proxy thread 112 refers to the queue 132 of the extended listen socket 130 corresponding to the CPU core 12 and checks whether or not there is a socket waiting for connection establishment in the queue 132.
  • the proxy thread 112 acquires a socket related to the connection 500 that is a new connection as a result of calling the accept function.
  • the proxy thread 112 reads data from the socket related to the connection 500 and executes predetermined processing such as data inspection, change, and presence / absence of cache. Thereafter, the proxy thread 112 starts establishing a connection 510 that is a connection on the server side. The proxy thread 112 acquires the transmission source port number “100” of the connection 500. When the proxy thread 112 generates a socket of the connection 510 that is a server-side connection, the generated socket is set so that the transmission source port number of the socket is the same as the transmission source port number “100” in the connection 500. The bind function is called. Thereafter, the proxy thread 112 establishes the server-side connection 510 by calling the connect function for the generated socket.
  • connection 510 uses the destination port number as a hash key by the RSS-mounted NIC 32 and the mask setting 36. Therefore, the RSS-equipped NIC 32 assigns the packet 511 received from the connection 510 to the CPU core 12. Thereby, the packet 511 is processed by the CPU core 12.
  • FIG. 4 is a sequence diagram showing the operation of the proxy device 100 according to this embodiment.
  • the RSS-equipped NIC 31 receives a packet 501 requesting establishment of a new connection 500 from the client 200 (step S100). As shown in FIG. 2, the packet 501 holds, as header information, a transmission destination IP address “IP0”, a transmission destination port number “0”, a transmission source IP address “IP100”, and a transmission source port number “100”. Yes.
  • the RSS-equipped NIC 31 determines an interrupt destination CPU core from among the CPU cores 11 to 14 based on the header information of the packet 501 (step S101).
  • the RSS-equipped NIC 31 determines an interrupt destination CPU core based on the header information masked by the mask setting 35.
  • the mask setting 35 is a setting for masking the transmission source port number in the header information of the packet 501. Therefore, the RSS-equipped NIC 31 determines an interrupt destination CPU core using the transmission source port number of the packet 501 as a hash key.
  • the RSS-equipped NIC determines the CPU core 12 as an interrupt destination.
  • the kernel thread 122 operating on the CPU core 12 acquires the packet 501 from the RSS 31 equipped with the NIC 31 and performs reception processing such as protocol processing.
  • the kernel thread 122 repeats steps S100 to S101 until the connection 500 can be established.
  • the kernel thread 122 stores the socket information regarding the connection 500 in the extended listen socket 130 (step S102).
  • the kernel thread 122 stores socket information including information related to the connection 500 in the queue 132 corresponding to the CPU core 12 in which the kernel thread 122 operates among the queues 131 to 134 of the extended listen socket 130.
  • the proxy threads 111 to 114 perform a confirmation operation by periodically calling the poll function or the select function with respect to the queues 131 to 134 of the extended listening socket 130.
  • the proxy thread 112 detects that socket information for establishing a new connection 500 is stored in the queue 132, the proxy thread 112 calls the accept function for the extended listen socket 130 (step S200).
  • the proxy thread 112 receives the socket of the new connection 500 from the extended listen socket 130 (step S201).
  • the socket 140 is a socket of the connection 500.
  • the proxy thread 112 reads / writes data from / to the socket 140 for communication in the connection 500 (step S202).
  • the socket 140 is used for communication with the client 200.
  • the socket 140 is processed by the proxy thread 112 that has taken over the socket 140.
  • the client 200 transmits data by the packet 501 through the connection 500 (step S300).
  • the RSS-equipped NIC 31 receives the packet 501 from the client 200.
  • the RSS-equipped NIC 31 determines an interrupt destination CPU core based on the transmission source port number in accordance with the mask setting 35 in the header information stored in the packet 501 received from the client 200.
  • the RSS-equipped NIC 31 determines the CPU core 12 as the interrupt destination in the same manner as described above in order to determine the interrupt destination CPU core using the transmission source port number as a hash device, as in step S101.
  • the kernel thread 122 operating on the CPU core 12 receives the packet 501 and performs reception processing such as protocol processing on the packet 501 (step S301).
  • the kernel thread 122 writes data related to the packet 501 in the socket 140 corresponding to the connection 500 (step S302).
  • the proxy thread 112 reads data from the socket 140 and performs predetermined processing such as data verification, security check, and presence / absence of a cache (step S303).
  • the proxy thread 112 acquires the transmission source port number of the connection 500 that is the client-side connection from the socket 140 before establishing the connection 510 that is the server-side connection (step S304).
  • the proxy thread 112 generates a socket for the connection 510.
  • the proxy thread 112 has created the socket 141.
  • the proxy thread 112 calls the bind function for the socket 141, thereby setting the transmission source port number of the connection 500 acquired in step S304 as the transmission source port number of the connection 510 (step S305).
  • the proxy thread 112 starts establishment of the connection 510 by calling the connect function for the socket 141 in which the same port number as the transmission source port number of the connection 500 is set (step S306). After the system call of the socket 141 is called, protocol processing in the kernel at the time of transmission may be executed in the context of the proxy thread 112 or may be executed in the context of the kernel thread 122. Even in this case, the processing is performed by the CPU core 12.
  • the server 300 transmits data by the packet 511 through the established connection 510 (step S400).
  • the RSS-equipped NIC 32 determines an interrupt destination CPU core based on the transmission destination port number according to the mask setting 36 in the header information stored in the packet 511 received from the server 300.
  • the transmission destination port number stored in the packet 511 is the same as the transmission source port number stored in the packet 501. Therefore, the RSS-equipped NIC 32 determines the CPU core 12 as an interrupt destination CPU core.
  • both the packet 501 received from the client 200 through the connection 500 and the packet 511 received from the server 300 through the connection 510 are processed by the same CPU core 12.
  • the kernel thread 122 operating on the CPU core 12 inputs the packet 511 and performs reception processing such as protocol processing on the packet 511 (step S401).
  • the kernel thread 122 writes data relating to the packet 511 to the socket 141 corresponding to the connection 510 (step S402).
  • the proxy thread 112 reads data from the socket 141 and receives data transmitted from the server (step S403). Thereafter, the proxy thread 112 transmits data from the server to the client 200 through the connection 500.
  • the above is description of operation
  • the proxy device in the present embodiment has been described.
  • processing is performed by a kernel thread and a proxy thread in which a certain connection operates on the same CPU core in an environment using an RSS-mounted NIC. Therefore, the locality of the cache of the CPU core is improved and low overhead processing can be realized.
  • the extended listen socket has the same number of queues as the CPU core in correspondence with the CPU core.
  • the proxy thread performs processing on the queue of the extended listen socket provided corresponding to the CPU core on which the proxy thread operates in the call of the accept function when establishing a connection from the client. Become.
  • the proxy device of the present invention in an environment using an RSS-mounted NIC, synchronization between a proxy thread operating on different CPU cores and a kernel thread is unnecessary, thereby improving parallelism, and By processing on the same CPU core, the cache cache locality is improved and the proxy performance is improved.
  • the proxy device includes two RSS-installed NICs that exclusively process the client-side connection and the server-side connection.
  • the RSS-mounted NIC for client side connection is masked so that the source port number is used as a hash key in the packet header information.
  • the RSS-mounted NIC for server side connection is masked so as to use the destination port number as a hash key in the packet header information.
  • the proxy thread when establishing the connection of the server side connection, the proxy thread takes over the source port number of the client side connection and sets it by calling the bind function as the source port number in the socket of the server side connection. To do. Therefore, two connections related to the session between the client and the server are processed by the kernel thread on the same CPU core.

Abstract

 あるセッションに関するカーネル処理とプロキシ処理とを同一のCPUコア内で処理することが可能な並列化されたプロキシ装置が提供される。複数のCPUコアを備えるマルチコアCPUと、複数のCPUコアに対応する複数のキューを具備する拡張リッスンソケットと、複数のCPUコアに対応する複数のカーネルスレッド及び複数のプロキシスレッドとを備える。各カーネルスレッドは、各カーネルスレッドの動作するCPUコアに割り当てられたクライアント側コネクションの確立要求パケットの受信処理を行って、確立待ちソケットを各カーネルスレッドの動作するCPUコアに対応したキューに登録する。各プロキシスレッドは、各プロキシスレッドの動作するCPUコアに対応するキューを参照して、確立待ちソケットが登録されている場合に第1コネクションを確立する。

Description

プロキシ装置とその動作方法
 本発明は、マルチコアCPUを備え、並列処理を行うプロキシ装置に関する。
 CPU(Central Processing Unit)における動作周波数の向上が、限界に近づいている。そのため、CPUの発展は、動作周波数の向上から、コアの増加に向かっている。こうした状況の下、複数のコアを備えたマルチコアCPUが普及してきている。
 プロキシ装置は、クライアントとサーバとの間に設けられて、クライアント側コネクションとサーバ側コネクションを中継する。ここで、クライアント側コネクションは、クライアントとプロキシ装置間のコネクションである。サーバ側コネクションは、サーバとプロキシ装置間のコネクションである。このプロキシ装置においても、マルチコアCPUを備える装置が増加している。そして、マルチコアCPUをより効率的に運用するアーキテクチャや実装方式が提案されている。
 また、並列性は、マルチコアCPUを用いて高いスケーラビリティを得るために重要である。マルチコアCPUでは、コア間における同期処理が処理能力に影響を及ぼす。そのため、プロキシ装置においても、CPUコア間の同期が発生しないような制御を必要とする。
 プロキシ装置が、クライアント側コネクションとサーバ側コネクションの2つでの処理を2つのセッションとして扱う場合、複数のセッション間で共有すべきデータはほとんど存在しない。そのため、このような通信における並列化に最も有効な方法は、セッション毎に処理を行うCPUコアを分ける手法であることが知られている。以下、このような、手法をセッション分散と呼ぶ。
 特許文献1は、NAT(Network Address Translation)処理を行うセキュリティゲートウェイにおいて、処理を行う資源の割り当てを決定するディスパッチャがクライアント側コネクションとサーバ側コネクションの2つのコネクションで伝送されるパケットが同じCPUコアで処理されるように、サーバ側コネクションのプロキシのアドレスを選択する技術を開示している。
 特許文献1によれば、ディスパッチャが2つのコネクションで伝送されるパケットを同一のCPUコアに割り振るため、セッション分散が実現されており、それにより他CPUコアとの同期が不要となり、スケーラビリティを向上できる。
 一方、TCP(Transmission Control Protocol)コネクションを終端するようなプロキシ装置も存在する。このようなプロキシ装置は、ソケットを利用したユーザ空間のアプリケーションとして実現される。
 プロキシ装置においてプロキシ処理を行うスレッド(以下、プロキシスレッドと呼ぶ。)は、クライアントからのTCPコネクションを確立して、このコネクションに関するソケットを取得する。続いて、プロキシスレッドは、ソケットからデータを取得して、データの検査や、加工処理や、あるいはキャッシュの有無の判断等の所定の処理を実行する。その後、プロキシスレッドは、サーバ側のコネクションに関するソケットを生成して、サーバとのコネクションを確立して、ソケットにデータを送信する。
 このようなプロキシ装置においてセッション分散を実現する場合、システムは、CPUコアの数と同数のプロキシスレッドを生成する。システムは、それぞれのプロキシスレッドをCPUコア上に固定的に割り当てる。こうして、あるセッションに関連するクライアント側コネクションとサーバ側コネクションに関する2つのソケット処理が、同一のCPUコア上で動作するプロキシスレッドにより実行される。
 この処理において、クライアント側コネクションのソケットの情報は、コネクションが確立可能な状態となると、リッスンソケットのキューに追加される。プロキシスレッドは、コネクションを確立するためにaccept関数の呼び出しを行う。これによって、確立されるべきコネクションに対応するソケットがキューから取り出されてコネクションを確立する。この後、一度確立されたコネクションの処理は、コネクションを確立したプロキシスレッドが行う。
 従って、あるクライアント側コネクションを処理するCPUコアは、コネクションの確立時に決定される。また、プロキシスレッドがクライアント側コネクションを確立した後に、サーバ側コネクションは確立されるので、あるセッションに関連するクライアント側コネクションとサーバ側コネクションの2つのコネクションは、同じCPUコア上に固定的に割り当てられたプロキシスレッドで処理される。
 このようにして、ユーザ空間でのプロキシ処理の並列化が実現されて、マルチコアCPUを生かした高いスケーラビリティを得ることができる。
 最近、マルチコアCPUを搭載したWebサーバの性能向上のために、受信されるパケットを処理の空いているCPUコアへ動的に分散するReceive Side Scalingや、Receive Packet Steering(以下、これらの機能をまとめてRSSと呼ぶ。)といった機能を備えるNIC(Network Interface Card)が登場してきている。
 このような、RSS搭載NICは、受信パケットのヘッダに含まれる情報に基づいてハッシュ値を算出して、ハッシュ値に基づいて割り込みを対象となるCPUコアを決定する機能を有する。
 あるコネクション上で伝送されるパケットは、同じヘッダ情報を備えているので、そのパケットは、全て同じCPUコアに対して割り込みを発生する。すなわち、RSS搭載NICでのパケットの受信に応答してカーネルスレッドが受信パケットに関するプロトコル処理を行い、対応するソケットのバッファにパケットデータを登録するまでの処理を1つのCPUコアで行うことができる。
 このように、RSS搭載NICを用いることで、カーネルスレッドの処理もコネクション毎に並列処理することができるようになり、マルチコアCPUを活かした高いスケーラビリティを得ることができる。
 しかしながら、特許文献1に記載された手法を用いて、RSS搭載NICでのパケット受信からユーザ空間でのプロキシ処理までを同一CPUコアにより処理するようなプロキシ装置を実現するときには、以下のような課題が存在する。
 まず、第1課題は、あるコネクションに対して処理を行うカーネルスレッドが動作するCPUコアと、プロキシスレッドが動作するCPUコアとが同一とは限らない点である。これは、プロキシスレッドがコネクションを確立する際に、カーネルスレッドが動作するCPUコアとは別のCPUコアで動作するプロキシスレッドが先にaccept関数の呼び出しを行ってコネクションを確立してしまう可能性があるからである。
 一度、別のCPUコアに固定的に割り当てられたプロキシスレッドがコネクションを確立すると、その後、そのコネクションに関する処理は、そのプロキシスレッドが処理する。そのプロキシスレッドとカーネルスレッドとが動作するCPUコアは異なるため、CPUキャッシュを活かした高速な処理を実現できない。
 従って、あるコネクションの処理を行うカーネルスレッドとプロキシスレッドを同一のCPUコアで実行されるためには、プロキシスレッドがクライアント側コネクションを確立する際に、クライアント側コネクションの確立処理を行ったカーネルスレッドと同一のCPUコアで動作するプロキシスレッドがサーバ側コネクションを確立する仕組みが必要となる。
 第2課題は、クライアント側コネクションとサーバ側コネクションの2つのコネクションに属するパケットのヘッダに含まれる情報が異なるので、RSS搭載NICを用いたとしても、2つのコネクション上で伝送されるパケットが同じCPUコアで動作するカーネルスレッドで処理されるとは限らない点である。
 プロキシ装置に備えられるRSS搭載NICは、通常、サードベンダー製品が用いられる。サードベンダー製品では、RSS搭載NICによる割り込み先となるCPUコアを決定するアルゴリズムが不明であることも多い。そのため、特許文献1に示された手法のように、RSS搭載NICが、クライアント側コネクションうえのパケットとサーバ側コネクション上のパケットとを同一CPUコアに割り当てられるように、サーバ側コネクションの処理を行うCPUコアのアドレスを選択することは難しい。
 仮に、RSS搭載NICによりサーバ側コネクションが別のCPUコアで動作するカーネルスレッドに割り当てられた場合、プロキシスレッドは、2つのコネクション上のパケット受信処理において、別のCPUコアで動作するカーネルスレッドとの同期が必要となる。一般に、同一CPUコア内での同期処理よりも、異なるCPUコア間での同期処理のほうが処理コストは大きくなるので、処理の並列性が低下してしまう。また、同一CPUコアでないので、キャッシュのローカリティが低下して性能が劣化してしまう。
 なお、関連技術として、マルチコアCPUを用いた装置における処理速度の向上に関する技術が、特許文献2、3、4に開示されている。
国際公開第2009/073295号パンフレット 特開2009-199433号公報 特表2008-512950号公報 特開2008-134775号公報
 本発明の主題は、あるセッションに関するカーネル処理とプロキシ処理とを同一のCPUコア内で処理することが可能な並列化されたプロキシ装置を実現することである。
 本発明のプロキシ装置は、複数のCPUコアを備えるマルチコアCPUと、複数のCPUコアの各々に対応して設けられた複数のキューを具備する拡張リッスンソケットと、複数のCPUコアの各々に対応して設けられて、対応するCPUコアに処理を割り当てられたクライアントとの第1コネクションの確立要求パケットの受信処理を行って、第1コネクションの情報を含んだ確立待ちソケットを、複数のキューのうちからそれぞれの動作するCPUコアに対応したキューに登録する複数のカーネルスレッドと、各CPUコアに対応して設けられて、複数のキューのうちからそれぞれに対応したCPUコアに対応するキューを参照して、確立待ちソケットが登録されている場合に、確立待ちソケットに基づいて第1コネクションを確立する複数のプロキシスレッドとを備える。
 本発明のプロキシ方法は、複数のCPUコアを備えるマルチコアCPUと、複数のCPUコアの各々に対応して設けられた複数のキューを具備する拡張リッスンソケットと、複数のCPUコアの各々に対応して設けられた複数のカーネルスレッドと、各CPUコアに対応して設けられた複数のプロキシスレッドとを備えるプロキシ装置において、対応するCPUコアに処理を割り当てられたクライアントとの第1コネクションの確立要求パケットの受信処理を行うステップと、第1コネクションの情報を含んだ確立待ちソケットを、複数のキューのうちからそれぞれの動作するCPUコアに対応したキューに登録するステップと、複数のキューのうちからそれぞれに対応したCPUコアに対応するキューを参照するステップと、確立待ちソケットが登録されている場合に確立待ちソケットに基づいて第1コネクションを確立するステップとを備える。
 本発明によれば、マルチコアCPUを用いて、あるセッションに関するカーネル処理とプロキシ処理とを同一のCPUコア上で処理することが可能なプロキシ装置を実現できる。
図1は、本発明の実施形態におけるプロキシ装置100の構成を示す図である。 図2は、本発明の実施形態におけるプロキシ装置100の機能ブロック図である。 図3は、本発明の実施形態における拡張リッスンソケット130の構成を示す図である。 図4は、本発明の実施形態におけるプロキシ装置100の動作を示すシーケンス図である。
 添付図面を参照して、本発明によるプロキシ装置を以下に説明する。
[概要]
 本発明のプロキシ装置は、ネットワーク内において、クライアントとサーバの間に設けられ、クライアントとサーバの間の通信を中継する機能を有する。プロキシ装置は、マルチコアCPU(Central Processing Unit)を備えている。プロキシ装置は、各CPUコア上で動作するカーネルスレッドとプロキシスレッドとを備え、さらに、リッスンソケットに各CPUコアに対応したキューを備えている。カーネルスレッドは、受信されたパケットのプロトコル処理等の受信処理を終えると、当該カーネルスレッドの動作するCPUコアに対応するリッスンソケットのキューに、接続待ちとなるソケットを登録する。また、プロキシスレッドは、当該プロキシスレッドの動作するCPUコアに対応するリッスンソケットのキューから接続待ちのソケットを取得して、コネクションの接続処理を実行する。
 このように、本発明のプロキシ装置では、カーネルスレッドとプロキシスレッドとは、それらが動作するCPUコアに対応するリッスンソケットのキューに対してソケットの登録処理と取得処理を行う。接続が確立されたソケットの通信は、その後も、同じカーネルスレッドとプロキシスレッドとにより処理が行われるため、同一のCPUコア上で処理される。
 また、本発明のプロキシ装置は、受信されたパケットの受信処理を各CPUコアへ振り分けるRSS(RSS:Receive Side Scaling、本発明では、Receive Packet Steering等の同様の機能を含めてRSSと記載する。)搭載NIC(Network Interface Card)を備える。RSS搭載NICは、受信されたパケットのヘッダ情報に基づいて、振り分け先のCPUコアを決定する。本発明のプロキシ装置では、RSS搭載NICが参照するヘッダ情報に所定のマスクが設定される。これにより、RSS搭載NICは、クライアント側及びサーバ側のいずれから受信されたパケットに対しても、ヘッダ情報の同じ情報に基づいて振り分け先CPUコアを決定する処理を行うことができる。そのため、一つの通信セッションに対して、クライアント側及びサーバ側のいずれから受信されたパケットも、同じCPUコアへ処理を割り振ることができる。
 これらの構成によって、本発明のプロキシ装置は、クライアントとサーバの間で行われる通信において、クライアント側コネクション及びサーバ側コネクションのいずれから受信されたパケットに対しても、同一CPUコアで処理を行うことが可能となり、CPUコア間の同期が必要とならず、高いスケーラビリティを実現することができる。
 以下に、本発明の一実施形態によるプロキシ装置の構成及び動作を詳細に説明する。
[構成]
 はじめに、本実施形態におけるプロキシ装置の構成を説明する。図1は、本実施形態におけるプロキシ装置100の構成を示すブロック図である。本実施形態のプロキシ装置100は、処理部10と、記憶部20と、通信部30とを備えている。処理部10、記憶部20、及び通信部30は、それぞれバス1を介して接続されており、データの送受信が可能である。
 まず、記憶部20は、プロキシ装置100の機能を実現するためのコンピュータプログラムや各種データを記憶する。記憶部20は、RAM(Random Access Memory)や、ROM(Read Only Memory)や、HDD(Hard Disk Drive)に例示されるような主記憶装置及び補助記憶装置により構成される。記憶部20は、コンピュータプログラムとして、プロキシ装置100を制御するオペレーティングシステム(以下、OS)21、及びOS21上で動作するアプリケーションプログラム22を記憶する。
 次に、処理部10は、記憶部20に記憶されたコンピュータプログラムを実行することで、プロキシ装置100の機能を実現する。処理部10は、複数のコアを備えるマルチコアCPUにより例示される。本実施形態において、処理部10は、4つのCPUコア11~14を備える。なお、以下の説明において、処理部10は4つのCPUコア11~14を備えたマルチコアCPUとして説明を行うが、CPUコアの数は、4つに限定せず、4つより多くとも、少なくとも構わない。
 次に、通信部30は、プロキシ装置100における外部装置との通信インターフェースである。通信部30は、RSS搭載NIC31、RSS搭載NIC32を備える。RSS搭載NIC31は、図示されないネットワークを介してクライアント200と接続されて、データの送受信が可能である。RSS搭載NIC32は、図示されないネットワークを介してサーバ300と接続されて、データの送受信が可能である。なお、図1において、クライアント200とサーバ300とは、それぞれ1台づつ記載されているが、実際には、多数のクライアント200及びサーバ300が、ネットワークを介してRSS搭載NIC31、及び32と接続される。RSS搭載NIC31、32は、クライアント200、及びサーバ300からパケットを受信して、処理部10のCPUコア11~14のうちから当該パケットの受信処理を行うCPUコアを決定する。
 ここで、記憶部20に記憶されたコンピュータプログラムは、固定的な記録媒体に記録されている。ここで、記録媒体とは、CD(Compact Disk)や、USB(Universal Serial Bus)インターフェースを搭載したフラッシュメモリ(USBメモリ)等に例示される。コンピュータプログラムは、このような記録媒体により流通が可能である。コンピュータプログラムは、図示されないプロキシ装置100のCDドライブや、USBインターフェースを介して、プロキシ装置100へインストールされる。また、コンピュータプログラムは、図示されないネットワークに接続されたアプリケーションサーバのHDDにダウンロード可能に記憶されていてもよい。この場合、コンピュータプログラムは、ネットワークを介して、プロキシ装置へ導入される。
 続いて、図2は、本実施形態におけるプロキシ装置100の機能ブロック図である。本実施形態におけるプロキシ装置100は、プロキシプロセス110と、カーネル120と、RSS搭載NIC31、32と、マスク設定の保持部35、36とを備える。
 まず、カーネル120は、パケットの受信処理を行う。カーネル120は、OS21のカーネルである。カーネル120は、カーネルスレッド121~124と、拡張リッスンソケット130と、ソケット140~146とを備える。
 カーネルスレッド121~124は、それぞれCPUコア11~14に対応して設けられる。すなわち、カーネルスレッド121は、CPUコア11上に固定的に割り当てられ、動作する。同様にカーネルスレッド122、123、124は、それぞれCPUコア12、13、14上に固定的割り当てられ、動作する。カーネルスレッド121~124は、それぞれ、CPU11~14に割り当てられた受信パケットのプロトコル処理等の受信処理を行う。
 拡張リッスンソケット130には、接続の確立を待つソケットが登録される。拡張リッスンソケット130は、socket関数の呼び出しを行うことより生成される。図3は、本実施形態における拡張リッスンソケット130の構成を示す図である。本実施形態の拡張リッスンソケット130は、CPUコア11~14に対応して設けられたキュー131~134を備える。キュー131~134は、それぞれ対応するCPUコア11~14上で動作するカーネルスレッド121~124により処理されたソケットを記憶する。
 ソケット140~146は、プロキシ装置100におけるコネクションの処理に用いられる。図2には、7つのソケット140~146が記載されているが、ソケット140~146は、プロキシ装置100が処理するコネクション数に対応して生成されるため、全く存在しない(0個)場合や、より多くの数のソケットが存在する場合がある。
 次に、プロキシプロセス10は、コネクション間を接続するプロキシ処理を行う。プロキシプロセス10は、OS21のアプリケーションである。プロキシプロセス10は、プロキシスレッド111~114を備える。プロキシスレッド111~114は、それぞれCPUコア11~14に対応して設けられる。すなわち、プロキシスレッド111は、CPUコア11上に固定的に割当てられて動作する。同様に、プロキシスレッド112、113、114は、それぞれCPUコア12、13、14上に固定的に割当てられて動作する。
 プロキシスレッド111~114は、それぞれが動作するCPUコア11~14に対応する拡張リッスンソケット130のキュー131~134に格納された接続確立待ちのコネクションに対してプロキシ処理を行う。
 RSS搭載NIC31、32は、前述の通り、クライアント200及びサーバ300からパケットを受信して、処理部10のCPUコア11~14のうちから当該パケットの受信処理を行うCPUコアを決定する。RSS搭載NIC31、32は、それぞれ、マスク設定35、36に基づいてマスクされたヘッダ情報をハッシュのキーとして利用する。
 保持部に保持されたマスク設定35、36は、それぞれ、RSS搭載NIC31、32が受信処理を行う際に、パケットのヘッダ部に行うマスク設定を保持する。マスク設定35、36は、設定ファイルやコマンドとして与えられる。本実施形態において、マスク設定35は、RSS搭載NIC31がクライアント側のコネクションから受信されるパケットに対して、パケットの送信元ポート番号をマスクする設定である。また、マスク設定36は、RSS搭載NIC32がサーバ側のコネクションから受信されるパケットに対して、パケットの送信先ポート番号をマスクする設定である。
 ここで、以下の説明において、プロキシスレッド112とクライアント200の間には、クライアント側コネクションであるコネクション500が確立され、プロキシスレッド112とサーバ300との間には、サーバ側コネクションであるコネクション510が確立される。コネクション500、510は、TCP(Transmission Control Protocol)やUDP(User Datagram Protocol)によるコネクションである。また、クライアント200には、IP(Internet Protocol)アドレス「IP100」が設定されている。RSS搭載NIC31には、IPアドレス「IP0」、RSS搭載NIC32には、IPアドレス「IP1」が設定されている。サーバ300には、IPアドレス「IP200」が設定されている。
 また、コネクション500において、クライアント200がポート番号「100」を使用し、プロキシスレッド112がポート番号「0」を使用する。コネクション510において、サーバ300がポート番号「200」を使用し、プロキシスレッド112がポート番号「1」を使用する。
 このような設定状態において、RSS搭載NIC31が、コネクション500から受信するパケットは、パケット501のようなヘッダ情報を格納する。つまり、パケット501は、ヘッダ情報として、送信先IPアドレス「IP0」、送信先ポート番号「0」、送信元IPアドレス「IP100」、送信元ポート番号「100」を格納する。また、RSS搭載NIC32が、コネクション510から受信するパケットは、パケット511のようなヘッダ情報を格納する。つまり、パケット511は、ヘッダ情報として、送信先IPアドレス「IP1」、送信先ポート番号「1」、送信元IPアドレス「IP200」、送信元ポート番号「200」を格納する。なお、これらの設定は、あくまで一例であり、このような設定には限定しない。
 以上が、本実施形態におけるプロキシ装置100の構成の説明であるが、このような構成のプロキシ装置は、概略、次のように動作する。クライアント200は、新規のコネクション500の接続要求のためパケット501を送信する。この場合、パケット501のヘッダ情報は、図2に示すとおりである。RSS搭載NIC31は、パケット500を受信すると、パケット500のヘッダ情報に基づいて、CPUコア11~14から割り込み先のCPUコアを決定する。ここで、RSS搭載NIC31がCPUコア12を割り込み先として決定したとする。CPUコア12上で動作するカーネルスレッド122が、パケット500のプロトコル処理等の受信処理を行う。カーネルスレッド122は、コネクション500の接続確立の準備ができた段階で、拡張リッスンソケット130のキュー131~134のうち、CPUコア12に対応するキュー132へコネクション500に関するソケットを登録する。
 一方、CPUコア12上で動作するプロキシスレッド112は、新規コネクションを受け付けるために、accept関数の呼び出しをおこなう。accept関数の呼び出しを受けて、プロキシスレッド112は、CPUコア12に対応する拡張リッスンソケット130のキュー132を参照し、キュー132にコネクションの接続確立待ちのソケットが存在するか否かを確認する。キュー132にはコネクション500の接続確立待ちのソケットが存在するとき、プロキシスレッド112は、accept関数の呼び出しの結果として、新規コネクションであるコネクション500に関するソケットを取得する。
 続いて、プロキシスレッド112は、コネクション500に関するソケットからデータを読み出して、データの検査、変更、キャッシュの有無の確認等の所定の処理を実行する。その後、プロキシスレッド112は、サーバ側のコネクションであるコネクション510の確立を開始する。プロキシスレッド112は、コネクション500の送信元ポート番号「100」を取得する。プロキシスレッド112は、サーバ側コネクションであるコネクション510のソケットを生成する際に、当該ソケットの送信元ポート番号がコネクション500における送信元ポート番号「100」と同じ番号になるように、生成されたソケットに対してbind関数の呼び出しを行う。その後、プロキシスレッド112は、生成されたソケットに対して、connect関数の呼び出しを行うことでサーバ側コネクション510を確立する。
 コネクション510は、RSS搭載NIC32とマスク設定36によって、送信先ポート番号がハッシュのキーとして利用される。そのため、RSS搭載NIC32は、コネクション510から受信されたパケット511を、CPUコア12へ割り当てる。これにより、パケット511は、CPUコア12で処理を行われる。
[動作]
 次に、上述のように構成されたプロキシ装置100の動作を説明する。図4は、本実施形態におけるプロキシ装置100の動作を示すシーケンス図である。
 RSS搭載NIC31は、クライアント200から新規のコネクション500の確立を要求するパケット501を受信する(ステップS100)。パケット501は、図2に示すように、ヘッダ情報として、送信先IPアドレス「IP0」、送信先ポート番号「0」、送信元IPアドレス「IP100」、送信元ポート番号「100」を保持している。
 RSS搭載NIC31は、パケット501のヘッダ情報に基づいて、CPUコア11~14のうちから割り込み先のCPUコアを決定する(ステップS101)。RSS搭載NIC31は、マスク設定35によりマスクされたヘッダ情報に基づいて割り込み先のCPUコアを決定する。本実施形態において、マスク設定35は、パケット501のヘッダ情報において、送信元ポート番号をマスクする設定である。そのため、RSS搭載NIC31は、パケット501の送信元ポート番号をハッシュのキーとして、割り込み先のCPUコアを決定する。ここでは、RSS搭載NICは、CPUコア12を割り込み先として決定したとする。
 CPUコア12上で動作するカーネルスレッド122は、RSS搭載NIC31からパケット501を取得してプロトコル処理等の受信処理を行う。カーネルスレッド122は、コネクション500の確立が可能になるまで、ステップS100~ステップS101を繰り返す。カーネルスレッド122は、コネクション500の確立が可能となると、コネクション500に関するソケット情報を拡張リッスンソケット130へ格納する(ステップS102)。この時カーネルスレッド122は、拡張リッスンソケット130のキュー131~134のうち、カーネルスレッド122が動作するCPUコア12に対応するキュー132へコネクション500に関する情報を含んだソケット情報を格納する。
 一方、プロキシスレッド111~114は、拡張リッスンソケット130のキュー131~134に対して、poll関数や、select関数の呼び出しを行って定期的に参照することにより確認動作を行う。プロキシスレッド112は、キュー132において新規のコネクション500の確立のためのソケット情報が格納されたことを検知すると、拡張リッスンソケット130に対して、accept関数の呼び出しを行う(ステップS200)
 プロキシスレッド112は、accept関数の呼び出しが成功すると、拡張リッスンソケット130から新規のコネクション500のソケットを受け取る(ステップS201)。ここでは、ソケット140をコネクション500のソケットとする。プロキシスレッド112は、以後、コネクション500における通信に関してソケット140に対してデータの読み書きを行う(ステップS202)。以後、クライアント200との間の通信には、ソケット140が利用される。ソケット140は、ソケット140を引き取ったプロキシスレッド112により処理される。
 続いて、クライアント200は、コネクション500を通じてパケット501によりデータを送信する(ステップS300)。RSS搭載NIC31は、クライアント200からパケット501を受信する。RSS搭載NIC31は、クライアント200から受信されたパケット501に格納されたヘッダ情報のうち、マスク設定35に従って、送信元ポート番号に基づいて割り込み先CPUコアを決定する。RSS搭載NIC31は、ステップS101と同様に、送信元ポート番号をハッシュの器として割り込み先CPUコアを決定するため、前述と同様に、CPUコア12を割り込み先として決定する。
 RSS搭載NIC31によりCPUコア12に割り込みが発生すると、CPUコア12上で動作するカーネルスレッド122は、パケット501を受けて、パケット501に対してプロトコル処理等の受信処理を行う(ステップS301)。カーネルスレッド122は、コネクション500に対応するソケット140に、パケット501に関するデータを書き込む(ステップS302)。
 プロキシスレッド112は、ソケット140からデータを読み込んで、データの検証や、セキュリティチェックや、キャッシュの有無といった所定の処理を行う(ステップS303)。
 プロキシスレッド112は、サーバ側のコネクションであるコネクション510を確立する前に、ソケット140からクライアント側のコネクションであるコネクション500の送信元ポート番号を取得する(ステップS304)。
 プロキシスレッド112は、コネクション510のソケットを生成する。ここでは、プロキシスレッド112が、ソケット141を生成したとする。プロキシスレッド112は、ソケット141に対して、bind関数の呼び出しを行うことで、ステップS304で取得したコネクション500の送信元ポート番号を、コネクション510の送信元ポート番号に設定する(ステップS305)。
 プロキシスレッド112は、コネクション500の送信元ポート番号と同じポート番号が設定されたソケット141に対して、connect関数の呼び出しを行うことでコネクション510の確立を開始する(ステップS306)。ソケット141のシステムコールが呼び出された後は、送信時のカーネル内のプロトコル処理は、プロキシスレッド112のコンテキストで実行される場合や、あるいはカーネルスレッド122のコンテキストで実行される場合もあるが、いずれの場合においても、CPUコア12での処理となる。
 続いて、サーバ300は、確立されたコネクション510を通じてパケット511によりデータを送信する(ステップS400)。RSS搭載NIC32は、サーバ300から受信されたパケット511に格納されたヘッダ情報のうち、マスク設定36に従って、送信先ポート番号に基づいて割り込み先CPUコアを決定する。このとき、パケット511に格納される送信先ポート番号は、パケット501に格納される送信元ポート番号と同一である。そのため、RSS搭載NIC32は、CPUコア12を割り込み先のCPUコアとして決定する。これにより、クライアント200からコネクション500を通じて受信されるパケット501も、サーバ300からのコネクション510を通じて受信されるパケット511も、同様のCPUコア12により処理が行われることとなる。
 RSS搭載NIC32によりCPUコア12に割り込みが発生すると、CPUコア12上で動作するカーネルスレッド122は、パケット511を入力して、パケット511に対してプロトコル処理等の受信処理を行う(ステップS401)。カーネルスレッド122は、コネクション510に対応するソケット141に、パケット511に関するデータを書き込む(ステップS402)。
 プロキシスレッド112は、ソケット141からデータを読み込んで、サーバから送信されたデータを受信する(ステップS403)。その後、プロキシスレッド112は、クライアント200へコネクション500を通じて、サーバからのデータを送信する。以上が、本実施形態におけるプロキシ装置の動作の説明である。
 ここまで、本実施形態におけるプロキシ装置の説明を行ってきた。本発明のプロキシ装置によれば、RSS搭載NICを用いた環境において、あるコネクションが同一のCPUコア上で動作するカーネルスレッドとプロキシスレッドとにより処理が行われる。そのため、CPUコアのキャッシュのローカリティが向上し、低オーバーヘッド処理を実現することができる。それは、拡張リッスンソケットが、CPUコアに対応させて、CPUコアと同数のキューを備えるからである。これにより、プロキシスレッドは、クライアントからのコネクションを確立する際のaccept関数の呼び出しにおいて、当該プロキシスレッドの動作するCPUコアに対応して設けられた拡張リッスンソケットのキューに対して処理を行うことになる。
 また、本発明のプロキシ装置によれば、RSS搭載NICを用いた環境において、異なるCPUコア上で動作するプロキシスレッドとカーネルスレッド間での同期が不要になることで並列性が向上し、かつ、同一CPUコア上で処理されることにより、CPUのキャッシュのローカリティが向上してプロキシの性能が向上する。それは、プロキシ装置が、クライアント側コネクションとサーバ側コネクションをそれぞれ専用に処理する2つのRSS搭載NICを備えるからである。クライアント側コネクション用のRSS搭載NICは、パケットのヘッダ情報において送信元ポート番号をハッシュのキーとして利用するようにマスク設定される。また、サーバ側コネクション用のRSS搭載NICは、パケットのヘッダ情報において送信先ポート番号をハッシュのキーとして利用するようにマスク設定される。さらに、プロキシスレッドは、サーバ側コネクションの接続確立を行う際に、クライアント側コネクションの送信元ポート番号を引き継いで、サーバ側コネクションのソケットにおける送信元ポート番号として、bind関数の呼び出しを行うことより設定する。そのため、クライアントとサーバ間のセッションに関する2つのコネクションが、同じCPUコア上のカーネルスレッドで処理されることになる。
 これまで、実施形態を参照して本願発明の説明を行ってきたが、本願発明は、上記の実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解し得る様々な変更を行うことが可能である。
 この出願は、2010年2月3日に出願された日本出願特願2010-022107を基礎とする優先権を主張し、その開示の全てをここに取り込む。

Claims (9)

  1.  複数のCPUコアを備えるマルチコアCPUと、
     前記複数のCPUコアに対してそれぞれ設けられた複数のキューを具備する拡張リッスンソケットとを具備し、
     前記複数のCPUコアの各々の上でカーネルスレッドとプロキシスレッドが動作し、
     前記カーネルスレッドは、前記複数のCPUコアのうちの対応するものに割り当てられた、クライアントとの第1コネクションの確立要求パケットの受信処理を行い、前記第1コネクションの情報を含んだ確立待ちソケットを、前記複数のキューのうちの対応するものに登録し、
     前記プロキシスレッドは、前記対応するキューを参照し、前記対応するキューに前記確立待ちソケットが登録されている場合に、前記確立待ちソケットに基づいて前記第1コネクションを確立する
     プロキシ装置。
  2.  請求項1に記載のプロキシ装置であって、
     前記クライアントと接続され、前記クライアントからクライアント側パケットを受信すると、前記クライアント側パケットのヘッダ情報に基づいて、前記複数のCPUコアのうちから、前記クライアント側パケットの処理を行うものを、第1指定CPUコアとして決定する第1NIC(Network Interface Card)と、
     サーバと接続されて、前記サーバからサーバ側パケットを受信すると、前記サーバ側パケットのヘッダ情報に基づいて前記複数のCPUコアのうちから、前記サーバ側パケットの処理を行うものとして、第2指定CPUコアを決定する第2NICと、
     前記第1NICが前記第1指定CPUコアを決定するときの前記クライアント側パケットのヘッダ情報に対するマスクである第1マスク設定を保持する第1マスク保持部と、
     前記第2NICが前記第2指定CPUコアを決定するときの前記サーバ側パケットのヘッダ情報に対するマスクである第2マスク設定を保持する第2マスク保持部と
    を更に備え、
     前記第1マスク設定と前記第2マスク設定は、前記第1NICと前記第2NICがそれぞれ同一の情報に基づいて前記第1、第2指定CPUコアを決定するように設定される
     プロキシ装置。
  3.  請求項2に記載のプロキシ装置であって、
     前記第1マスク設定は、前記クライアント側パケットのヘッダ情報において、送信元ポート番号をマスクするように設定され、
     前記第2マスク設定は、前記サーバ側パケットのヘッダ情報において、送信先ポート番号をマスクするように設定される
     プロキシ装置。
  4.  請求項1に記載のプロキシ装置であって、
     前記プロキシスレッドは、前記第1コネクションと対となる前記サーバとの第2コネクションを確立するときに、前記第1コネクションにおける送信元ポート番号を前記第2コネクションにおける送信元ポート番号に設定する
     プロキシ装置。
  5.  複数のCPUコアを備えるマルチコアCPUと、前記複数のCPUコアの各々の上でカーネルスレッドとプロキシスレッドが動作し、
     前記複数のCPUコアに対してそれぞれ設けられた複数のキューを具備する拡張リッスンソケットと、
    を備えるプロキシ装置において、
     前記カーネルスレッドにより、前記複数のCPUコアのうちの対応するものに割り当てられた、クライアントとの第1コネクションの確立要求パケットの受信処理を行うステップと、
     前記カーネルスレッドにより、前記第1コネクションの情報を含んだ確立待ちソケットを、前記複数のキューのうちの対応するものに登録するステップと、
     前記プロキシスレッドにより前記対応するキューを参照するステップと、
     前記対応するキューに前記確立待ちソケットが登録されている場合に、前記確立待ちソケットに基づいて前記第1コネクションを確立するステップと
    を備える
     プロキシ装置の動作方法。
  6.  請求項5に記載のプロキシ装置の動作方法であって、
     前記クライアントと接続された第1NIC(Network Interface Card)により、前記クライアントからクライアント側パケットを受信するステップと、
     前記第1NICにより、前記クライアント側パケットのヘッダ情報に対して第1マスクを設定するステップと、
     前記第1NICにより、前記クライアント側パケットのマスクされたヘッダ情報に基づいて、前記複数のCPUコアのうちから、前記クライアント側パケットの処理を行うものを、第1指定CPUコアとして決定するステップと、
     サーバと接続された第2NICにより、前記サーバからサーバ側パケットを受信するステップと、
     前記第2NICにより前記サーバ側パケットのヘッダ情報に対して第2マスクを設定するステップと、
      前記第2NICにより、前記サーバ側パケットのマスクされたヘッダ情報に基づいて前記複数のCPUコアのうちから、前記サーバ側パケットの処理を行うものとして、第2指定CPUコアを決定するステップと、
    を更に備える
     プロキシ装置の動作方法。
  7.  請求項6に記載のプロキシ装置の動作方法であって、
     前記第1マスクを設定するステップは、
     前記クライアント側パケットのヘッダ情報の送信元ポート番号をマスクするように前記第1マスクを設定するステップを備え、
     前記第2マスクを設定するステップは、
     前記サーバ側パケットのヘッダ情報の送信先ポート番号をマスクするように前記第2マスクを設定するステップを備える
     プロキシ装置の動作方法。
  8.  請求項5に記載のプロキシ装置の動作方法であって、
     前記プロキシスレッドは、前記第1コネクションと対となる前記サーバとの第2コネクションを確立するときに、前記第1コネクションにおける送信元ポート番号を前記第2コネクションにおける送信元ポート番号に設定するステップ
    を更に備える
     プロキシ装置の動作方法。
  9.  請求項5から請求項8までのいずれかに記載のプロキシ装置の動作方法を実現するための、計算機実行可能なプログラムコードが記録された計算機読み取り可能な固定的な記録媒体。
PCT/JP2011/051421 2010-02-03 2011-01-26 プロキシ装置とその動作方法 WO2011096307A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2011552737A JPWO2011096307A1 (ja) 2010-02-03 2011-01-26 プロキシ装置とその動作方法
US13/200,820 US8612611B2 (en) 2010-02-03 2011-10-03 Proxy apparatus and operation method thereof

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010-022107 2010-02-03
JP2010022107 2010-02-03

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/200,820 Continuation US8612611B2 (en) 2010-02-03 2011-10-03 Proxy apparatus and operation method thereof

Publications (1)

Publication Number Publication Date
WO2011096307A1 true WO2011096307A1 (ja) 2011-08-11

Family

ID=44355307

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/051421 WO2011096307A1 (ja) 2010-02-03 2011-01-26 プロキシ装置とその動作方法

Country Status (3)

Country Link
US (1) US8612611B2 (ja)
JP (1) JPWO2011096307A1 (ja)
WO (1) WO2011096307A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101435500B1 (ko) 2012-10-09 2014-09-11 주식회사 시큐아이 프록시 장치를 제어하는 방법 및 프록시 장치
JP5917678B1 (ja) * 2014-12-26 2016-05-18 株式会社Pfu 情報処理装置、方法およびプログラム
JP2017117448A (ja) * 2015-12-26 2017-06-29 インテル コーポレイション アプリケーションレベルネットワークキューイング
WO2024024270A1 (ja) * 2022-07-28 2024-02-01 株式会社 東芝 サーバ装置、通信装置、及び制御システム

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9069850B2 (en) * 2011-11-08 2015-06-30 Comcast Cable Communications, Llc Content descriptor
CN103501245B (zh) * 2013-09-26 2017-02-08 北京搜狐互联网信息服务有限公司 一种网络事件处理方法及装置
US9628333B2 (en) * 2013-12-04 2017-04-18 International Business Machines Corporation Operating a dual chipset network interface controller (‘NIC’) that includes a high performance media access control chipset and a low performance media access control chipset
US10721160B2 (en) 2014-05-15 2020-07-21 Samsung Electronics Co., Ltd. Method of distributing data and device supporting the same
US10652353B2 (en) 2015-09-24 2020-05-12 Intel Corporation Technologies for automatic processor core association management and communication using direct data placement in private caches
US10083355B2 (en) * 2016-06-24 2018-09-25 Facebook, Inc. Systems and methods for incremental media processing based on utilizing client-side computation
CN111176855B (zh) * 2018-11-09 2023-10-27 微软技术许可有限责任公司 在用户空间中建立线程之间的队列
CN110177047B (zh) * 2019-05-27 2022-03-04 北京字节跳动网络技术有限公司 报文发送方法、装置、电子设备和计算机可读存储介质
CN111031065B (zh) * 2019-12-25 2022-02-11 东软集团股份有限公司 一种文件传输方法、系统、客户端及防火墙
CN113342554B (zh) * 2021-08-02 2022-01-04 阿里云计算有限公司 Io多路复用方法、介质、设备和操作系统
CN114172976B (zh) * 2021-11-11 2024-02-02 北京天融信网络安全技术有限公司 上下游连接关联方法、装置、网络转发设备、系统及介质
CN115297164A (zh) * 2022-07-06 2022-11-04 珠海格力电器股份有限公司 网络代理方法、装置、电子设备及计算机可读存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000101640A (ja) * 1998-09-18 2000-04-07 Mitsubishi Electric Corp クライアント/サーバシステム
JP2005295268A (ja) * 2004-03-31 2005-10-20 Fujitsu Ltd 階層型パケット処理システム、中継装置、サーバ、その方法、及びそのプログラム
JP2007128349A (ja) * 2005-11-04 2007-05-24 Nec Corp ネットワークシステム、プロキシサーバ、セッション管理方法、及びプログラム
JP2007514337A (ja) * 2003-10-10 2007-05-31 サイトリックス システムズ, インコーポレイテッド 信頼性および持続性のある通信セッションを介したクライアントの自動的な再接続
JP2008131584A (ja) * 2006-11-24 2008-06-05 Hitachi Ltd 情報処理装置及び情報処理システム
JP2008129767A (ja) * 2006-11-20 2008-06-05 Mitsubishi Electric Corp ネットワーク装置
JP2008299439A (ja) * 2007-05-29 2008-12-11 Mitsubishi Electric Corp パケット処理装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7562146B2 (en) 2003-10-10 2009-07-14 Citrix Systems, Inc. Encapsulating protocol for session persistence and reliability
US7100200B2 (en) 2001-06-13 2006-08-29 Citrix Systems, Inc. Method and apparatus for transmitting authentication credentials of a user across communication sessions
US7984157B2 (en) 2002-02-26 2011-07-19 Citrix Systems, Inc. Persistent and reliable session securely traversing network components using an encapsulating protocol
US7895431B2 (en) 2004-09-10 2011-02-22 Cavium Networks, Inc. Packet queuing, scheduling and ordering
US8079077B2 (en) 2006-08-08 2011-12-13 A10 Networks, Inc. System and method for distributed multi-processing security gateway
JP2008134775A (ja) 2006-11-28 2008-06-12 Hitachi Ltd 記憶サブシステム及びこれを利用したリモートコピーシステム
JP2009199433A (ja) 2008-02-22 2009-09-03 Fujitsu Ltd ネットワーク処理装置およびネットワーク処理プログラム
US8009682B2 (en) * 2009-05-05 2011-08-30 Citrix Systems, Inc. Systems and methods for packet steering in a multi-core architecture

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000101640A (ja) * 1998-09-18 2000-04-07 Mitsubishi Electric Corp クライアント/サーバシステム
JP2007514337A (ja) * 2003-10-10 2007-05-31 サイトリックス システムズ, インコーポレイテッド 信頼性および持続性のある通信セッションを介したクライアントの自動的な再接続
JP2005295268A (ja) * 2004-03-31 2005-10-20 Fujitsu Ltd 階層型パケット処理システム、中継装置、サーバ、その方法、及びそのプログラム
JP2007128349A (ja) * 2005-11-04 2007-05-24 Nec Corp ネットワークシステム、プロキシサーバ、セッション管理方法、及びプログラム
JP2008129767A (ja) * 2006-11-20 2008-06-05 Mitsubishi Electric Corp ネットワーク装置
JP2008131584A (ja) * 2006-11-24 2008-06-05 Hitachi Ltd 情報処理装置及び情報処理システム
JP2008299439A (ja) * 2007-05-29 2008-12-11 Mitsubishi Electric Corp パケット処理装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101435500B1 (ko) 2012-10-09 2014-09-11 주식회사 시큐아이 프록시 장치를 제어하는 방법 및 프록시 장치
JP5917678B1 (ja) * 2014-12-26 2016-05-18 株式会社Pfu 情報処理装置、方法およびプログラム
JP2017117448A (ja) * 2015-12-26 2017-06-29 インテル コーポレイション アプリケーションレベルネットワークキューイング
WO2024024270A1 (ja) * 2022-07-28 2024-02-01 株式会社 東芝 サーバ装置、通信装置、及び制御システム

Also Published As

Publication number Publication date
JPWO2011096307A1 (ja) 2013-06-10
US8612611B2 (en) 2013-12-17
US20120030364A1 (en) 2012-02-02

Similar Documents

Publication Publication Date Title
WO2011096307A1 (ja) プロキシ装置とその動作方法
EP3675432B1 (en) Intelligent and dynamic overlay tunnel formation via automatic discovery of citrivity/sdwan peer in the datapath in a pure plug and play environment with zero networking configuration
US8671152B2 (en) Network processor system and network protocol processing method
EP2824880B1 (en) Flexible offload of processing a data flow
EP2318926B1 (en) Method and system for low-overhead data transfer
US10146566B2 (en) Enabling virtual desktop connections to remote clients
US7996569B2 (en) Method and system for zero copy in a virtualized network environment
US9473596B2 (en) Using transmission control protocol/internet protocol (TCP/IP) to setup high speed out of band data communication connections
US11611545B2 (en) RDP proxy support in presence of RDP server farm with session directory or broker
JP2009528620A (ja) ハードウェア・デバイスなどのリソースを有する仮想マシンの移動
WO2007002710A1 (en) Offload stack for network, block and file input and output
US20140082180A1 (en) Information processor apparatus, information processing method, and recording medium
WO2013097484A1 (zh) 虚拟机集群的负载均衡方法、服务器及系统
US8819242B2 (en) Method and system to transfer data utilizing cut-through sockets
CN111447155A (zh) 数据传输方法、装置、设备及存储介质
US20050091334A1 (en) System and method for high performance message passing
US8588095B2 (en) Data conversion device and data conversion method
CN107493574B (zh) 无线控制器设备、并行认证处理方法、系统、组网装置
US20120020374A1 (en) Method and System for Merging Network Stacks
US10791088B1 (en) Methods for disaggregating subscribers via DHCP address translation and devices thereof
JP2016162266A (ja) 通信装置及びそのプロセッサ割当方法
KR101577034B1 (ko) 소프트웨어적인 네트워크 부가기능 추가가 용이한 멀티코어 기반의 toe 시스템 및 그 제어 방법
WO2023238326A1 (ja) スイッチ
Neville-Neil Whither Sockets? High bandwidth, low latency, and multihoming challenge the sockets API.
JP5423404B2 (ja) オフロード処理装置、および、通信システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11739656

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011552737

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11739656

Country of ref document: EP

Kind code of ref document: A1