WO2015167375A1 - Procédé et mandataire tcp permettant de prendre en charge une communication entre un dispositif client et un nœud de serveur - Google Patents

Procédé et mandataire tcp permettant de prendre en charge une communication entre un dispositif client et un nœud de serveur Download PDF

Info

Publication number
WO2015167375A1
WO2015167375A1 PCT/SE2014/050531 SE2014050531W WO2015167375A1 WO 2015167375 A1 WO2015167375 A1 WO 2015167375A1 SE 2014050531 W SE2014050531 W SE 2014050531W WO 2015167375 A1 WO2015167375 A1 WO 2015167375A1
Authority
WO
WIPO (PCT)
Prior art keywords
tcp
server node
client device
proxy
handshake procedure
Prior art date
Application number
PCT/SE2014/050531
Other languages
English (en)
Inventor
Dan Mathiasen
Thorsten Herber
Johan Svedberg
Robert Skog
Original Assignee
Telefonaktiebolaget L M Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget L M Ericsson (Publ) filed Critical Telefonaktiebolaget L M Ericsson (Publ)
Priority to PCT/SE2014/050531 priority Critical patent/WO2015167375A1/fr
Publication of WO2015167375A1 publication Critical patent/WO2015167375A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Definitions

  • 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.
  • TCP Transmission Control Protocol
  • TCP Transmission Control Protocol
  • 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 .
  • the application 100a 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.
  • RTT Round-Trip Time
  • 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.
  • 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.
  • 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.
  • a TCP connection must be established between the TCP end- points.
  • 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.
  • 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.
  • 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.
  • the TCP proxy establishes two TCP communication between two end-points.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • the TCP client 204b 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.
  • 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.
  • a method is performed by a Transmission Control Protocol, TCP, proxy for supporting a TCP communication between a client device and a server node.
  • TCP Transmission Control Protocol
  • 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.
  • 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
  • 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.
  • TCP proxy may be configured and implemented according to different optional embodiments to accomplish further features and benefits, to be described below.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the TCP proxy 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
  • 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.
  • 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.
  • the TCP proxy may store connection information associated with the server node comprising a destination address and a
  • 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.
  • 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
  • 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.
  • 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.
  • the stored connection information may be deleted from the pool once the TCP connection has been established.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the TCP client 404b returns an
  • 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
  • ACK packet of action 4:5a may be used to indicate whether a response is received from the client device 400 to the SYN.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • the processor P may comprise a single Central Processing Unit (CPU), or could comprise two or more processing units.
  • 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).
  • ASIC Application Specific Integrated Circuit
  • 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.
  • 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).
  • RAM Random-Access Memory
  • ROM Read-Only Memory
  • EEPROM Electrically Erasable Programmable ROM
  • 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
  • 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
  • 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.
  • 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.
  • the above-described first handshake with the server node can be initiated as early as possible to save time.
  • FIG. 7 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé et un mandataire TCP (404) pour prendre en charge une communication TCP entre un dispositif client (400) et un nœud de serveur (402). Lorsque le mandataire TCP (404) intercepte un paquet de synchronisation envoyé à partir du dispositif client (400) et adressé au nœud de serveur, il lance une première procédure d'établissement de liaison avec le nœud de serveur (402) avant l'achèvement d'une seconde procédure d'établissement de liaison avec le dispositif client (400). Le mandataire TCP (404) réalise ensuite simultanément la première procédure d'établissement de liaison pour établir une connexion TCP entre le mandataire TCP et le nœud de serveur (402) et la seconde procédure d'établissement de liaison pour établir une connexion TCP entre le mandataire TCP et le dispositif client (400).
PCT/SE2014/050531 2014-04-30 2014-04-30 Procédé et mandataire tcp permettant de prendre en charge une communication entre un dispositif client et un nœud de serveur WO2015167375A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SE2014/050531 WO2015167375A1 (fr) 2014-04-30 2014-04-30 Procédé et mandataire tcp permettant de prendre en charge une communication entre un dispositif client et un nœud de serveur

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2014/050531 WO2015167375A1 (fr) 2014-04-30 2014-04-30 Procédé et mandataire tcp permettant de prendre en charge une communication entre un dispositif client et un nœud de serveur

Publications (1)

Publication Number Publication Date
WO2015167375A1 true WO2015167375A1 (fr) 2015-11-05

