Devices and methods for performing tcp handshakes

The present disclosure relates to computer systems in general, and in particular to performing TCP / IP handshakes in such systems.

This section is intended to introduce the reader to various technical aspects and is relevant to the various aspects of this disclosure described and / or claimed below. This description is believed to assist in providing the reader with background information to facilitate a proper understanding of the various aspects of this disclosure. Therefore, these statements should be read from that point of view and should be understood rather than as a self-confidence of the prior art.

In this description, the term "client" can be used in connection with a TCP client (ie, a device that sends SYN and ACK messages), and the term "server" is a TCP server (ie, device). Can be used in connection with (devices that receive SYN messages). Such a "client" may be a server (such as a web server) in more general terms, and a "server" may be a client such as a web client accordingly. Good things will be acknowledged. It is clear from the context how these terms should be interpreted.

TCP / IP is a very well known communication protocol. To set up a TCP / IP connection between the two devices, the device performs the TCP handshake shown in Figure 1. The first device (referred to as a client) sends a SYN (m) message containing the IP address of the first device and the first integer m to the second device (referred to as a server). When the server accepts the request, it responds with a SYN-ACK (m + 1, n) message to the IP address it receives, which is the second integer n and the first integer m incremented by one. Includes (ie, m + 1) and. After sending a SYN message, the client keeps a record of the SYN message sent and waits for a predetermined period of time; if the corresponding SYN-ACK message is not received before the period expires, it waits. Stop. Upon receiving the SYN-ACK message from the server, the client checks that the SYN-ACK message contains m + 1. If so, it confirms receipt by sending an ACK (n + 1) message to the server that contains the second integer n incremented by one (ie n + 1). The server finally verifies that the ACK message contains n + 1. If the server verification is successful, the handshake has been performed properly since then.

In certain situations where a client attempts to perform a handshake in parallel with multiple servers, it can be problematic that the device must maintain allocated resources during the handshake. For each of the transmitted or received SYNs, the TCP stack begins recording one Transmission Control Block (TCB), each recording requiring hundreds of bytes. No prior predictions have been made regarding network speed during the 3-way handshake. Therefore, TCB records will probably survive for long periods of time and consume resources. To make matters worse, sending a SYN to a device that is not connected or does not respond to the TCP stack wastes resources if it maintains the corresponding TCB for a period of time (timeout duration).

It will be acknowledged that it is hoped that it will provide a solution that overcomes at least some of the problems with TCP handshakes. The present disclosure provides such a solution.

In the first aspect, this principle relates to devices that perform TCP handshakes. The device is an interface configured to send a message between at least one external device and the processor of that device; as well as receiving a SYN-ACK message from that interface, which the device corresponds to. The message has not been sent and the SYN-ACK message contains the source address; generate an ACK message corresponding to the SYN-ACK message; and send the ACK message to the interface for sending to the source address. It has a processor that is configured to do.

Various forms of the first aspect include: The processor is configured to access the TCP stack, which stores a record of the SYN messages sent, and the device sends the corresponding SYN messages as if they were. By patching the TCP stack as if it were, and creating a record corresponding to the corresponding SYN message, the TCP handshake is performed as if the device was sending the corresponding SYN message. Configured to rebuild. Each record contains the sequence number of the SYN message, and the processor is further configured to obtain the sequence number of the corresponding SYN message by subtracting 1 from the corresponding integer in the SYN-ACK message. That is an advantage.

The device further has a firewall configured to intercept the SYN-ACK message and notify the processor of the interception. The processor is further configured to generate the corresponding SYN message sent to the source address and update the TCP stack. The firewall is further configured to intercept the corresponding SYN message generated by the processor and only forward the SYN-ACK message to the processor.

The processor sends a request for data (including the first integer) to the server, receives the data from the server, and utilizes the first integer and the second integer received with the SYN-ACK message. Further configured to confirm that the SYN-ACK message is related to the request.

In the second aspect, this principle relates to a method for performing TCP handshakes. The device processor receives the SYN-ACK message, the device has not sent the corresponding SYN message, the SYN-ACK message contains the source address, and the device processor has the ACK message corresponding to the SYN-ACK message. Is generated and sent to the source address.

Various forms of the second aspect include: The method involves accessing the TCP stack, which stores a record of the SYN messages sent, and as if the device was sending the corresponding SYN message. It also has the step of reconstructing the TCP handshake as if the device was sending the corresponding SYN message by patching the TCP stack and creating a record corresponding to the corresponding SYN message. .. Each record contains the sequence number of the SYN message, and the processor is configured to obtain the sequence number of the corresponding SYN message by subtracting 1 from the corresponding integer in the SYN-ACK message. That is an advantage.

