WO2015167375A1

WO2015167375A1 - Method and tcp proxy for supporting communication between a client device and a server node

Info

Publication number: WO2015167375A1
Application number: PCT/SE2014/050531
Authority: WO
Inventors: Dan Mathiasen; Thorsten Herber; Johan Svedberg; Robert Skog
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2014-04-30
Filing date: 2014-04-30
Publication date: 2015-11-05

Abstract

A method and TCP proxy (404) for supporting a TCP communication between a client device (400) and a server node (402). When the TCP proxy (404) intercepts a synchronization packet sent from the client device (400) and addressed to the server node, it initiates a first handshake procedure with the server node (402) prior to completing a second handshake procedure with the client device (400). The TCP proxy (404) then performs simultaneously the first handshake procedure to establish a TCP connection between the TCP proxy and the server node (402) and the second handshake procedure to establish a TCP connection between the TCP proxy and the client device (400).

Description

METHOD AND TCP PROXY FOR SUPPORTING COMMUNICATION BETWEEN A CLIENT DEVICE AND A SERVER NODE

Technical field

The present disclosure relates generally to a method and a Transmission Control Protocol, TCP, proxy for supporting a TCP communication between a client device and a server node.

Background

The Transmission Control Protocol, TCP, is a commonly used protocol for communication of data over IP-based networks such as the Internet. The protocol is connection-oriented and transmits data in a controlled and reliable fashion. TCP is often used for transmitting data in packets from one end-point, e.g. a client device, to another opposite end-point, e.g. a server node. An example of a TCP communication between two end-points is schematically illustrated in Fig. 1 .

When an application 100a, running on an operating system of one TCP end-point, e.g. a client device 100, wants to send data to an opposite TCP end-point, e.g. a server node 102, the application builds up a buffer 100b with the data to send and hands the data in the buffer to an operating system kernel 100c. The operating system kernel 100c includes a Transmission Control Protocol/Internet Protocol, TCP/IP, stack 100d where the communication of the data in TCP packets is executed. The server node 102 likewise comprises an application 102a and a

TCP/IP stack 102d. Data is thus communicated from TCP/IP stack 100d to TCP/IP stack 102d as indicated by dashed arrows. The application 100a can now be assured that the data will be delivered to the opposite TCP end point 102. If a transmitted TCP packet is lost or received incorrectly, which may be indicated by non-acknowledgement from the opposite TCP end point 102, the TCP/IP stack 100d in the operating system kernel 100c is responsible for re-transmitting the missing TCP packet. TCP provides functions to detect transmission errors and tampering of data, to mention a few examples. TCP is commonly used also as a carrier for other protocols, such as the Hyper-Text Transfer protocol, HTTP. A significant performance metric for TCP communication is the Round-Trip Time, RTT, which is the time it takes between sending a TCP packet and receiving an acknowledgement on that TCP packet. It may be a drawback that the RTT is too long such that one or both of the TCP end points 100, 102 experience unwanted delays in the communication. For example, a user of a client device may browse the Internet and frequently request for web pages from a server node, where a web page may contain a considerable number of objects, each object having a separate web address such as a Uniform Resource Locator, URL. In that case, the TCP/IP stack in the client device need to retrieve each object from the server separately involving establishment of a TCP communication for each web address, before a complete web page has been retrieved and can be displayed at the client device. Even if the RTT for one session amounts to just a few milliseconds, the total waiting time for retrieving such a web page with all its objects may be substantial. The user may therefore experience the browsing as being "slow", e.g. when retrieving a succession of web pages which is a common browsing behavior. It is therefore a problem to reduce the time it takes to establish a TCP connection between two TCP end points such as the client device 100 and the server node 102.

As indicated above, when a TCP end-point intends to transmit data to another TCP end-point, a TCP connection must be established between the TCP end- points. For example, a client device may send a request for a web page using HTTP or other resource to a server node. A TCP connection can be seen as a bidirectional data channel. A bi-directional TCP connection is typically established using a 3-step handshake procedure as follows. 1 ) The client device 100 sends a synchronize packet, which is a TCP packet with the SYN flag set. This packet is referred to as "SYN" for short. The synchronize packet is addressed to a port in the server node.

