JP2010183553A - Network device and method for processing packet communication - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a network device and a method for processing packet communication. <P>SOLUTION: The TCP-based network device serves as an HTTP proxy which is interposed between a client and a web server. In order to solve the problem that non-HTTP services can not be provided for the port 80, a port exclusively for HTTP, the network device forwards TCP 3-way handshaking packets which are transmitted from the client to generate a TCP connection to a destination server without performing latency binding function processing and subsequently relay transmits the transmitted non-HTTP packets simply between the client and the destination server. In this manner, the problem that services not based on the HTTP are not provided is solved and the service quality can be further improved. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a network device, and more particularly, to a TCP-based network device that functions as an HTTP proxy interposed between a client and a web server.

  Equipment for network control or control on the network may be interposed between the client and the server. However, the presence of such a device such as a firewall or a load balancing switch sometimes causes a failure in communication between the client and the server.

  The present invention is derived from such a background, and an object of the present invention is to provide a network device and a packet communication processing method that prevent a network device from stopping a specific service for non-HTTP traffic.

  The technical problem is that a non-HTTP packet transmitted from a client is forwarded to a port 80, which is an HTTP-dedicated port provided in a network device, to a destination server, and thereafter the client or the destination server. It is achieved by a network device characterized by having a communication setting option for simply relaying and transmitting a packet input from the client and the destination server.

  At this time, the network device simply transmits a TCP 3-way handshaking packet transmitted to generate a TCP connection from the client, without executing a delayed binding function process. And relay transmission.

  On the other hand, the technical problem is to receive a non-HTTP packet transmitted from a client to 80 ports that are dedicated HTTP ports of a network device, and forward the received non-HTTP packet to a destination server. (Forwarding: retransmission), and after forwarding, the packet input to the port 80 from the client or the destination server is simply relayed between the client and the destination server. It is also achieved by a packet communication processing method of a network device characterized in that it is included.

  In the method, if a TCP handshaking packet transmitted to generate a TCP connection is received from the client before the step of receiving the non-HTTP packet, the TCP handshaking process is not performed without performing the delayed binding function process. Relaying a shaking packet to a service server; and relaying a response packet of the service server to the TCP handshaking packet between the service server and the client.

  ADVANTAGE OF THE INVENTION According to this invention, the problem that a specific service is not provided by the network apparatus introduce | transduced for the purpose of load distribution can be solved, and service quality can be improved more.