The device further has a firewall configured to intercept the SYN-ACK message and notify the processor of the interception. The processor is further configured to generate the corresponding SYN message sent to the source address and update the TCP stack. The firewall is further configured to intercept the corresponding SYN message generated by the processor and only forward the SYN-ACK message to the processor.

The processor sends a request for data (including the first integer) to the server, receives the data from the server, and utilizes the first integer and the second integer received with the SYN-ACK message. Further configured to confirm that the SYN-ACK message is related to the request.

In the third aspect, the principle relates to a server with a processor, where the processor receives a request for data from the client, the data has parts 1 and 2, and the request is the address of the client. Containing; sending the first part to the client; and sending a TCP handshake SYN message to another device that is configured to provide the second part to the client. Is configured to include the client's address as the source address;

The third aspect forms include that the request contains an integer and that the processor is further configured to send the integer with a SYN message to another device.

In the fourth aspect, the principle relates to a method in the server's processor, in which the method is the step of receiving a request for data from a client, where the data has first and second parts and the request is. A step that includes the client's address; a step that sends the first part to the client; and a step that sends a TCP handshake SYN message to another device that is configured to provide the second part to the client. , SYN message has step; including the address of the client as the source address.

The fourth aspect form comprises that the request contains an integer and that the processor sends the integer to another device with a SYN message.

In the fifth aspect, the principle relates to a non-temporary storage medium for storing instructions, which implements the method of the second aspect when executed by a processor.

Preferred features of this principle will be described in connection with the accompanying drawings by non-limiting examples.<figref num="1">Figure 1 shows a conventional TCP handshake.</figref><figref num="2">Figure 2 shows a system that realizes this principle.</figref><figref num="3">Figure 3 shows how to perform a TCP handshake on a device according to this principle.</figref>

Figure 2 shows a system 200 that realizes this principle. The system 200 has an initiator device (or starting device) 210, at least one server device (or server device) 220, and at least one terminator device (or terminating device) 230. Although only a few devices are shown, each of these devices 210, 220, 230 has at least one handshake processing unit (processor) 211, 231, memories 212, 232, and at least one communication interface (I). With / O) 213, 233, the communication interface is configured to communicate messages from other devices to the processor and from the processor to other devices. Terminator device 230 can also include firewall 234, which is optionally implemented in processor 231 or in another processor (not shown). Those skilled in the art will recognize that the devices shown are very simplified for the sake of brevity and that the actual devices have additional functions such as internal connectivity and power supply. The processor is configured to execute instructions (in some cases, at least partially stored in memory) for handling messages, performing calculations, etc., as described herein. .. A non-temporary storage medium (not shown) stores the instructions, which, when executed by the processor, perform a TCP handshake method on the terminator device as described herein.

To perform a TCP handshake, the initiator device 210 initiates it by sending a SYN (m) message 240 to the server 220. The SYN message contains the first integer m and, unlike the standard traditional handshake, the IP address of the terminator device. After this, the initiator device 210 can forget everything about the SYN message 240 sent; it is not useful for the initiator device 210 to save the TCB, because the initiator device has any corresponding SYN-ACK. This is because the message will not be received either. For example, in one embodiment particularly suitable for monitoring many server devices, the initiator device 210 selects a source address from among the network addresses of the (plural) terminator devices in order to balance the load between the terminator devices. It is possible; therefore, for the terminator device, it is useful to provide the initiator device with feedback on their load.

The server 220 reacts like a traditional server, i.e., with a corresponding SYN-ACK message (m + 1, n) containing m + 1 and a second integer n. Server 220 sends a response to the source IP address of SYN message 240 because server 220 considers it to be the source IP address of SYN-ACK message 240. It should be noted.

The terminator device 230 that receives the SYN-ACK message does not store the corresponding TCB, which means that the SYN-ACK message is the first contact for a TCP handshake. The terminator device 230 then needs to build a TCP handshake (again) as if it was sending the original SYN message 240. This can be done in a variety of ways and two examples are given below.

The first method is to patch the TCP stack by setting the TCP state machine to "ESTABLISHED" and rebuilding the TCB using the sequence number corresponding to the first integer m. To apply. The sequence number is easily calculated by subtracting 1 from the incremented integer received in the SYN-ACK message 250, i.e. by calculating (m + 1) -1. In general, the TCP stack also maintains a timestamp of SYN message 240; this timestamp may be rebuilt using the time prior to the receipt of SYN-ACK message 250. The advantage of this method is that it is lightweight, but on the other hand it can be complicated by patching TCP code.

The second method is to intercept (receive) the SYN-ACK message 250 by using the firewall 234 in the terminator device 230, and notify the functional part of the terminator device 230 of the reception. The functional part generates a corresponding SYN (m) message that is sent to server 220 but intercepted by the firewall, which only forwards the SYN-ACK message 250 to the TCP stack. The advantage of this method is that the TCP stack is not modified, but it requires additional resources such as firewalls and functional parts.