2) The server node 102 checks that the addressed port is being monitored, or "listened" to. If so, the server node 102 acknowledges the SYN by raising the ACK flag in a response packet and also sets the SYN flag in the response packet to synchronize the connection in the other direction.

3) The client device 100 receives the response packet containing the SYN, ACK flags and returns an ACK packet to acknowledge the SYN. The bi-directional TCP connection is now established and can be used to transmit data by either of the end-points 100, 102.

A TCP proxy is a functional node that is used in communication networks for establishing and controlling TCP connections between different end-points. The TCP proxy is thus an intermediate network node between two end-points with functionality for controlling the TCP communication, e.g. acting as a firewall for the network, and it is also referred to as an intercepting TCP proxy. For each TCP communication between two end-points, the TCP proxy establishes two

communication "legs" including one leg to a first end-point and another leg to a second end-point. An intercepting, i.e. transparent, TCP proxy is a network processor to which TCP packets are routed by the network. Two connections must thus be established: one connection between the client device and the TCP proxy and another connection between the TCP proxy and the server node, hence the two communication legs.

The intercepting TCP proxy is not the actual addressed end-point, but acts as a "virtual" end-point towards both real end-points, e.g. a client device and a server node, by terminating the TCP connection on behalf of the addressed end-point, and the TCP proxy sets up or re-uses an outbound TCP connection to the originally addressed end-point. Thus, towards each real end-point the TCP proxy appears as the opposite end point in that the TCP proxy comprises a virtual TCP server to which the client device is connected over one communication leg and a virtual TCP client to which the server node is connected over another

communication leg, as shown in Fig. 2.

An application executing on an operating system of a processor in a network must register itself with a port upon which it is willing to accept TCP connections. Such a processor may be implemented in any network node such as a client device, a server node and/or a TCP proxy. This is commonly described such that the application "listens" on a port and also accepts connections on that port. For example, a web server normally listens on, or monitors, TCP port 80, which is typically used as default port for the HTTP protocol.

A client device that intends to connect to that particular application on the network processor operating system, firstly initiates the connection by sending a SYN packet to the IP address of the network processor. The network processor operating system receives the SYN packet and secondly responds by returning a SYN, ACK packet. When the network processor operating system thirdly receives an ACK packet from the client device, the connection is established and the application is notified that the new connection is ready. The above 3-way handshake procedure must be completed before the application is notified.

As indicated above, a limiting metric for the theoretical maximum bandwidth, i.e. data throughput that can be achieved in a TCP communication is the RTT. The RTT is inverse proportional to the bandwidth such that a higher bandwidth can be achieved by reducing the RTT. A normal handshake procedure for establishing a TCP connection between a client device 200 and a server node 202 over a TCP proxy 204, will now be described with reference to Fig. 2. The TCP proxy 204 comprises a virtual TCP server 204a for communication with the client device 200 typically over an access network such as a wireless network, a virtual TCP client 204b for communication with the server node 202 typically over the Internet, and a control logic 204c arranged between the TCP server 204a and the virtual TCP client 204b. Each of the TCP server 204a and the TCP client 204b comprises an TCP/IP stack for handling the respective TCP communication with a corresponding TCP/IP stack at each end-point 200, 202. The control logic 204c is used for implementing various control functions on requested

communications. In this procedure, the client device 200 initiates a communication with the server node 202 by sending a SYN packet addressed to the server node 202, which packet is intercepted by the virtual TCP server 204a in the TCP proxy 204 in a first action 2:1. The SYN packet is effectively a request for communication with the server node 202. The TCP server 204a then acts on behalf of the server node 202 and returns a SYN, ACK packet to the client device 200, in an action 2:2, and the latter responds by sending an acknowledgement packet which is intercepted by the TCP server 204a in another action 2:3. Thereby, the handshake with client device 200 is completed and the first communication leg is established between the client device 200 and the TCP proxy 204.