1 is a diagram schematically showing an example of a network configuration including a network device. It is a data flowchart for demonstrating the packet communication processing process of a network device. It is a data flowchart which shows the packet communication processing method with the network device which concerns on one Embodiment of this invention. 4 is a data flowchart for explaining a client push process of a non-HTTP packet in the network system according to the embodiment of the present invention. 4 is a data flowchart for explaining a server push process of a non-HTTP packet in a network system according to an embodiment of the present invention.

  The foregoing and additional aspects of the present invention will become more apparent through the preferred embodiments described with reference to the accompanying drawings. In the following, the present invention will be described in detail so that those skilled in the art can easily understand and reproduce through such embodiments.

  FIG. 1 is a diagram schematically illustrating an example of a network configuration including a network device 20. The client (client side communication device) 10 transmits data processed by the service server 30 or the cache server 40. The network device 20 performs switching based on the content of the traffic transmitted from the client 10 and transmits it to the service server (destination side communication device) 30 and the cache server (destination side communication device) 40.

  For communication between the client 10 and the service server 30, when the client 10 first transmits data to the service server 30, that is, in the case of client push (Client-push), the service server 30 first transfers the data to the client 10. There is a case of server push (Server-push) for transmitting data. For example, the protocol used in the case of client push includes HTTP, SSL (Secure Socket Layer), Skype (registered trademark), and the protocol used in the case of server push includes FTP (File Transfer Protocol), SMTP (Simple). Mail Transfer Protocol), POP3 (Post Office Protocol Version 3), IMAP (Internet Message Access Protocol), Telnet, and the like. Generally, before the client 10 or the service server 30 first requests data transmission, the other party enters a standby state until receiving the expected data.

  At this time, in order to support a hypertext transfer protocol (Hypertext Transfer Protocol: hereinafter referred to as HTTP) request transmitted from the client 10, the network device 20 transmits traffic through a session destined for an HTTP dedicated port (80 ports). Receive.

  FIG. 2 is a flowchart for explaining the packet communication process of the network device 20.

  The client 10 first undergoes a TCP handshaking process in order to prepare for communication with the network device 20. This is a process for confirming whether the network device 20 is communicable with the TCP base in order to execute communication with the TCP base protocol, and performing a TCP connection with the network device 20. Specifically, when the client 10 transmits a packet asking whether the network device 20 is ready for connection, that is, a SYN (synchronize) packet (S200), the network device 20 is currently ready for connection. Then, a packet asking whether it is ready to be sent to the client 10, that is, a SYN / ACK (acknowledge response) packet is transmitted (S202). Next, the client 10 transmits a packet informing that the message transmission preparation is ready, that is, an ACK packet to the network device 20 (S204).

  Thereafter, the network device 20 determines the service server 30 that provides the actual service according to the content of the HTTP request (HTTP req.) Received after receiving the HTTP packet from the client 10 (S210), and the service server 30 and TCP handshaking (S220, S222). Here, the HTTP request (HTTP req.) Packet is a request message in which actual contents desired by the client 10 to receive the web service are set.

  In order to understand the content of the web service request desired by the user of the client 10 in the network device 20, a procedure based on such TCP handshaking must be passed. That is, after the stage of transmitting / receiving SYN, SYN / ACK, and ACK packets, the content of the web service request actually desired by the user of the client 10 is known.

  Then, in order to determine the service server 30 that provides the service, the network device 20 must know the content of the service requested by the user of the client 10. Therefore, the network device 20 does not proceed with TCP handshaking with any web server (service server 30) for connection until the service server 30 is determined. This is referred to as delayed binding. That is, when the content of the web service request is actually received from the client 10, the network device 20 analyzes the content for the first time, determines the service server 30 that provides the service, and actually executes the connection procedure. The network device 20 transmits an HTTP request (HTTP req.) Packet to the determined service server 30 (S230). The service server 30 transmits an HTTP response (HTTP resp.) Packet with respect to the HTTP request (HTTP req.) Packet to the client 10 (S235).

  Further, the network device 20 performs TCP handshaking with the cache server 40 when transmission to the cache server 40 is necessary depending on the content of the HTTP request (HTTP req.) Packet received from the client 10 (S240). (S250, S255). Then, the network device 20 transmits an HTTP request (HTTP req.) Packet to the cache server 40 (S260). The cache server 40 transmits an HTTP response (HTTP resp.) Packet for the HTTP request (HTTP req.) Packet to the client 10 (S265).

  After the TCP handshaking is completed between the client 10 and the network device 20, if the network device 20 receives an HTTP request (HTTP req.) Packet from the client 10 (S270), the network server 20 performs the TCP handshaking with the service server 30. Without executing, the HTTP request (HTTP req.) Packet received from the client 10 is immediately transmitted to the service server 30 (S272). Then, the service server 30 transmits an HTTP response (HTTP resp.) Packet with respect to the HTTP request (HTTP req.) Packet to the client 10 (S274).

  On the other hand, after the TCP handshaking is completed between the client 10 and the network device 20, if protocol data other than HTTP is received at the 80 port of the network device 20, the network device 20 transmits an erroneous HTTP packet. It recognizes that it has been received, and does not execute the relay of the erroneous HTTP packet, but transmits “400 Bad Request” to the client 10. Then, the network device 20 does not transmit an erroneous HTTP packet to the service server 30. That is, when a non-HTTP packet is received for 80 ports that are HTTP dedicated ports provided in the network device 20, client push is not possible.

  Further, when the service server 30 that provides the web service requested by the client 10 does not exist or when the service server 30 fails and communication is not possible, there is no way for the client 10 to immediately know such a failure state. . Even if the TCP handshaking is not normally performed between the network device 20 and the service server 30 because the TCP handshaking has already been normally performed between the client 10 and the network device 20, the client 10 may An HTTP request (HTTP req.) Packet is sent to the terminal and a response is awaited. In this case, the network device 20 sends a “503 Service Unavailable response” to the client 10 to inform that a failure has occurred, but time and network resources are wasted in this process.

  In addition, the network device 20 selects the service server 30 after actually receiving the HTTP packet from the client 10, and performs TCP handshaking with the service server 30 to confirm whether it is ready for communication. Can do. For this reason, the service server 30 having no history of receiving an HTTP packet from the client 10 cannot determine whether or not the client 10 is ready for communication. Therefore, in this case, server push is also impossible. As a result, when a non-HTTP packet is input to the network device 20, there is a problem that HTTP communication based on the TCP base cannot be normally executed for the corresponding specific service.

  Applicant has long-term analysis of the cause of failure in communications where the reason is not known in a network where there is a firewall or load balancing switch, especially in non-HTTP communication such as FTP and e-mail services. As a result, in the non-HTTP protocol processing process through an abnormal 80 port such as non-HTTP communication from the client, the above-mentioned features (HTTP request (HTTP) (layer 7: application layer)) are equipped. req.) Packet based communication procedure) has been found to cause problems.

  Actually, there is a case where a firewall (Fire Wall) is provided between the client 10 and the network device 20 in order to prevent harmful traffic transmission. At this time, the user of the client 10 has a firewall (Fire Wall). For the purpose of avoiding the problem, it has been recognized that there are cases where protocol data other than HTTP is set as a destination port to 80 ports which are dedicated HTTP ports.

  The present invention is for solving such problems, and the embodiment of the present invention for solving such technical problems will be described in more detail below.

  FIG. 3 is a data flowchart illustrating a packet communication processing method executed in the network device 300 according to an embodiment of the present invention.

  The network device 300 according to an embodiment of the present invention includes a dedicated port corresponding to a specific communication protocol, forwards a request packet corresponding to another communication protocol input to the dedicated port, and is input thereafter. Configuration option to simply relay packets to the other party.

  Here, the specific communication protocol is HTTP, and the dedicated port corresponding to the specific communication protocol is 80 ports. The network apparatus 300 according to the present embodiment realizes communication for transmitting a non-HTTP packet such as SSL or Skype (registered trademark) input from the client 10 to the 80 port to the service server 30.

  Thereafter, the network device 300 simply does not execute a process related to L7 (layer 7: application layer) such as load distribution and security for a packet input from the client 10 and simply transmits the packet. Realize communication relayed to the other party.

  Further, according to an additional aspect, the network device 300 according to the embodiment does not execute the delay binding function process on the TCP handshaking packet input from the client 10 to the dedicated port of the specific protocol for the pre-communication process. It is characterized by simply relaying to the other party.

  When the network device 300 receives from the client 10 a packet asking whether it is ready for connection, that is, a SYN packet (S300), whether the client 10 is currently ready for connection and ready to send to the client 10. Before transmitting the packet for inquiring the request, that is, the SYN / ACK packet to the client 10, the packet for inquiring whether the connection is ready, that is, the SYN packet is transmitted to the service server 30 (S302).

  Then, the network device 300 receives a packet from the service server 30 that is ready for connection and asks whether a transmission message is prepared, that is, a SYN / ACK packet (S304), and sends the SYN / ACK packet to the client. 10 (S306). In addition, when receiving a packet indicating that the message transmission preparation is completed, that is, an ACK packet from the client 10 (S308), the network device 300 transmits the ACK packet to the service server 30 (S309). In other words, the TCP handshaking is not performed between the network device 20 and the service server 30 until the network device receives an actual HTTP request (HTTP req.) Packet from the client 10 conventionally. According to the embodiment of the present invention, in the network device 300, TCP handshaking with the client 10 is executed, and at the same time, TCP handshaking with the service server 30 is executed.

  With this TCP handshaking operation, when the network device 300 receives an HTTP request (HTTP req.) Packet from the client 10 (S310), it can immediately transmit it to the service server 30 (S312). The service server 30 transmits an HTTP response (HTTP resp.) Packet corresponding to the HTTP request (HTTP req.) Packet to the client 10 (S316).

  On the other hand, when the network device 300 understands the content of the HTTP request (HTTP req.) Packet received from the client 10 (S320) and determines that transmission to the cache server 40 is necessary, the network device 300 TCP handshaking is performed in between (S322, S324). Then, the network device 300 transmits an HTTP request (HTTP req.) Packet to the cache server 40 (S326). The cache server 40 transmits an HTTP response (HTTP resp.) Packet corresponding to the HTTP request (HTTP req.) Packet to the client 10 (S328).

  FIG. 4 is a data flowchart for explaining a client push process of a non-HTTP packet executed in the network system according to the embodiment of the present invention.

  First, TCP handshaking for executing communication between the client 10, the network device 300, and the service server 30 is executed.

  When the network device 300 receives from the client 10 a packet asking whether it is ready for connection, that is, a SYN packet (S300), whether the client 10 is currently ready for connection and ready to send to the client. Before transmitting the packet for inquiring about the packet, that is, the SYN / ACK packet, the packet for inquiring whether the connection is ready, that is, the SYN packet is transmitted to the service server 30 (S302).

  Then, the network device 300 receives a packet from the service server 30 that is ready for connection and asks whether a transmission message is prepared, that is, a SYN / ACK packet (S304), and sends the SYN / ACK packet to the client. 10 (S306). Further, the network device 300 receives from the client 10 a packet notifying that preparation for message transmission is completed, that is, an ACK packet (S308), and transmits the ACK packet to the service server 30 (S309). That is, unlike the conventional case where TCP handshaking is not performed between the network device 20 and the service server 30 until an actual HTTP request (HTTP req.) Packet is received, According to the embodiment, the network device 300 performs TCP handshaking with the client 10 and also performs TCP handshaking with the service server 30.

  Then, the network device 300 receives a non-HTTP packet from the client 10 (S400). At this time, when the network device 300 receives a non-HTTP packet that is not an HTTP packet at the HTTP dedicated port (80 port), the network device 300 does not perform a separate process such as load balancing or security processing, but the non-HTTP packet. The packet is transmitted to the service server 30 (S405). Thereafter, the network device 300 immediately forwards the packet transmitted between the client 10 and the service server 30 to the other party without executing any separate processing (S410).

  If the service server 30 that provides the web service requested by the client 10 does not exist or if the service server 30 fails and communication cannot be performed normally, the service server 30 communicates with the network device 300. A packet that is currently ready for connection, that is, a SYN / ACK packet (S304) cannot be transmitted. In this case, TCP handshaking fails between the client 10 and the network device 300 and between the network device 300 and the service server 30. Then, by applying the communication protocol shown in FIG. 4 described above, the client 10 knows that a failure has occurred in the service server 30 before transmitting the HTTP request (HTTP req.) Packet. Therefore, it is possible to prevent time and network resources that may be generated when the client 10 transmits an HTTP request (HTTP req.) Packet to the network device 300 without knowing that the service server 30 has failed.

  FIG. 5 is a data flowchart for explaining a server push process of a non-HTTP packet executed in the network system according to the embodiment of the present invention.

  When the network device 300 receives from the client 10 a packet asking whether it is ready for connection, that is, a SYN packet (S300), whether the client 10 is currently ready for connection and ready to send to the client. Before transmitting the packet for inquiring about the packet, that is, the SYN / ACK packet, the packet for inquiring whether the connection is ready, that is, the SYN packet is transmitted to the service server 30 (S302).

  Then, the network device 300 receives a packet from the service server 30 that is ready for connection and asks whether a transmission message is prepared, that is, a SYN / ACK packet (S304), and sends the SYN / ACK packet to the client. 10 (S306). Further, the network device 300 receives from the client 10 a packet informing that message preparation is complete, that is, an ACK packet (S308), and transmits the ACK packet to the service server 30 (S309). According to an embodiment of the present invention, the network device 300 performs TCP handshaking with the client 10 and also performs TCP handshaking with the service server 30.

  The network device 300 can receive a non-HTTP packet from the service server 30. Conventionally, until the network device 300 receives an HTTP packet from the client 10, TCP handshaking is not performed between the network device 300 and the service server 30, so the service server 30 connects the client 10. It was impossible to recognize the condition. However, the network device 300 according to the embodiment of the present invention performs TCP handshaking with the client 10 without executing the delayed binding function processing, and at the same time, with the service server 30, TCP Server push is possible to perform handshaking.

  Then, the network device 300 receives a non-HTTP packet from the service server 30 (S500). At this time, when the network device 300 receives a non-HTTP packet that is not an HTTP packet at the HTTP dedicated port (80 port), the network device 300 does not execute a separate process such as load distribution or security processing to the service server 30. -An HTTP packet is transmitted (S505). Thereafter, the network device 300 simply transmits the non-HTTP packet to the non-HTTP packet without performing any processing such as load distribution or security on the non-HTTP packet transmitted between the client 10 and the service server 30. (Forwarding: retransmission) (S510).

  The packet communication processing method described above can be created as a computer program. Further, this program can be realized by being stored in a computer readable information recording medium (computer readable media), being read and executed by the computer. This recording medium includes a magnetic recording medium, an optical recording medium, and the like.

  The present invention has been described above with a focus on preferred embodiments. Those skilled in the art will appreciate that the present invention can be embodied as a modified form without departing from the essential characteristics of the present invention. Accordingly, the disclosed embodiments are to be considered in an illustrative, not a limiting sense. The scope of the present invention is expressed in the claims, and all differences within the equivalent scope should be construed as being included in the present invention.

