Patent Document

CROSS REFERENCE TO RELATED APPLICATIONS 
   This application is a continuation of U.S. application Ser. No. 10/983,131, filed Nov. 4, 2004 now U.S. Pat. No. 7,058,058, which claims the benefit of U.S. Provisional Application Ser. No. 60/517,934, filed Nov. 5, 2003, the entire contents of each of which is incorporated herein by reference. 

   FIELD OF THE INVENTION 
   The present invention relates to the field of networking and the communication of data over a network and more particularly to transparent optimization for transmission control protocol (TCP) initial session establishment. 
   BACKGROUND OF THE INVENTION 
   The transmission control protocol (TCP) is one of the most widely used and reliable data transport protocols across communications networks. One of TCP&#39;s primary distinctions and the reasons for its widespread use is that TCP provides reliable communications. A “reliable” data transport protocol is one that provides accurate, loss-free, and in order delivery of data from a source to a destination. If there is any packet loss or packet reordering during transmission of the data across a communications network, TCP internally corrects such an error by retransmitting the lost data and by buffering the out-of-order data until the missing data arrives. TCP then delivers the data to the destination in the same initial order. Hence, by using TCP as its data transport protocol, an application can effectively operate in a best-effort packet switched network that does not guarantee data packet delivery. This reliable transport capability simplifies data communications, thus resulting in the widespread adoption of TCP. 
   TCP utilizes various internal algorithms to provide its capability of reliable transport. These algorithms include initial session establishment, slow start, packet reordering, packet loss detection, and numerous other mechanisms to dynamically decrease or increase the data transmission rate based on network conditions. 
   Network latency is a common problem that affects network and application performance. Network latency is attributable to several factors, including physical distance, number of hops, switching and router delays, and network congestion. Because these factors are not constants, networks may have unpredictable latency over a period of time. The variation in network latency depends on the distance spanned by the network link and the transmission medium used by the link. For instance, a local high-speed dedicated line between two buildings within a metro area may experience less than 5 milliseconds (ms) of one-way latency, while a global long distance asynchronous transfer mode (ATM) link between the United States and Europe may have anywhere from 50 to 250 ms of one-way latency. Similarly, a satellite link typically incurs about 240 to 300 ms of one-way latency, due to the time to transmit a signal up to an orbiting satellite and back. 
   The impact of latency on network applications may be traced directly to the inefficiencies of TCP under conditions of network latency. Most network applications can be classified into short-transaction based “chatty” applications or long-bulk data transfer applications. Common sources of short-transaction based network traffics include interactive applications (e.g., graphical or web-based user interfaces), various databases, enterprise resource planning (ERP) applications, customer relationship management (CRM) applications, etc. As users access and browse these applications, the applications typically generate numerous short TCP sessions to send and receive small amounts of information that the application then collects and presents to the users. Though most of these short TCP sessions involve sending or receiving a few hundred bytes or kilobytes of data, the actual data transfer is delayed because of TCP&#39;s initial session establishment. 
   To provide reliable communications, TCP first establishes a formal session between a source and a destination before transmitting any application-layer data. TCP provides this initial session establishment such that the destination does in fact receive and acknowledge the transmitted data. Accordingly, the destination can communicate with the source even if any data is lost. TCP&#39;s initial session establishment is based on the source first sending a request to initiate a session and then waiting for a response from the destination before transmitting the first application-layer data packet. This initial request and acknowledgment process utilizes one round-trip time (RTT). Hence, even if the source desires to transmit a small number of application-layer data packets across a high latency link, a portion of the total communications time is wasted on the initial session establishment. Thus, the cumulative delay due to the latency on the initial session establishment may decrease the end-user application performance, especially for chatty applications that established many short, serialized TCP sessions. 
   What is needed is a system and method for optimizing TCP&#39;s initial session establishment to improve the performance of short, serialized TCP sessions without intruding upon TCP&#39;s core algorithms. 
   SUMMARY OF THE INVENTION 
   The present invention is a system and method for optimizing TCP&#39;s initial session establishment without intruding upon TCP&#39;s core algorithms. The invention accelerates TCP&#39;s initial session establishment by locally processing a source&#39;s initial TCP request within the source&#39;s local area network (LAN). The present invention utilizes a control module relatively near the source&#39;s LAN and another control module relatively near a destination&#39;s LAN to complete the initial TCP session establishment within the source and the destination&#39;s respective LANs, thereby substantially eliminating the first RTT delay before the actual data flow begins. The invention thus allows the first application-layer data packet to be transmitted at substantially the same time as the initial TCP request. In one embodiment, the present invention optionally observes one or more TCP sessions between the source and the destination before accelerating the initial session establishment. The invention observes the one or more TCP sessions to provide a mechanism for error recovery during the optimization process. 
   The features and advantages described in the specification are not all inclusive and, in particular, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  is an illustration of one example of a network environment in which the present invention can operate. 
       FIG. 2  is a flowchart illustrating the conventional operation of TCP&#39;s initial session establishment. 
       FIG. 3  is a flowchart illustrating a method implemented by one embodiment of the present invention for optimizing TCP&#39;s initial session establishment. 
       FIGS. 4A and 4B  are flowcharts illustrating a method implemented by one embodiment of the invention and executed by a control module relatively near a source to optimize TCP&#39;s initial session establishment. 
       FIG. 5  is a flowchart illustrating a method implemented by one embodiment of the invention and executed by a control module relatively near a destination to optimize TCP&#39;s initial session establishment. 
   

   DETAILED DESCRIPTION OF THE INVENTION 
   A preferred embodiment of the present invention is now described with reference to the figures where like reference numbers indicate identical or functionally similar elements. Also in the figures, the left most digit of each reference number corresponds to the figure in which the reference number is first used. 
   Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment. 
   Some portions of the detailed description that follows are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps (instructions) leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared and otherwise manipulated. It is convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. Furthermore, it is also convenient at times, to refer to certain arrangements of steps requiring physical manipulations of physical quantities as modules or code devices, without loss of generality. 
   It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient characterizes applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or “determining” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices. 
   Certain aspects of the present invention include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions of the present invention could be embodied in software, firmware or hardware, and when embodied in software, could be downloaded to reside on and be operated from different platforms used by a variety of operating systems. 
   The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability. 
   The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and any references below to specific languages are provided for disclosure of enablement and best mode of the present invention. 
   In addition, the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims. 
     FIG. 1  is an illustration of one example of a network environment in which the present invention can operate. A source  102  can be any device that sends/receives data to/from one or more endpoints using TCP. For illustration purposes, source  102  as described hereinafter is any device that can request a TCP session. Source  102  is connected to a control module  104  (e.g., in a control device) via a communications network, such as a LAN  106 . Alternatively, control module  104  is directly connected to the source  102  without via the LAN  106  or is implemented within source  102  as a program module. Control module  104  is connected to one or more other control modules via another communications network such as a wide area network (WAN)  108 . Even though  FIG. 1  shows that control module  104  is connected to one other control module (i.e., the control module  110 ), control module  104  can be connected to more than one control module. Each of the other control modules is connected to a destination via yet another communications network. For example,  FIG. 1  shows that control module  110  (e.g., in a control device) is connected to a destination  112  via a LAN  114 . The destination  112  can be any device that receives/sends data from/to one or more endpoints using TCP. For illustration purposes, destination  112  as described hereinafter is any device that can respond to the TCP request sent by source  102 . Moreover, control module  110  can be directly connected to destination  112  without via the LAN  114  or can be implemented within destination  112  as a program module. 
   In one embodiment of the invention, control module  104  is located relatively nearer to source  102  than to destination  112 , while control module  110  is located relatively nearer to destination  112  than to source  102 . Accordingly, control module  104  is physically and logically associated with source  102 , and control module  110  is physically and logically associated with destination  112 . 
   As discussed, TCP&#39;s initial session establishment that requires the first application-layer data packet to be sent after the initialization is complete may delay the TCP transaction between source  102  and destination  112 . This process introduces at least one RTT of delay per transaction, which in the case of a high latency link may amount to 500 to 1000 ms of delay. When many of these short transactions are serially executed, the cumulative delay from this initialization process may be significant. Thus, in an embodiment of the invention, control module  104  and control module  110  cooperate to predictably and reliably complete the initial TCP session establishment within the respective LANs of source  102  and destination  112 . Control module  104  and control module  110  provide an optimization that is non-intrusive and transparent to TCP. That is, control modules  104  and  110  operate transparently to TCP&#39;s end-to-end reliability algorithms and avoid the complexities and risks of replacing TCP as the transmission protocol. Control modules  104  and  110  do not generate any acknowledgment for data that has not actually been received and instead use an existing acknowledgment to optimize the data flow. Accordingly, TCP&#39;s reliability protocols continue to operate end-to-end as if control modules  104  and  110  do not exist. The present invention thus non-intrusively improves TCP&#39;s latency performance by optimizing TCP&#39;s initial session establishment. 
     FIG. 2  illustrates the conventional operation of TCP&#39;s initial session establishment without control modules  104  and  110 . At A, source  102  first sends a special TCP packet to destination  112 . This special packet includes no application-layer data. It does, however, have one of the flag bits in the packet&#39;s header, called the synchronization (SYN) bit, set to TRUE. This special packet is often referred to as a SYN packet. Furthermore, source  102  selects an initial sequence number called source_isn and inserts this value in the initial SYN packet&#39;s sequence number field. Source  102  encapsulates this SYN packet within an internet protocol (IP) datagram and sends it to destination  112 . 
   At B, after the IP datagram including the SYN packet arrives at destination  112 , destination  112  extracts the SYN packet from the IP datagram, allocates the TCP buffers and variables to the connection, and sends a TCP connection-granted packet to source  102 . This connection-granted packet also includes no application-layer data. However, the SYN bit in the packet header is set to TRUE. Destination  112  also sets the ACK bit in the packet header and the acknowledgment field of the connection-granted packet header to source_isn+1. Moreover, destination  112  selects its own initial sequence number called destination_isn and inserts this value in the sequence number field of the connection-granted packet header. The connection-granted packet is often referred to as a synchronization-acknowledgment (SYN-ACK) packet. 
   At C, after receiving the connection-granted packet, source  102  allocates buffers and variables to the connection. Source  102  then sends yet another packet to destination  112 . This packet acknowledges the connection-granted packet of destination  112 . Specifically, source  102  inserts the value destination_isn+1 in the acknowledgment field of the TCP packet header. Source  102  also sets the TCP packet header&#39;s SYN bit to FALSE, since the TCP connection is established. 
   After steps A—C have been completed, source  102  and destination  112  can send packets including application-layer data to each other. In each of these future packets, the SYN bit is set to FALSE. 
   As can be seen, three packets are sent between source  102  and destination  112  to establish an initial TCP session between source  102  and destination  112 . Thus, this session establishment procedure is often referred to as a “three-way handshake.” Even though the TCP three-way handshake provides reliable delivery of data, source  102  is required to receive the SYN-ACK packet from destination  112  before it can begin to transmit application-layer data to destination  112 , and destination  112  is required to receive the last packet of the three-way handshake before it can begin to transmit application-layer data to source  102 . This requirement delays the application-layer data transmission, especially for multiple short TCP transactions that are serially executed. 
     FIG. 3  illustrates an exemplary operation of TCP&#39;s initial session establishment optimized by control modules  104  and  110  according to an embodiment of the invention. According to a preferred embodiment of the invention, before optimizing TCP&#39;s initial session establishment, control module  104  associated with source  102  gathers information about destination  112  and stores this information in a database. As illustrated, at A, control module  104  first allows source  102  to establish one or more TCP sessions with destination  112 . Even though control modules  104  and  110  do not interfere with such TCP sessions, control module  104  observes the responses of destination  112  to the SYN packets sent by source  102 . Control module  104  further observes a network address such as the IP address of destination  112 . Particularly, control module  104  observes one or more responses of destination  112  to a SYN packet to determine the TCP options used in response to the TCP options in the SYN packet for the IP address of destination  112 . Control module  104  then stores the responses of destination  112  having different combinations of TCP options in a database maintained by control module  104 . The responses are stored in the database in a per IP address, per TCP option combination manner. After control module  104  observes a sufficient number (e.g., 5) of TCP sessions between source  102  and destination  112  having a specific TCP option combination, and if the responses from destination  112  are consistent, then control module  104  “activates” the IP address and the specific TCP option combination of destination  112 . 
   After control module  104  activates the IP address and TCP option combination of destination  112 , source  102  sends a SYN packet to destination  112  at B. Control module  104  intercepts this SYN packet and, at C, responds to source  102  with a synthesized SYN-ACK packet having the IP address, port number, and TCP option combination of destination  112  as indicated in the database. Control module  104  also predictably or arbitrarily decides an initial sequence number (called synth_isn) and inserts this value in the sequence number field of the SYN-ACK packet header. At D, source  102  responds to the synthesized SYN-ACK packet sent by control module  104  with an acknowledgment (ACK) packet and puts itself into a session-established state. Source  102  then commences application-layer data transmission. Moreover, control module  104  characterizes the ACK packet and sends it to destination  112 . 
   After control module  104  intercepts the SYN packet sent from source  102  to destination  112 , it characterizes this SYN packet and inserts the synth_isn into the TCP header or the characterized SYN packet header, either as an unused TCP option or in the acknowledgment number field, or as additional data that is sent along with the packet. Control module  104  then sends the characterized SYN packet to destination  112  at E. During the time beginning when source  102  puts itself in the session-established state until source  102  receives information that destination  112  is also in the session-established state, control module  104  will characterize any data packet from source  102  to destination  112 . Control module  104  characterizes a SYN packet or data packet by using one or more fields available in the TCP header or by adding data to the packet. 
   Before the characterized SYN packet reaches destination  112 , control module  110  associated with destination  112  intercepts this characterized SYN packet. Control module  110  removes the characterization and finds out the synth_isn from the SYN packet. For example, control module  110  may find out an arbitrarily decided synth_isn based on what is included in the TCP header, the characterized SYN packet header, or the additional data being sent along with the packet. However, if the synth_isn was predictably decided by control module  104 , control module  110  may use the same prediction method to derive the synth isn after it determines that the SYN packet header is “characterized.” Control module  110  then sends the characterization-free SYN packet to destination  112  at F. 
   Before control module  110  receives a SYN-ACK packet from destination  112 , it may receive the characterized ACK packet from source  102  at G. In this case, control module  110  temporarily stores this characterized ACK packet in a memory area while waiting for the SYN-ACK packet from destination  112 . 
   When destination  112  sends the SYN-ACK packet to source  102  at H, control module  110  intercepts this SYN-ACK packet. From the SYN-ACK packet, control module  110  learns the initial sequence number used by destination  114  (referred to as destination_isn) and then sends the SYN-ACK packet to source  102 . Control module  110  then adjusts the temporarily stored ACK packet from source  102  to destination  112  based on the destination_isn. 
   In a preferred embodiment of the invention, control module  110  adjusts the ACK packet by computing an adjustment number called SeqAckAdjustment. For example, the SeqAckAdjustment can be computed by subtracting the destination_isn from the synth_isn. Accordingly, after control module  110  computes the SeqAckAdjustment, control module  110  releases the ACK packet that is temporarily stored in the memory area. Specifically, control module  110  removes the characterization from the ACK packet and adjusts the packet using the computed SeqAckAdjustment, for example, by subtracting the computed SeqAckAdjustment from the ACK packet&#39;s acknowledgment number and making a corresponding adjustment to the ACK packet&#39;s checksum. Control module  110  then sends the adjusted ACK packet to destination  112  at I. 
   In addition, if control module  110  receives a characterized data packet from source  102  before it receives the SYN-ACK packet from destination  112  (e.g., at J), it temporarily stores the characterized data packet. After the SYN-ACK packet arrives from destination  112 , control module  110  removes the characterization from the data packet, adjusts the data packet (e.g., by subtracting the computed SeqAckAdjustment from the data packet&#39;s acknowledgment number and making a corresponding adjustment to the data packet&#39;s checksum), and sends the adjusted data packet to destination  112  at K. For subsequent characterized data packets arriving from source  102 , control module  110  removes the characterization from the data packets, adjusts the data packets, and sends the adjusted data packets to destination  112 . 
   According to an embodiment of the invention, if the SYN packet characterized by control module  104  is lost before it reaches control module  110 , control module  110  may recover the information included in this lost SYN packet from a subsequent data packet arriving from control module  104  (e.g., at J). Accordingly, control module  110  can recover the lost information, recreate the SYN packet, and send the recreated SYN packet to destination  112 . This operation also applies if the SYN packet reaches control module  110  after the data packet arrives at control module  110 . Furthermore, if the SYN packet is lost on its way from control module  110  to destination  112 , control module  110  can use the information included in the subsequent data packet to recreate another SYN packet and send the recreated SYN packet to destination  112 . 
   In another embodiment of the invention, if the SYN-ACK packet from destination  112  is lost on its way to control module  110 , control module  110  recreates the SYN packet based on the information included in the subsequent data packet (e.g., that arrives at J). Control module  110  then sends the recreated SYN packet to destination  112  for destination  112  to transmit another SYN-ACK packet. 
   Before the SYN-ACK packet from destination  112  arrives at control module  104  associated with source  102 , control module  104  may receive a data packet from destination  112  before it receives the SYN-ACK packet from destination  112 . In this case, control module  104  temporarily stores this data packet in a memory area. 
   At L, control module  104  receives the SYN-ACK packet from destination  112 . From the received SYN-ACK packet, control module  104  learns the destination_isn and adjusts the temporarily stored data packets and subsequent data packets between source  102  and destination  112  based on the destination_isn. Control module  104  also examines the SYN-ACK packet to determine if it was formed as suggested in the database. If control module  104  determines that the SYN-ACK packet was not formed as suggested in the database (e.g., the IP address and/or the TCP option combination are different), then it “deactivates” destination  112  in the database and then observes subsequent regular TCP sessions between source  102  and destination  112  (without interference from control modules  104  and  110 ) to determine the correct information about destination  112 . 
   In any case, control module  104  consumes the SYN-ACK packet and does not send the SYN-ACK packet to source  102 . 
   In an embodiment of the invention, if the SYN-ACK packet from destination  112  is lost on its way from control module  110  to control module  104 , control module  104  can detect this loss because a data packet from destination  112  reaches control module  104  before the SYN-ACK packet arrives at control module  104 . In this case, control module  104  uses an out-of-band TCP channel to control module  110  to request the value of the SeqAckAdjustment in order for it to adjust the data packet. Alternatively, control module  104  can use the out-of-band TCP channel to explicitly request control module  110  to retransmit the SYN-ACK packet. 
   According to a preferred embodiment of the invention, control module  104  adjusts the data packets from destination  112  to source  102  by computing the SeqAckAdjustment. The SeqAckAdjustment may be computed by subtracting the destination_isn from the synth_isn. Therefore, after control module  104  computes the SeqAckAdjustment, it adjusts and releases the data packet that is temporarily stored in the memory area. For example, control module  104  adjusts the stored data packets by adding the computed SeqAckAdjustment to the data packet&#39;s sequence number and making a corresponding adjustment to the data packet&#39;s checksum. Control module  104  then sends the adjusted data packet to source  102 . In addition, if control module  104  receives a data packet from destination  112 , for example, at M, it adjusts the received data packet by, for example, adding the computed SeqAckAdjustment to the data packet&#39;s sequence number and making a corresponding adjustment to the data packet&#39;s checksum. Control module  104  then sends the adjusted data packet to source  102  at N. 
   In addition, after control module  104  computes the SeqAckAdjustment and receives a data packet from source  102 , for example, at O, it adjusts the received data packet by, for example, subtracting the computed SeqAckAdjustment from the data packet&#39;s acknowledgment number and making a corresponding adjustment to the data packet&#39;s checksum. Control module  104  then sends the adjusted data packet to destination  112  at P without any characterizing. Since this data packet is not characterized, control module  110  does not intercept the data packet on its way to destination  112 . Thus, the characterization-free data packet is directly transmitted to destination  112  without any interference from control module  110 . From this point on, normal TCP transaction may continue without further involvements from control module  110 . For the rest of the packets in this TCP transaction, processing of the sequence number for packets going from destination  112  to source  102  (e.g., at Q and R) and of the acknowledgment numbers for packets going from source  102  to destination  112  (e.g., at O and P) will be done by control module  104 . 
   As can be seen, by intercepting the SYN packet from source  102  and sending the synthesized SYN-ACK packet to source  102  in response to the SYN packet, control module  104  allows source  102  to begin transmitting application-layer data to destination  112  without waiting for the real SYN-ACK packet from destination  112 . This speeds up TCP&#39;s initial session establishment, especially for multiple short TCP transactions that are serially executed. By having control module  110  cooperating with control module  104 , embodiments of the invention optimize TCP&#39;s initial session establishment without intruding upon TCP&#39;s core algorithms. 
     FIGS. 4A and 4B  are flowcharts illustrating a TCP optimization routine that is implemented by one embodiment of the present invention and executed by control module  104  associated with source  102 . In a preferred embodiment of the invention, control module  104  observes one or more responses of destination  112  to a SYN packet to determine the TCP options used in response to the TCP options in the SYN packet for the IP address of destination  112 . Control module  104  thus determines the IP address and TCP option combination of destination  112  based on the observed responses. Control module  104  then determines  404  if the IP address and TCP option combination of destination  112  have been consistent. If the IP address and TCP option combination have been consistent, control module  104  activates  406  the IP address and TCP option combination of destination  112 . If the IP address and TCP option combination have not been consistent, control module  104  returns to step  402  to observe further responses of destination  112  to SYN packets sent by source  102 . 
   Control module  104  receives  408  a SYN packet from source  102 . Based on the received SYN packet, control module  104  generates a synthesized SYN-ACK packet having the IP address, port number, and TCP option combination of destination  112 . Control module  104  also predictably or arbitrarily decides an initial sequence number called synth_isn and inserts the synth_isn into the synthesized SYN-ACK. Control module  104  then sends the synthesized SYN-ACK to source  102 . Control module  104  further characterizes the SYN packet received from source  102  and sends the characterized SYN packet to destination  112 . 
   After control module  104  sends the synthesized SYN-ACK to source  102 , it receives  410  an ACK packet from source  102 , characterizes the ACK packet, and sends the characterized ACK packet to destination  112 . Control module  104  then determines  412  if a data packet arrives from source  102 . If a data packet arrives from source  102 , control module  104  characterizes  414  the data packet received from source  102  and sends the characterized data packet to destination  112 . After control module  104  sends the characterized data packet to destination  112  or if a data packet does not arrive from source  102 , control module  104  determines  416  if a data packet arrives from destination  112 . If a data packet arrives from destination  112 , control module  104  stores  418  the data packet received from destination  112 . 
   After control module  104  stores the data packet received from destination  112  or if a data packet does not arrive from destination  112 , control module  104  receives  420  a SYN-ACK packet from destination  112 . Control module  104  finds out the sequence number of destination  112  (referred to as destination_isn) from the received SYN-ACK packet. In a preferred embodiment of the invention, control module  104  also computes an adjustment number called SeqAckAdjustment by, for example, subtracting the destination_isn from the synth_isn. Control module  104  also consumes  422  the SYN-ACK packet to prevent it from reaching source  102 . Control module  104  further determines  424  if the SYN-ACK packet was formed as expected (i.e., it is consistent with the determined IP address and TCP option combination of destination  112 ). If the SYN-ACK packet was not formed as expected, control module  104  deactivates the IP address and TCP option combination of destination  112  and returns to step  402  to observe further responses of destination  112  to SYN packets sent by source  102 . 
   If the SYN-ACK packet was formed as expected, control module  104  sends  426  the stored data packet, if any, to source  102  after adjusting the data packet. For example, control module  104  can adjust the data packet by adding the SeqAckAdjustment to the data packet&#39;s sequence number and making a corresponding adjustment to the data packet&#39;s checksum. Control module  104  then determines  428  if a data packet arrives from destination  112 . If a data packet arrives from destination  112 , control module  104  sends  430  the data packet to source  102  after adjusting the data packet. Control module  104  can adjust the data packet by, for example, adding the SeqAckAdjustment to the data packet&#39;s sequence number and making a corresponding adjustment to the data packet&#39;s checksum. Control module  104  then determines  432  if a data packet arrives from source  102 . 
   If a data packet does not arrive from destination  112 , control module  104  also determines  432  if a data packet arrives from source  102 . If a data packet arrives from source  102 , control module  104  sends  434  the data packet to destination  112  without any characterizing after adjusting the data packet. The data packet can be adjusted, for example, by subtracting the SeqAckAdjustment from the data packet&#39;s acknowledgment number and making a corresponding adjustment to the data packet&#39;s checksum. Control module  104  then returns to step  428  to determine if a data packet arrives from destination  112 . Alternatively, if a data packet does not arrive from source  102 , control module  104  also returns to step  428  to determine if a data packet arrives from destination  112 . The process flow continues until either source  102  or destination  112  terminates the TCP session. 
     FIG. 5  is a flowchart illustrating a TCP optimization routine that is implemented by one embodiment of the present invention and executed by control module  110  associated with destination  112 . Control module  110  receives  502  a characterized SYN packet from source  102 . Control module  110  removes the characterization from the SYN packet and sends the characterization-free SYN packet to destination  112 . Control module  110  then determines  504  if a characterized ACK packet arrives from source  102 . If a characterized ACK packet arrives from source  102 , control module  110  stores  506  the ACK packet arrived from source  102 . 
   After control module  110  stores the ACK packet received from source  102 , control module  110  receives  508  a SYN-ACK packet from destination  112 . Control module  110  finds out the destination_isn from the received SYN-ACK packet and sends the SYN-ACK to source  102 . In a preferred embodiment of the invention, control module  110  computes an adjustment number called SeqAckAdjustment by, for example, subtracting the destination_isn from the synth_isn. 
   Control module  110  also sends  510  the stored ACK packet, if any, to destination  112  after adjusting the ACK packet and removing the characterization from the ACK packet. For example, control module  110  can adjust the ACK packet by subtracting the SeqAckAdjustment from the ACK packet&#39;s acknowledgment number and making a corresponding adjustment to the ACK packet&#39;s checksum. 
   Control module  110  further determines  512  if a characterized data packet arrives from source  102 . If a characterized data packet arrives from source  102 , control module  110  removes  514  the characterization from the data packet, adjusts the data packet, and sends the characterization-free data packet to destination  112 . The data packet can be adjusted, for example, by subtracting the SeqAckAdjustment from the data packet&#39;s acknowledgment number and making a corresponding adjustment to the data packet&#39;s checksum. The process then returns to step  512 . If a characterized data packet does not arrive from source  102 , control module  110  loops back to step  512  until source  102  or destination  112  terminates the TCP session. 
   While particular embodiments and applications of the present invention have been illustrated and described herein, it is to be understood that the invention is not limited to the precise construction and components disclosed herein and that various modifications, changes, and variations may be made in the arrangement, operation, and details of the methods and apparatuses of the present invention without departing from the spirit and scope of the invention as it is defined in the appended claims.

Technology Category: h