A following action 2:4 illustrates that the TCP server 204a notifies the control logic 204c that the handshake is ready by forwarding the SYN packet to the control logic 204c which then may apply various control functions on the SYN packet such as a firewall function or the like. If the requested communication is accepted, the control logic 204c establishes address information in an action 2:5, including source address and source port as well as destination address and destination port. The control logic 204c then triggers the TCP client 204b, in another action 2:6, to initiate a TCP connection with the server node 202 addressed by the SYN packet sent from the client device 200. To execute a handshake with the server node 202, the TCP client 204b sends a corresponding SYN packet to the server node 202 in a following action 2:7, and the server node 202 responds by sending a SYN, ACK packet to the TCP client 204b in another action 2:8. Finally, the TCP client 204b sends an acknowledgement packet to the server node 202 in an action 2:9. Thereby, the handshake with the server node 202 is completed and the second communication leg is established between the TCP proxy 204 and the server node 202, and the TCP communication of data may thus be executed.

It should be noted that in this conventional TCP connection set-up procedure, the handshake procedure with the client device 200 must be completed and the address information must be established before the handshake procedure with the server node 202 can start, in order to establish a TCP connection between the two end-points 200, 202 over the TCP proxy 204. It is thus a problem that this set-up procedure may cause unwanted latency to the TCP communication, particularly when it must be executed multiple times in order to obtain some desired data, e.g. when retrieving a web page with multiple objects. The access network used by the client device 200 may have limited bandwidth and be slow, particularly in the case of a mobile or wireless access network, and it may therefore take some time to complete the handshake with the client device 200 due to a high RTT in such access networks.

Summary

It is an object of embodiments described herein to address at least some of the problems and issues outlined above. It is possible to achieve this object and others by using a method and a TCP proxy as defined in the attached independent claims.

According to one aspect, a method is performed by a Transmission Control Protocol, TCP, proxy for supporting a TCP communication between a client device and a server node. In this method, when the TCP proxy intercepts a

synchronization packet sent from the client device and addressed to the server node, the TCP proxy initiates a first handshake procedure with the server node prior to completing a second handshake procedure with the client device. The TCP proxy further performs simultaneously the first handshake procedure to establish a TCP connection between the TCP proxy and the server node and the second handshake procedure to establish a TCP connection between the TCP proxy and the client device.

According to another aspect, a Transmission Control Protocol, TCP, proxy is arranged to support a TCP communication between a client device and a server node. The TCP proxy comprises means configured to intercept a synchronization packet sent from the client device and addressed to the server node. The TCP proxy also comprises means configured to initiate a first handshake procedure with the server node prior to completing a second handshake procedure with the client device. The TCP proxy further comprises means configured to perform simultaneously the first handshake procedure to establish a TCP connection between the TCP proxy and the server node and the second handshake

procedure to establish a TCP connection between the TCP proxy and the client device.

By employing the above method and TCP proxy, the time it takes to establish a TCP communication between a client device and a server node over the TCP proxy can be minimized or at least reduced as compared to conventional procedures. A computer program is also provided which comprises instructions which, when executed on at least one processor, cause the at least one processor to carry out the method. A carrier is also provided which contains the above computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

The above method and TCP proxy may be configured and implemented according to different optional embodiments to accomplish further features and benefits, to be described below.

Brief description of drawings

The solution will now be described in more detail by means of exemplary embodiments and with reference to the accompanying drawings, in which: Fig. 1 is a communication scenario illustrating a basic TCP communication between two end-points, according to the prior art.

Fig. 2 is a signaling diagram illustrating how a TCP communication between two end-points is established over a TCP proxy, according to the prior art.

Fig. 3 is a flow chart illustrating a procedure in a TCP proxy, according to some possible embodiments. Fig. 4 is a signaling diagram illustrating an example of a TCP communication being established between two end-points over a TCP proxy, according to further possible embodiments.

Fig. 5 is a block diagram illustrating functional entities in a TCP proxy, according to further possible embodiments.

Fig. 6 is a block diagram illustrating how a TCP proxy may be arranged in more detail, according to further possible embodiments.

Fig. 7 is a signaling diagram illustrating a practical example of how a TCP communication may be established between two end-points over a TCP proxy, according to further possible embodiments.

Detailed description