DESCRIPTION OF SYMBOLS 10 ... Client, 30 ... Service server, 40 ... Cache server, 300 ... Network apparatus.

Claims (6)

  A dedicated port corresponding to a specific communication protocol is provided, a packet transmitted from a client side communication device is received at the dedicated port, the received packet is retransmitted to a destination side communication device, and after the retransmission, the A communication setting option for receiving a packet transmitted from the client side communication device or the destination side communication device at the dedicated port, and relaying the received packet between the client side communication device and the destination side communication device. A network device comprising:   80, which is a dedicated port corresponding to HTTP, receives the non-HTTP packet transmitted from the client side communication device at the 80 port, retransmits the non-HTTP packet to the destination side communication device, After transmission, a packet transmitted from the client side communication device or the destination side communication device is received by the dedicated port, and the received packet is relayed between the client side communication device and the destination side communication device. A network device having a communication setting option.   Receiving a TCP handshaking packet transmitted to execute a TCP connection from the client-side communication device, and relaying the TCP handshaking packet to the destination-side communication device without executing a delayed binding function process; The network device according to claim 2. Receiving a packet transmitted from a client-side communication device at a dedicated port corresponding to a specific communication protocol;
Retransmitting the received packet to a destination communication device;
After the retransmission, the packet input from the client side communication device or the destination side communication device to the dedicated port is relayed between the client side communication device and the destination side communication device. And a packet communication processing method. Receiving a non-HTTP packet transmitted from the client-side communication device at a dedicated port corresponding to HTTP;
Retransmitting the received non-HTTP packet to a destination communication device;
A step of relaying a packet input to the 80 port from the client side communication device or the destination side communication device after the retransmission, between the client side communication device and the destination side communication device; And a packet communication processing method. Before receiving the non-HTTP packet,
If a TCP handshaking packet transmitted to execute a TCP connection from the client side communication device is received at the 80 port, the TCP handshaking packet is transmitted to the destination side communication without executing a delayed binding function process. Relaying to the device;
A step of relaying a response packet transmitted from the destination communication device to the TCP handshaking packet between the destination communication device and the client communication device. The packet communication processing method according to claim 6.