Family

ID=50897841

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2014/050531 WO2015167375A1 (fr) 2014-04-30 2014-04-30 Procédé et mandataire tcp permettant de prendre en charge une communication entre un dispositif client et un nœud de serveur

Country Status (1)

Country Link
WO (1) WO2015167375A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107659966A (zh) * 2016-07-26 2018-02-02 普天信息技术有限公司 数据传输方法、网络设备、用户终端、网关设备
CN109510801A (zh) * 2017-09-15 2019-03-22 华耀(中国)科技有限公司 显式正向代理与ssl侦听集成系统及其运行方法
WO2022212133A1 (fr) * 2021-03-31 2022-10-06 Google Llc Protocole sans proxy

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7016973B1 (en) * 1999-11-19 2006-03-21 At&T Corp. Apparatus and methods for providing translucent proxies in a communications network
US20100318665A1 (en) * 2003-04-14 2010-12-16 Riverbed Technology, Inc. Interception of a cloud-based communication connection

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7016973B1 (en) * 1999-11-19 2006-03-21 At&T Corp. Apparatus and methods for providing translucent proxies in a communications network
US20100318665A1 (en) * 2003-04-14 2010-12-16 Riverbed Technology, Inc. Interception of a cloud-based communication connection

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107659966A (zh) * 2016-07-26 2018-02-02 普天信息技术有限公司 数据传输方法、网络设备、用户终端、网关设备
CN109510801A (zh) * 2017-09-15 2019-03-22 华耀(中国)科技有限公司 显式正向代理与ssl侦听集成系统及其运行方法
CN109510801B (zh) * 2017-09-15 2021-08-31 北京华耀科技有限公司 显式正向代理与ssl侦听集成系统及其运行方法
WO2022212133A1 (fr) * 2021-03-31 2022-10-06 Google Llc Protocole sans proxy
US11533372B2 (en) 2021-03-31 2022-12-20 Google Llc Proxyless protocol
US11870855B2 (en) 2021-03-31 2024-01-09 Google Llc Proxyless protocol

Similar Documents

Publication Publication Date Title
US9641650B2 (en) TCP proxy server
US8938553B2 (en) Cooperative proxy auto-discovery and connection interception through network address translation
US11277341B2 (en) Resilient segment routing service hunting with TCP session stickiness
EP2741463B1 (fr) Procédé de transmission de paquets de données
US10027781B2 (en) TCP link configuration method, apparatus, and device
CN109412946B (zh) 一种确定回源路径的方法、装置、服务器及可读存储介质
US10361921B2 (en) Method and apparatus for managing connections in a communication network
US20160241664A1 (en) Method, device, and system for redirecting data by using service proxy
KR20140070426A (ko) 다중 경로 연결을 확립하기 위한 방법 및 멀티 홈 장비
US20150373135A1 (en) Wide area network optimization
US7564848B2 (en) Method for the establishing of connections in a communication system
US11700321B2 (en) Transparent proxy conversion of transmission control protocol (TCP) fast open connection
CN110753035B (zh) 一种基于tcp协议的fpga超低延迟通信传输方法
US11349934B2 (en) Opportunistic transmission control protocol (TCP) connection establishment
WO2015167375A1 (fr) Procédé et mandataire tcp permettant de prendre en charge une communication entre un dispositif client et un nœud de serveur
CN108124504B (zh) Tfo传输方法、代理服务器和系统
WO2019243890A2 (fr) Transmission de données multiport par l'intermédiaire du protocole udp
WO2013152614A1 (fr) Système et procédé d'accès au réseau basé sur des données de couche application
CN110381007B (zh) Tcp加速方法及装置
JP5723808B2 (ja) 通信装置、通信方法、及びプログラム
Liqing et al. TCP optimization implementation of a small embedded system
WO2020064593A1 (fr) Procédé et appareil pour transmettre des paquets d'un premier réseau vers un second réseau
EP3525413A1 (fr) Protocole sans connexion comportant un contrôle de bande passante et de congestion
EP3525412A1 (fr) Protocole de transmission de données sans connection amélioré
EP3525419A1 (fr) Protocole sans connexion avec régulation de la largeur de bande et de l'encombrement

Legal Events

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

Ref document number: 14729074

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14729074

Country of ref document: EP

Kind code of ref document: A1