Briefly described, a solution is provided to reduce the time it takes to complete the process of establishing an end-to-end TCP connection between a client device and a server node over a TCP proxy. In particular, the above-described

handshake procedure between the TCP proxy and the server node does not have to wait for the handshake procedure between the TCP proxy and the client device to be completed. This solution allows these two handshake procedures to be executed in parallel, i.e. at least partly at the same time, in order to save time, which will be described in more detail below. This reduction of time to establish such an end-to-end TCP connection can be accomplished by implementing a method in the TCP proxy as illustrated by the flow chart in Fig. 3. It is assumed that the client device is able to communicate with the TCP proxy over a transport network such as an access network, and that the TCP proxy is able to communicate with the server node over another transport network such as the Internet. However, the solution is not limited to using such communication networks and any types of networks may be used between the TCP proxy and the client device and between the TCP proxy and the server node, respectively. The method of Fig. 3 begins when the TCP proxy receives and intercepts a synchronization packet, SYN packet for short, that is sent from the client device and addressed to the server node, as shown in an action 300. The client device may be triggered to send the SYN packet e.g. when a user is browsing the Internet and requests a web page using an application in the client device. In response thereto, the application triggers a TCP/IP stack in the client device to send the SYN packet towards the server node which packet is routed over the TCP proxy. The SYP packet may be received by a virtual TCP server in the TCP proxy as similar to Fig. 2. In a possible embodiment, the synchronization packet sent from the client device may be intercepted in action 300 by a SYN detector arranged between a network driver and a TCP/IP stack of a virtual TCP server configured to act on behalf of the server node in the TCP proxy. Some examples of how this SYN detector may be implemented in the TCP proxy will be outlined later below with reference to Figs 4, 6 and 7. The term "SYN detector" is used here to represent any functional entity in the TCP proxy that is capable of detecting and intercepting incoming SYN packets.

In conventional procedures when such a SYN packet is received, the TCP proxy would first execute and complete a handshake procedure with the client device before initiating a first handshake procedure with the server node, as described for Fig. 2. The method of Fig. 3 is different, however, in that these two procedures are executed in parallel instead of one by one. A following action 302 illustrates thus that the TCP proxy initiates a first handshake procedure with the server node prior to completing a second handshake procedure with the client device. Thereby, the first and second handshake procedures will be executed at least partly at the same time. Actions 304a and 304b thus illustrate that the TCP proxy performs simultaneously the first handshake procedure to establish a TCP connection between the TCP proxy and the server node and the second handshake

procedure to establish a TCP connection between the TCP proxy and the client device. In some possible embodiments, actions 304a, b may be performed as follows. The first handshake procedure may be performed by a TCP/IP stack of a virtual TCP client configured to act on behalf of the client device in the TCP proxy. Further, the second handshake procedure may be performed by a TCP/IP stack of a virtual TCP server configured to act on behalf of the server node in the TCP proxy.

In another possible embodiment, the TCP proxy may store connection information associated with the server node comprising a destination address and a

destination port, in a pool of multiple connections once the first handshake procedure with the server node has been completed. In this way, the TCP proxy may maintain such a pool of multiple connections as a precaution, or "early notice", in order to have connection information for various end points established and readily available for use when communication of data gets started between two end points, such as between the client device and the server node. Thereby, delays can be reduced and further time can be saved before the communication of data begins.

In yet another possible embodiment, once the second handshake procedure with the client device has been completed, the TCP proxy may obtain connection information associated with the client device comprising a source address and a source port, and retrieve the stored connection information associated with the server node is from the pool, in order to connect the client device with the server node in the TCP proxy based on the obtained and retrieved connection

information.

The above-mentioned pool of multiple connections may be implemented in the TCP proxy in different ways. For example, connection information stored from various received SYN packets may be deleted from the pool after a preset storage time has expired, or when the pool becomes saturated or "full", i.e. when all its available memory space is occupied, the oldest entry with connection information may be deleted from the pool, and so forth. In another possible embodiment, the pool of multiple connections may thus be configured to hold connection information of no more than a pre-set maximum number of connections, and if the maximum number has been reached in the pool, the connection information associated with the server node replaces the oldest connection information in the pool. In a further possible embodiment, the stored connection information may be deleted from the pool once the TCP connection has been established.