The TCP stack can be stored in the processor, in memory, or a combination thereof if the processor has sufficient resources to store it. In any case, the processor has access (rights) to the TCP stack.

And the terminator device 230<u style="single">ACK</u>(n + 1) Send message 260 to server 220, after which handshake ends.

Figure 3 shows how to perform a TCP handshake on a terminator device according to this principle. Terminator device 230 does not store any TCB for future TCP handshakes; in other words, it is not sending a start SYN message, and is not even aware that such a message was sent. May be good.

In step S310, the communication interface of the terminator device receives a SYN-ACK (m + 1, n) message from the server. In step S320, the terminator device reconstructs the TCP handshake, for example, using one of the two methods described above, as if it were sending the original SYN message. Then, the terminator device is set in step S330.<u style="single">ACK</u>(n + 1) Send a message to the server, after which the handshake ends.

This principle may be used in remote monitoring devices such as gateways and mobile phones. Traditional solutions to such monitoring encounter problems primarily due to a large number of devices (hundreds of thousands to millions), because the monitoring server sends each device to which a SYN message is sent. This is because resources are allocated to. The main traditional solution is horizontal scaling, that is, adding a monitoring server (correspondingly) as a function of the number of devices to be monitored. The cost of scaling is linear at best, but it usually requires external infrastructure.

It will be recognized that this principle can at least partially overcome the problem. The initiator device does not maintain any state, does not store any TCB, and they do not need to allocate resources to each monitored device (except for the resources needed to send a SYN message). Means. The monitored device operates in the conventional manner as described above. Ultimately, the terminator device (usually more than one in this example) only needs to allocate resources to the monitored device when receiving a SYN-ACK message. Therefore, there is no need to allocate resources to devices that do not respond for any or other reason.

This principle may be used when a client, such as a web browser, requests a web page with information provided by various providers. A prime example of such a web page is the front page of an online newspaper, which contains advertisements served by various advertising providers apart from the news articles provided by the newspaper itself.

It will be acknowledged that this principle can also be used in the following examples. When a client requests a web page from the server, the server acts as an initiator device and provides tracking, advertising, caching, embedded content, etc. to the requested web page. It is possible to send SYN messages to third party servers. The server spoofs the source addresses of these SYN messages, making the SYN messages appear to come from the client. Third party servers operate according to normal TCP handshakes, i.e. they "respond" with SYN-ACK messages sent to clients. Then, when receiving the SYN-ACK message, the client acts like a terminator device, i.e. reconnects the TCP connection and sends the SYN message to a third party server.

It is useful to take advantage of features similar to SYN-cookies: the client's request has an integer, which the server wants to include in the SYN-ACK message sent to the client. Transferred to a third-party server. In this way, the client can verify that the SYN-ACK message received is related to the web page request. The third party server may include the integer as is, but may process the integer before including it, for example by incrementing the integer (as was done for the integer in the SYN message). In any case, the received integer allows confirmation that the SYN-ACK message is related to the request.

The advantage of this is that it allows for faster connections, because it speeds up the connection between the client and the third party server, and the server initiates a TCP handshake. This is because the client does not have to wait for information about the third party server in the web page in some cases. It is advantageous for the client to notify the server, for example, in a request that it is possible to handle the modified TCP handshake, because devices that cannot work that way are SYN-from a third party server. This is because it simply rejects the ACK message.

It will be acknowledged that this principle provides a TCP handshake that can improve the traditional TCP handshake, at least in certain circumstances.