An example of how the above-described method of Fig. 3 can be used in practice will now be described with reference to the signaling diagram in Fig. 4 illustrating establishment of a TCP communication between a client device 400 and a server node 402 over a TCP proxy 404. As in Fig. 2, the TCP proxy 404 comprises a virtual TCP server 404a to which the client device 400 is connected over one communication leg and a virtual TCP client 404b to which the server node 402 is connected over another communication leg. A control logic 404c is also arranged between the virtual TCP server 404a and the virtual TCP client 404b. However, the TCP proxy 404 is distinct from the TCP proxy 404 of Fig. 2 by further comprising a SYN detector 404d. The TCP communication is established according to Fig. 4 as follows.

In this procedure, the client device 400 initiates a communication with the server node 402 by sending a SYN packet addressed to the server node 402, which packet is detected and intercepted by the SYN detector 404d in the TCP proxy 404 in a first action 4:1 , which corresponds to action 300 above. The SYN packet is effectively a request for communication with the server node 402 and it also triggers establishment of a TCP connection as a communication leg between the TCP proxy 404 and the client device 400. Having intercepted the SYN packet, the SYN detector 404d immediately forwards SYN information to the control logic 404c, in an action 4.2, which triggers establishment of a TCP connection as a communication leg between the TCP proxy 404 and the server node 402. The SYN detector 404d extracts the SYN information from the SYN packet including a source address referring to the client device 400 and a destination address referring to the server node 402. The control logic 404c is then able to trigger the TCP client 404b, in an action 4:3, to start a handshake procedure with the server node 402. Another action 4:4a illustrates that the SYN detector 404d also forwards the incoming SYN packet to the TCP server 404a which is then able to execute a handshake procedure with the client device 400 in response to receiving the SYN packet, which corresponds to the second handshake procedure in the method of Fig. 3.

The TCP client 404b thus starts the handshake procedure with the server node 402 by sending a SYN packet thereto, in an action 4:4b, which corresponds to the first handshake procedure in the method of Fig. 3. It should be noted that the first handshake procedure with the server node 402 is thereby initiated prior to completing the second handshake procedure with the client device 400, and that actions 4:4a and 4:4b can be executed independent of one another and in any order.

The TCP server 404a duly acts on behalf of the server node 402 and returns a SYN, ACK packet to the client device 400, in an action 4:5a. In parallel with this second handshake procedure with the client device 400, the TCP client 404b sends a corresponding SYN packet to the server node 402 in an action 4:4b, and the server node 402 responds by sending a SYN, ACK packet to the TCP client 404b in another action 4:5b. Finally, the TCP client 404b returns an

acknowledgement packet to the server node 402 in an action 4:6b. Thereby, the first handshake with the server node 402 is completed and a TCP connection is established between the TCP proxy 404 and the server node 402.

Another action 4:7 illustrates that the TCP client 404b notifies the control logic 404c that the first handshake procedure with the server node has been completed and that the TCP connection has been established between the TCP proxy 404 and the server node 402. The control logic 404c then stores connection

information associated with the server node comprising a destination address and a destination port, in a pool of multiple connections once the first handshake procedure with the server node 402 has been completed, as shown in an action 4:8

As mentioned above, it may take some time before a response is received from the client device 400 to the SYN, ACK packet of action 4:5a, particularly if the client device 400 is using a wireless access network which may require free radio resources, establishment of a radio bearer, and so forth. If the current traffic load is high on the wireless access network, the delay may be substantial. At some point, the TCP server 404a receives an acknowledgement packet from the client device 400, illustrated by another action 4:9, which may occur after the first handshake with the server node 402 has actually been completed. Thereby, the handshake with client device 400 is also completed and the TCP server 404a notifies the control logic 404c, in an action 4:10, that the second handshake procedure with the client device 400 has been completed and that the TCP connection has been established between the TCP proxy 404 and the client device 400.

The control logic 404c may apply various control functions on the SYN packet such as a firewall function or the like, which is however somewhat outside the described solution. If the requested communication is accepted, the control logic 404c obtains connection information associated with the client device comprising a source address and a source port, and retrieves the stored connection information associated with the server node 402 from the pool in an action 4:11. Thereby, the communication of data between the client device 400 and the server node 402 may be executed over the TCP proxy 404, using the source address and source port and the destination address and destination port. A detailed but non-limiting example of how a TCP proxy may be structured with some possible functional entities such as modules, circuits or units, to bring about the above-described functionality of the TCP proxy, is illustrated by the block diagram in Fig. 5. In this figure, the TCP proxy 500 is arranged to support a TCP communication between a client device 502 and a server node 504. The TCP proxy 500 may be configured to operate according to any of the examples and embodiments of employing the solution as described above and as follows. In particular, the TCP proxy 500 may comprise means arranged or configured to perform at least the actions of the flow chart in Fig. 3 and possibly also to operate according to Fig 4 in the manner described above and/or according to Fig 7 in a manner to be described later below. In order to put any of this into practice, the TCP proxy 500 may be implemented with a communication circuit C, a memory M and an operable processor P comprising various functional modules as described below. More specifically, the TCP proxy 500 comprises means configured to intercept a synchronization packet sent from the client device 502 and addressed to the server node 504. This intercepting operation may be performed by an

intercepting module 500a, e.g. in the manner described for action 300 above. The TCP proxy 500 also comprises means configured to initiate a first handshake procedure with the server node 504 prior to completing a second handshake procedure with the client device 502. This initiating operation may be performed by a handshake module 500b, e.g. in the manner described for action 302 above.

The TCP proxy 500 also comprises means configured to perform simultaneously the first handshake procedure to establish a TCP connection between the TCP proxy 500 and the server node 504 and the second handshake procedure to establish a TCP connection between the TCP proxy 500 and the client device 502. This handshake operation may be performed by the handshake module 500b, e.g. in the manner described for actions 304a and 304b above.

It should be noted that Fig. 5 illustrates some possible functional modules in the TCP proxy 500 and the skilled person is able to implement these functional modules in practice using suitable software and hardware. Thus, the solution is generally not limited to the shown structures of the TCP proxy 500, and the functional modules 500a-b may be configured to operate according to any of the features described in this disclosure, where appropriate. The embodiments and features described herein may be implemented in a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the above actions e.g. as described for Figs 3 and 5. Further, the above-described embodiments may be implemented in a carrier containing the above computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium. The computer readable storage medium may be a compact disc or other carrier suitable for holding the computer program. Some examples of how the computer program and the carrier can be realized in practice are outlined below, with reference to Fig. 5.

The processor P may comprise a single Central Processing Unit (CPU), or could comprise two or more processing units. For example, the processor P may include a general purpose microprocessor, an instruction set processor and/or related chips sets and/or a special purpose microprocessor such as an Application Specific Integrated Circuit (ASIC). The processor P may also comprise a storage for caching purposes.

The memory M may comprise the above-mentioned computer readable storage medium or carrier on which the computer program is stored e.g. in the form of computer program modules or the like. For example, the memory M may be a flash memory, a Random-Access Memory (RAM), a Read-Only Memory (ROM) or an Electrically Erasable Programmable ROM (EEPROM).

Fig. 6 illustrates another example of how the TCP proxy described herein may be implemented. The TCP proxy 600 is shown here as divided into a proxy

application and an operating system. The operating system comprises a TCP/IP stack 600a and an network driver 600b which is the first entity to receive any incoming SYN packets, while the proxy application comprises a proxy logic 600c corresponding to the above-described control logic 404c, and a SYN detector 600d corresponding to the above-described SYN detector 404d. The proxy application also comprises further entities 600e such as a listen socket, a server socket and a client socket. As mentioned above, the solution and its benefits are enabled by the SYN detector 600d which is arranged between the network driver 600b and the TCP/IP stack 600a and to intercept incoming SYN packets before they are processed by the TCP/IP stack 600a. Thereby, the above-described first handshake with the server node can be initiated as early as possible to save time.