The claims and (if appropriate) claims and each feature disclosed in the drawings may be provided independently or in any suitable combination. Features described as being realized in hardware may be realized in software and vice versa. When the reference numbers appear in the claims, they are merely examples and have no limitation of effect on the claims.<u style="single">[Appendix 1]</u><u style="single"> A device that performs TCP handshakes:</u><u style="single"> Interface means for sending messages between at least one external device and the processing means of that device;</u><u style="single"> Receiving a SYN-ACK message from the interface, the device has not sent the corresponding SYN message, and the SYN-ACK message contains the source address;</u><u style="single"> Generate an ACK message corresponding to the SYN-ACK message;</u><u style="single"> Processing means for sending the ACK message to the interface for transmission to the source address;</u><u style="single"> Device with.</u><u style="single">[Appendix 2]</u><u style="single"> A means of accessing the TCP stack, which stores a record of transmitted SYN messages,</u><u style="single"> By patching the TCP stack as if the device was sending the corresponding SYN message and creating a record corresponding to the corresponding SYN message, the device said the corresponding SYN message. As if the TCP handshake was being reconstructed, as if it had been sent.</u><u style="single"> The device according to Appendix 1, further comprising.</u><u style="single">[Appendix 3]</u><u style="single"> Each record contains the sequence number of the SYN message, and the device further has means to obtain the sequence number of the corresponding SYN message by subtracting 1 from the corresponding integer in the SYN-ACK message. , The device described in Appendix 2.</u><u style="single">[Appendix 4]</u><u style="single"> Further, a firewall means for intercepting the SYN-ACK message and notifying the processor of the intercept, a means for generating the corresponding SYN message sent to the source address, and a means for updating the TCP stack. Have and</u><u style="single"> The device according to Appendix 1, wherein the firewall means only intercepts the corresponding SYN message generated by the processor and transfers the SYN-ACK message to the processor.</u><u style="single">[Appendix 5]</u><u style="single"> A means of sending a request for data to a server, wherein the request contains a first integer;</u><u style="single"> Means of receiving data from the server; and</u><u style="single"> A means of confirming that the SYN-ACK message is relevant to the request by utilizing the first integer and the second integer received with the SYN-ACK message;</u><u style="single"> The device according to Appendix 1, further comprising.</u><u style="single">[Appendix 6]</u><u style="single"> A way to perform TCP handshakes on your device:</u><u style="single"> Receiving a SYN-ACK message by means of receiving, said device has not sent a corresponding SYN message, and said SYN-ACK message contains a source address;</u><u style="single"> Generate an ACK message corresponding to the SYN-ACK message by the generation and transmission means and send it to the source address;</u><u style="single"> Method to have.</u><u style="single">[Appendix 7]</u><u style="single"> Accessing the TCP stack, which stores a record of transmitted SYN messages, and</u><u style="single"> By reconstructing means, the device patches the TCP stack as if the device had transmitted the corresponding SYN message, and creates a record corresponding to the corresponding SYN message so that the device Rebuilding the TCP handshake and reconstructing the TCP handshake as if it was sending the corresponding SYN message.</u><u style="single"> The method according to Appendix 6, which further comprises.</u><u style="single">[Appendix 8]</u><u style="single"> Each record contains the sequence number of the SYN message.</u><u style="single"> The method according to Appendix 7, wherein the acquisition means further comprises acquiring the sequence number of the corresponding SYN message by subtracting 1 from the corresponding integer in the SYN-ACK message.</u><u style="single">[Appendix 9]</u><u style="single"> Intercepting the SYN-ACK message by firewall means;</u><u style="single"> Notifying the processor of the intercept by the firewall means;</u><u style="single"> Generate the corresponding SYN message by the SYN message generation means;</u><u style="single"> Sending the corresponding SYN message to the source address by means of sending a SYN message;</u><u style="single"> Updating the TCP stack by update means;</u><u style="single"> Intercepting the corresponding SYN message generated by the processor by the firewall means;</u><u style="single"> Transferring the SYN-ACK message to the processor by the firewall means;</u><u style="single"> The method according to Appendix 6, which further comprises.</u><u style="single">[Appendix 10]</u><u style="single"> Sending a request for data to a server by means of request sending, said request containing a first integer;</u><u style="single"> Receiving data from the server by data receiving means;</u><u style="single"> Confirm that the SYN-ACK message is related to the request by using the first integer and the second integer received together with the SYN-ACK message by the confirmation means;</u><u style="single"> The method according to Appendix 6, which further comprises.</u><u style="single">[Appendix 11]</u><u style="single"> A means of receiving a request for data from a client, wherein the data has a first part and a second part, and the request includes the address of the client;</u><u style="single"> Means of transmitting the first part to the client; and</u><u style="single"> Means of sending a TCP handshake SYN message to another device configured to provide said second part to said client, said said SYN message containing the address of said client as a source address;</u><u style="single"> Server with.</u><u style="single">[Appendix 12]</u><u style="single"> 11 The server of Appendix 11, wherein the request comprises an integer, wherein the server further comprises means of transmitting the integer to the other device with the SYN message.</u><u style="single">[Appendix 13]</u><u style="single"> The method on the server:</u><u style="single"> Receiving a request for data from a client by means of receiving, wherein the data has a first part and a second part, and the request includes the address of the client;</u><u style="single"> Sending the first part to the client by means of the first part transmitting means;</u><u style="single"> The SYN message sending means is to send a TCP handshake SYN message to another device configured to provide the second part to the client, the SYN message source address of the client. Include as, send;</u><u style="single"> Method to have.</u><u style="single">[Appendix 14]</u><u style="single"> 13. The method of Appendix 13, wherein the request comprises an integer, the method further comprising transmitting the integer with the SYN message to the other device by the SYN message transmitting means.</u><u style="single">[Appendix 15]</u><u style="single"> A non-temporary storage medium for storing an instruction, wherein the instruction executes the method according to any one of Supplementary note 6 to 10 when executed by a processor.</u>