A practical example of how a TCP communication may be established between two end-points over a TCP proxy, will now be briefly described with reference to the signaling diagram in Fig. 7. This figure thus illustrates a client device 700, a server node 702 denoted "origin server", and a TCP proxy 704. The TCP proxy 704 in turn comprises a virtual TCP server 704a, a virtual TCP client 704b, a proxy logic 704c and a SYN detector 704d. The above-mentioned listen socket, server socket and client socket are also comprised in the TCP proxy 704. Further, both the virtual TCP server 704a and the virtual TCP client 704b comprise a network driver which are arranged to handle any outgoing and incoming communications. Fig. 7 further illustrates a series of operational steps 1 -24 as follows.

Step 1 : The proxy logic 704c starts to listen for any incoming TCP connections on the listen socket.

Step 2: The virtual TCP server 704a receives SYN packet from the client device 700 on the network driver. Step 3: The SYN packet is intercepted by the SYN detector 704d.

Step 4: The SYN detector 704d notifies the proxy logic 704c by forwarding SYN information thereto, including destination and source addresses extracted from the SYN packet as well as destination and source ports.

Step 5: The proxy logic 704c connects to the destination address and destination port via a new client socket.

Step 6: The SYN packet is forwarded from the TCP/IP stack to the network driver in the TCP client 704b. Step 7: The SYN packet is sent from the TCP client 704b to the server node 702.

Step 8: The SYN detector 704d forwards the SYN packet to the TCP/IP stack in the TCP server 704a.

Step 9: the TCP/IP stack sends a SYN, ACK packet to the network driver in the TCP server 704a.

Step 10: The network driver in the TCP server 704a sends the SYN, ACK packet to the client device 700.

Step 1 1 : The TCP client 704b receives a SYN, ACK packet from the server node 702. Step 12: The network driver in the TCP client 704b forwards the SYN, ACK packet to the TCP/IP stack.

Step 13: The TCP/IP stack in the TCP client 704b notifies the client socket and also returns an acknowledgement to the server node 702 as indicated by 13a and 13b. Step 14: The client socket notifies the proxy logic 704c that the TCP connection towards the server node 702 is ready.

Step 15: The TCP connection towards the server node 702 is placed in the pool of connections with the server node's 702 address as key.

Step 16: The network driver in TCP server 704a receives an acknowledgement, ACK, packet from the client device 700.

Step 17: The received ACK is forwarded to the TCP/IP stack in TCP server 704a.

Step 18: the TCP/IP stack in TCP server 704a notifies the listen socket that the TCP connection towards the client device 700 is ready. Step 19: The listen socket notifies the proxy logic 704c that the TCP connection towards the client device 700 is ready.

Step 20: The proxy logic 704c notifies the listen socket that the new TCP connections towards the client device 700 and the server node 702 are accepted. Step 21 : The listen socket returns to the proxy logic 704c a new server socket that represents the new connections.

Step 22: The proxy logic 704c retrieves the source address of the client device 700 and the destination address of the server node 702 from the server socket.

Step 23: The server socket returns the source address and the destination address to the proxy logic 704c.

Step 24: The proxy logic 704c retrieves connection to the server node 702 from the pool.

Thereby, the TCP connection between the client device 700 and the server node 702 has been established over the TCP proxy 704 and communication of data can be conducted. It should be noted that since the SYN detector 704d notifies the proxy logic 704c by forwarding SYN information thereto immediately in step 4, the handshake procedure with the server node 702 as of steps 9, 10, 16, 17 can be executed without having to wait for the handshake procedure with the client device 700 to be completed. It is therefore an advantage that considerable time can thus be saved, especially when retrieval of a web page or other resource requires that the above procedure is executed multiple times, as explained above.

While the solution has been described with reference to specific exemplifying embodiments, the description is generally only intended to illustrate the inventive concept and should not be taken as limiting the scope of the solution. For example, the terms "TCP proxy", "client device", "server node", "SYN detector" and "synchronization packet" have been used throughout this disclosure, although any other corresponding entities, functions, and/or parameters could also be used having the features and characteristics described here. The solution is defined by the appended claims.

Claims

1 . A method performed by a Transmission Control Protocol, TCP, proxy (404) for supporting a TCP communication between a client device (400) and a server node (402), the method comprising: - intercepting (300) a synchronization packet sent from the client device and addressed to the server node,

- initiating (302) a first handshake procedure with the server node prior to completing a second handshake procedure with the client device, and

- performing (304a, 304b) simultaneously the first handshake procedure to establish a TCP connection between the TCP proxy (404) and the server node and the second handshake procedure to establish a TCP connection between the TCP proxy (404) and the client device.

2. A method according to claim 1 , wherein connection information associated with the server node comprising a destination address and a

destination port, is stored in a pool of multiple connections once the first handshake procedure with the server node has been completed.

3. A method according to claim 2, wherein once the second handshake procedure with the client device has been completed, connection information associated with the client device comprising a source address and a source port is obtained and the stored connection information associated with the server node is retrieved from the pool, in order to connect the client device with the server node in the TCP proxy based on the obtained and retrieved connection information.

4. A method according to claim 2 or 3, wherein the stored connection information is deleted from the pool once the TCP connection has been

established.

5. A method according to any of claims 2-4, wherein the pool of multiple connections is configured to hold connection information of no more than a pre-set maximum number of connections, and if the maximum number has been reached in the pool the connection information associated with the server node (402) replaces the oldest connection information in the pool.

6. A method according to any of claims 1 -5, wherein the synchronization packet sent from the client device is intercepted by a SYN detector (404d, 704d) arranged between a network driver and a TCP/IP stack of a virtual TCP server (404a, 704a) configured to act on behalf of the server node in the TCP proxy.

7. A method according to any of claims 1 -6, wherein the first handshake procedure is performed by a TCP/IP stack of a virtual TCP client (404b, 704b) configured to act on behalf of the client device in the TCP proxy, and the second handshake procedure is performed by a TCP/IP stack of a virtual TCP server (404a, 704a) configured to act on behalf of the server node in the TCP proxy.

8. A Transmission Control Protocol, TCP, proxy (500) arranged to support a TCP communication between a client device (500) and a server node (502), the TCP proxy (500) comprising means configured to: intercept a synchronization packet sent from the client device and addressed to the server node, initiate a first handshake procedure with the server node prior to completing a second handshake procedure with the client device, and perform simultaneously the first handshake procedure to establish a TCP connection between the TCP proxy (404) and the server node and the second handshake procedure to establish a TCP connection between the TCP proxy (404) and the client device.

9. A TCP proxy (500) according to claim 8, wherein connection information associated with the server node comprising a destination address and a

destination port, is stored in a pool of multiple connections once the first

handshake procedure with the server node has been completed.

10. A TCP proxy (500) according to claim 9, wherein once the second handshake procedure with the client device has been completed, connection information associated with the client device comprising a source address and a source port is obtained and the stored connection information associated with the server node is retrieved from the pool, in order to connect the client device with the server node in the TCP proxy based on the obtained and retrieved connection information.

1 1 . A TCP proxy (500) according to claim 9 or 10, wherein the stored connection information is deleted from the pool once the TCP connection has been established.

12. A TCP proxy (500) according to any of claims 9-1 1 , wherein the pool of multiple connections is configured to hold connection information of no more than a pre-set maximum number of connections, and if the maximum number has been reached in the pool the connection information associated with the server node (402) replaces the oldest connection information in the pool.

13. A TCP proxy (500) according to any of claims 8-12, wherein the synchronization packet sent from the client device is intercepted by a SYN detector (404d, 704d) arranged between a network driver and a TCP/IP stack of a virtual TCP server (404a, 704a) configured to act on behalf of the server node in the TCP proxy.

14. A TCP proxy (500) according to any of claims 8-13, wherein the first handshake procedure is performed by a TCP/IP stack of a virtual TCP client (404b, 704b) configured to act on behalf of the client device in the TCP proxy, and the second handshake procedure is performed by a TCP/IP stack of a virtual TCP server (404a, 704a) configured to act on behalf of the server node in the TCP proxy.

15. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1 -7.

16. A carrier containing the computer program of claim 15, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.