HK1199153B - Method and system of accelerating service processing using fast path tcp - Google Patents

Description

Method and system for accelerating service processing by using fast path TCP

Cross Reference to Related Applications

This application claims priority to U.S. provisional patent application serial No. 61/564,575, filed on 29/11/2011, which is hereby incorporated by reference in its entirety.

Technical Field

The present invention relates generally to data communications, and more particularly to serving gateways.

Background

Fast path HTTP is the implementation of HTTP proxy services in service gateways, such as server load balancers or application delivery controllers. An example of fast path HTTP may be found in, for example, A10Networks^TMAX series server load balancers. Fast path HTTP is typically optimized for high performance with the support of hardware-based accelerators. The main difference between typical or normal HTTP implementations and fast path HTTP modes is that the operation (handling) of the underlying TCP (transmission control protocol) session of fast path HTTP does not use a normal or full TCP stack. In contrast, fast path HTTP usage speedThe fast path or sequence of operations (SEQ) and the Acknowledgement (ACK) number adjusted lightweight (LW-TCP) stack are used for proxy purposes without the packet buffering used in the normal TCP stack. Therefore, the fast path HTTP processing can achieve a higher level of performance than the normal HTTP processing.

However, the lack of a normal TCP stack can pose challenges for extreme conditions and specific protocol operations. In one example, when a TCP packet including a partial HTTP request is received at a service gateway, wherein the partial HTTP request includes a partial URL. The partial URI information may not include enough information for a service gateway (such as an HTTP server load balancer) to select a backend server. In this example, the service gateway needs to wait for additional TCP packets carrying the remaining HTTP requests. However, to avoid the client of the HTTP request unnecessarily re-sending the previously received TCP packets, the service gateway needs to send a TCP ACK to the client. In a different protocol operating scenario, the service gateway may need to resend the TCP packet to the server. This manipulation and resending of ACKs is found in normal TCP stack implementations and requires additional processing in a typical LW-TCP stack.

Even if the occurrence of extreme conditions is rare, given the various combinations of extreme conditions in an actual network, the specific operations in the fast path HTTP or LW-TCP modules are prone to errors and performance can be affected. Any performance increase of fast path HTTP may be offset by extreme case handling. However, it is appropriate not to consider any specific operations in fast path HTTP, but rather to allow these conditions to be handled by normal HTTP processing.

Therefore, there is a need for a system and method that transitions from a fast path HTTP processing scenario to normal HTTP processing.

Disclosure of Invention

According to one embodiment of the invention, a service gateway comprises: a fast path module for processing a data packet without using a packet buffer (buffer); and a normal path module for processing the data packets using one or more data packet buffers; wherein the fast path module: receiving a service request data packet from a client side session between a client and a service gateway; determining that the service request packet cannot be processed by the fast path module; and in response to a determination that the service request data packet cannot be processed by the fast path module, send the service request data packet to the normal path module, wherein in response to receiving the service request data packet from the fast path module, the normal path module: retrieving a first proxy session record created by the fast path module, wherein the first proxy session record is associated with a client session record for a client-side session; generating a second proxy session record based on the service request data packet and the client session record associated with the first proxy session record; and processing the service request packet according to the second proxy session record.

In one aspect of the invention, wherein upon determining that the service request packet cannot be processed by the fast path module, the fast path module: determining a service request data packet: does not include a full HTTP header; only partial URIs; only partial HTTP header fields; only a partial HTTP Cookie field; indicating the IP packet fragment; including unexpected URIs; not including an expected cookie field; or not include the expected HTTP header attributes.

In one aspect of the invention, wherein, in creating the second proxy session record, the normal path module: creating a second client session record based on the client session record associated with the first proxy session record and the service request data packet; and associating the second client session record with the second proxy session record.

In one aspect of the invention, wherein the client session comprises a TCP session, wherein in creating the second proxy session record, the normal path module is further to: obtaining a client session receiving initial sequence number and a client session sending initial sequence number from a client session record associated with the first proxy session record; creating one or more TCP session state variables and one or more packet buffers for the client side session; and storing the client session receive initial sequence number, the client transmit initial sequence number, and the one or more TCP session state variables in a second client session record.

In one aspect of the invention, the fast path module further: determining that the service request packet can be processed by the fast path module; in response to a determination that the service request packet can be processed by the fast path module, adjusting the sequence number in the service request packet using the calculated client session sequence number adjustment stored in the first proxy session record; and sending the adjusted service request packet over a server-side session between the server and the service gateway.

In one aspect of the invention, in adjusting the sequence number in the service request packet, the fast path module: adjusting the sequence number in the service request data packet by the calculated client session sequence number adjustment amount; and adjusting the acknowledgment number in the service request packet by the calculated client session sequence number adjustment.

Systems and methods corresponding to the service gateway summarized above are also described and claimed herein.

Drawings

Fig. 1 shows an embodiment of a service gateway for providing a service for a service application between a client device and a server device according to the present invention.

Figure 2 shows an embodiment of a service gateway according to the present invention.

Fig. 3 illustrates an embodiment of a fast path service application processing TCP session requests according to the present invention.

Fig. 4 illustrates an embodiment of a fast path service application processing HTTP service requests according to the present invention.

Fig. 5 shows an embodiment of establishing a server session according to the invention.

Fig. 5a shows an embodiment of calculating a client session sequence number adjustment according to the present invention.

Fig. 5b illustrates an embodiment of calculating a server session sequence number adjustment amount according to the present invention.

Fig. 6 shows an embodiment of forwarding a data packet from a server device to a client device according to the invention.

FIG. 7 illustrates an embodiment of a switch from a fast path module to a normal path module according to the present invention.

Fig. 8 illustrates an embodiment of creating a proxy session record for a normal path TCP module using a proxy session record for a fast path TCP module according to the present invention.

Detailed Description

The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the embodiments will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.

The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software (which includes but is not limited to firmware, resident (residual) software, microcode, etc.

Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a Random Access Memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W), and DVD.

A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage (bulk storage), and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

Input/output or IO devices (including but not limited to keyboards, displays, pointing devices (point devices), etc.) can be coupled to the system either directly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified native function(s). It should be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

Fig. 1 shows an embodiment of a service gateway 300 handling an application session 400 between a client device 100 and a server device 200 according to the present invention.

The embodiment of the service gateway 300 shown in figure 2 is operatively coupled to a processor module 310, a memory module 320, a network interface module 350, and a computer-readable module 340. The computer readable medium 340 stores computer readable program code that, when executed by the processor module 310 using the storage module 320, implements the various embodiments of the invention described herein. In certain embodiments, the service gateway 300 is implemented as a server load balancer, an application delivery controller, a service delivery platform, a traffic manager, a security gateway, a component of a firewall system, a component of a Virtual Private Network (VPN), a load balancer for a video server, a gateway that distributes load to one or more servers, a Web or HTTP server that operates the HTTP layer of an HTTP session service, or a gateway that performs Network Address Translation (NAT).

In one embodiment, the computer-readable medium 340 includes instructions 310 for the service application 500 and the processor module executes the service application 500. Embodiments of the service application 500 include server load balancing services, network address translation, firewalls, remote access services, HTTP proxy services, TCP proxy services, audio or video streaming services, Web services, content delivery services, WAN optimization services, mobile internet services, and content caching services.

Returning to fig. 1, the client device 100 is typically a computing device with network access capabilities. In one embodiment, the client device 100 is a workstation, desktop or laptop personal computer, Personal Data Assistant (PDA), tablet computing device, smart phone, or cellular phone, set-top box, internet media browser, internet media player, smart sensor, smart medical device, network-top box (net-top box), networked television, networked DVR, networked blu-ray player, networked handheld gaming device, or media center.

In one embodiment, the client device 100 is a cell broadband gateway, an enterprise internet gateway, an enterprise Web proxy, a network Customer Premises Equipment (CPE), or an internet access gateway.

In one embodiment, the client device 100 includes a Broadband Remote Access Server (BRAS), a Digital Subscriber Line Access Multiplexer (DSLAM), a Cable Modem Termination System (CMTS), or a service provider access gateway.

In one embodiment, the client device 100 comprises a mobile broadband access gateway, such as a Gateway GPRS Support Node (GGSN), a Home Agent (HA), or a PDN Gateway (PGW).

In one embodiment, the client device 100 includes a server load balancer, an application delivery controller, a traffic manager, a firewall, a VPN server, a remote access server, or a corporate or data center access gateway.

In one embodiment, the client device 100 is a device that includes similar components as the service gateway 300.

The client apparatus 100 initiates the application session 400 to the server apparatus 200.

The server device 200 is a computing device typically coupled to a processor and a computer readable medium storing computer readable program code. The server device 200 utilizes a processor and computer readable program code to implement the functionality of a Web server, file server, video server, database server, application server, voice system, conferencing server, media gateway, media center, application server, or Web server that uses the application session 400 to provide TCP-based services or application services to the client device 100.

Embodiments of application session 400 include HTTP sessions, file transfer sessions, TCP-based video streaming sessions, TCP-based music or video streaming media sessions, file download sessions, group conferencing sessions, database access sessions, remote terminal access conferences, Telnet sessions, e-commerce transactions, remote program calls, and other uses of TCP communication sessions.

The service application 500 includes a fast path module 520 and a normal path module 550. The normal path module 550 processes the application session 400 using typical TCP packet buffering mechanisms known to those skilled in the art. The fast path module 520 processes TCP packets of the application session 400 without packet buffers. Both processes will be described later in this specification.

FIG. 3 illustrates an embodiment of a process of the fast path module 520 according to the present invention. In one embodiment, the client device 100 sends a TCP session request 402 packet to the service gateway 300 to establish a client TCP session 430 for the application session 400. The service application 500 receives the TCP session request 402 and uses the fast path module 520 to manipulate the TCP session request 402. In one embodiment, the fast path module 520 includes a fast path TCP module 523 and a fast path service module 527.

Fast path TCP module 523 receives TCP session request 402 and creates client session record 543 and associated proxy session record 540. In one embodiment, proxy session record 540 includes client session record 543. In one embodiment, the service application 500 is connected to a memory 502 (such as the memory module 320). Fast path TCP module 523 stores proxy session record 540 and client session record 543 in store 502. Fast path TCP module 523 obtains several pieces of information from TCP session request 402 and stores the information in client session record 543. In one embodiment, the information of TCP session request 402 includes one or more of client session receive initial sequence number 433, IP source and destination addresses, TCP source and destination port numbers, lower layer network addresses (such as MAC address, VLAN address, WLAN address), and information about link layer, physical layer, tunnel (tunneling) session obtained from or using TCP session request 402.

In one embodiment, the fast path TCP module 523 accepts the TCP session request 402 and responds with a TCP session accept 413 packet, in which embodiment the fast path TCP module 523 generates an initial sequence number 437 or a client session send initial sequence number 437 in response to the TCP request packet 402. The fast path TCP module 523 stores the initial sequence number 437 in the client session record 543, sends a TCP session accept 413 to the client device 100, and establishes the client session 430.

In one embodiment, shown in FIG. 4, after establishing the client session 430, the client device 100 sends a service request 404 data packet to the service gateway 300 over the client session 430 to establish an application-level session for the application session 400. In one embodiment, service request 404 comprises HTTP request 405. Service application 500 receives service request 404. Fast path TCP module 523 compares service request 404 to one or more client session records in memory 502 and obtains client session record 543 corresponding to client session 430.

The service application 500 calls the fast path service module 527 to process the service request 404. In one embodiment, the fast path service module 527 retrieves the HTTP request 405 from the service request 404 and selects the server device 200 to service the HTTP request 405. In one embodiment, the fast path service module 527 instructs the fast path TCP module 523 to establish a server TCP session 470 with the server device 200. Fast path TCP module 523 creates server session record 547 and associates server session record 547 with proxy session record 540. In one embodiment, the fast path TCP module 523 stores the server session record 547 in the memory 502. In one embodiment, proxy session record 540 includes server session record 547.

In one embodiment, fast path TCP module 523 creates a server session send initial sequence number 477 and uses initial sequence number 477 to create TCP session request packet 408. The fast path TCP module 523 sends the TCP session request 408 to the server apparatus 200. In one embodiment, server device 200 accepts TCP service request 408 and responds with TCP session accept packet 409. Fast path TCP module 523 retrieves a message from TCP session accept 409, which in one embodiment, TCP session accept 409 message includes server session receive initial sequence number 478. The fast path TCP module 523 stores the initial sequence number 478 in the server session record 547.

In one embodiment shown in fig. 5, the fast path service module 527 sends the service request 404 to the server device 200 through the fast path TCP module 523. The fast path TCP module 523 further modifies the service request 404. In one embodiment, service request 404 includes a TCP header 415. In one embodiment, fast path TCP module 523 adjusts sequence number 417 and acknowledgement number 419 in TCP header 415. As shown in fig. 5a, fast path TCP module 523 uses client session receive initial sequence number 433 in client session record 543 and server session send initial sequence number 477 in server session record 547 to calculate client session sequence number adjustment 447. In one embodiment, fast path TCP module 523 subtracts client session receive initial sequence number 433 from server session send initial sequence number 477 to obtain client session sequence number adjustment 447.

In one embodiment, fast path TCP module 523 stores client session sequence number adjustment 447 in proxy session record 540.

In one embodiment shown in fig. 5b, fast path TCP module 523 similarly calculates server session sequence number adjustment 449 by subtracting server session receive initial sequence number 478 in server session record 547 from client session send initial sequence number 437 in client session record 543. In one embodiment, fast path TCP module 523 stores server session sequence number adjustment 449 in proxy session record 540.

Returning to the diagram in fig. 5, in one embodiment, fast path TCP module 523 adjusts sequence number 417 by adding client session sequence number adjustment 447.

In one embodiment, fast path TCP module 523 adjusts acknowledgement number 419 by adding server session sequence number adjustment 449.

The fast path TCP module 523 sends the adjusted service request 404' to the server device 200.

In one embodiment, the service gateway 300 receives a TCP packet 403 of a client session 430 from the client device 100. The fast path TCP module 523 adjusts the data packet 403 before sending the adjusted data packet 403' to the server device 200. Similar to the above adjustment, the fast path TCP module 523 adjusts the sequence number and acknowledgement number of the packet 403. The fast path TCP module 523 transmits the adjusted packet 403' to the server apparatus 200.

In one embodiment shown in fig. 6, the server device 200 sends a TCP packet 407 of the server session 470 to the service gateway 300. The fast path TCP module 523 receives the data packet 407 and adjusts the data packet 407 before sending the adjusted data packet 407' to the client device 100. Fast path TCP module 523 adjusts sequence number 416 and acknowledgement number 418 of packet 407. In one embodiment, fast path TCP module 523 adjusts the sequence number field of packet 407 by subtracting server session sequence number adjustment 449. In one embodiment, fast path TCP module 523 adjusts the acknowledgement sequence number field of packet 407 by subtracting client session sequence number adjustment 447. The fast path TCP module 523 sends the adjusted packet 407' to the client device 100.

In one embodiment, the sequence number adding and subtracting steps need to take into account the surrounding TCP sequence packets, as known to those skilled in the art.

In one embodiment, the fast path service module 527 modifies the service request 404, the data packet 407, or the data packet 403. The fast path service module 527 notifies the fast path TCP module 523 of any packet length adjustments due to packet modifications. The fast path TCP module 523 applies the appropriate adjustment to the sequence number adjustment step based on the signaled packet length adjustment.

In one embodiment, shown in fig. 7, the fast path service module 527 determines that it cannot process the service request 404. The service application 500 instructs the fast path service module 527 to send the service request 404 to the normal path module 550. In one embodiment, the fast path service module 527 determines that the service request 404 includes a partial HTTP header 412. In one embodiment, the partial HTTP header 412 does not include all necessary information to be processed by the fast path service module 527, including one or more conditions such as including a full HTTP header, a partial URI, a partial HTTP header field, or a partial Cookie field. In one embodiment, the partial HTTP header 412 indicates that the service request 404 is an IP packet fragment. In one embodiment, the fast path service module 527 is unable to process the service request 404 when the service request 404 includes unexpected information, such as an unexpected URI, missing an expected cookie field, or missing an expected HTTP header attribute. In one embodiment, the fast path service module 527 determines an error condition (condition) when processing the service request 404.

The fast path service module 527 sends the service request 404 to the normal path module 550. In one embodiment, the normal path TCP module 553 receives the service request 404 from the fast path TCP module 523 and retrieves the proxy session record 540. The normal path TCP module 553 creates a proxy session record 560 based on the service request 404 and the proxy session record 540.

As shown in the embodiment of fig. 8, normal path TCP module 553 creates a client session record 563 based on client session record 543 and service request 404 associated with proxy session record 540. Normal path TCP module 553 obtains client session receive initial sequence number 433 and client session send initial sequence number 437 from client session record 543 and stores them in client session record 563. The normal path TCP module 553 creates other necessary TCP session state variables and buffers for the client session 430. These TCP session state variables and buffers are known to those skilled in the art and are not described herein. In one embodiment, the normal path TCP module 553 stores these TCP session state variables and buffers in the client session record 563. Normal path TCP module 553 associates client session record 563 with proxy session record 560. In one embodiment, proxy session record 560 includes client session record 563. In one embodiment, the normal path TCP module 553 stores the proxy session record 560 in the memory 502.

Returning to the diagram in fig. 7, the normal path TCP module 553 then processes the service request 404 as if the normal path TCP module 553 received the service request 404 from the client session 430. The normal path TCP module 553 performs the usual TCP protocol steps for the service request 404 as known to those skilled in the art.

In one embodiment, the normal path TCP module 553 notifies the normal path service module 557 of the service request 404. In one embodiment, the service request 404 is an HTTP request. The normal path service module 557 processes HTTP requests. The normal handling of HTTP requests for service requests 404 is known to those skilled in the art. Such typical processing includes selecting the server apparatus 200, establishing a normal server TCP session 470 with the server apparatus 200, receiving a TCP packet from the client session 430 (server session 470), processing a sequence number field and an acknowledgement field of the received TCP packet, forwarding the content of the received TCP packet to the server session 470 (client session 430), generating a TCP packet for the server session 470 (client session 430) based on the forwarded content, calculating a sequence number field and an acknowledgement field of the generated TCP packet, and transmitting the generated TCP packet. The details of the processing are known to those skilled in the art and will not be described further herein.

In one embodiment, the service request 404 is a SIP request, or other request known to those skilled in the art. The general processing of such service requests by the normal path module 550 is not further described herein.

Although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.

Claims (12)

1. A service gateway, comprising:

a fast path module to process data packets without using packet buffers, the fast path module stored in memory at the service gateway and executed by at least one processor; and

a normal path module for processing the data packets using one or more packet buffers;

wherein the fast path module:

receiving a service request data packet from a client side session between a client and the service gateway;

determining that the service request packet cannot be processed by the fast path module; and is

In response to a determination that the service request data packet cannot be processed by the fast path module, send the service request data packet to the normal path module for processing data packets using one or more data packet buffers, the normal path module stored in memory at the service gateway and executed by the at least one processor,

wherein, in response to receiving the service request packet from the fast path module, the normal path module:

retrieving a first proxy session record created by the fast path module, wherein the first proxy session record is associated with a client session record of the client-side session;

creating a second proxy session record and a second client session record based on the service request data packet and the client session record associated with the first proxy session record;

associating the second client session record with the second proxy session record;

obtaining a client session receive initial sequence number and a client session transmit initial sequence number from the client session record associated with the first proxy session record;

creating one or more TCP session state variables and one or more packet buffers for the client side session;

storing the client session receive initial sequence number, the client session send initial sequence number, and the one or more TCP session state variables in the second client session record; and is

Processing the service request data packet according to the second proxy session record.

2. The service gateway of claim 1, wherein, upon determining that the service request packet cannot be processed by the fast path module, the fast path module:

determining that the service request packet:

does not include a full HTTP header;

only partial URIs;

only partial HTTP header fields;

only a partial HTTP Cookie field;

indicating an IP data packet fragment;

including unexpected URIs;

does not include an expected Cookie field; or

Not including the expected HTTP header attributes.

3. The service gateway of claim 1, wherein the fast path module is further to:

determining that the service request data packet can be processed by the fast path module;

in response to determining that the service request packet can be processed by the fast path module, adjusting a sequence number in the service request packet using the calculated client session sequence number adjustment stored in the first proxy session record; and is

Sending the adjusted service request packet over a server-side session between a server and the service gateway.

4. The serving gateway of claim 3, wherein, in adjusting the sequence number in the service request packet, the fast path module:

adjusting the sequence number in the service request data packet by the calculated client session sequence number adjustment amount; and is

Adjusting the acknowledgment number in the service request packet by the calculated client session sequence number adjustment.

5. A method of processing HTTP packets by a service gateway implemented by a processor, comprising:

receiving, by a fast path module of the service gateway implemented by the processor, a service request packet from a client-side session between a client and the service gateway, wherein the fast path module processes the packet without using a packet buffer;

determining that the service request packet cannot be processed by the fast path module;

in response to a determination that the service request data packet cannot be processed by the fast path module, sending the service request data packet from the fast path module to a normal path module of the service gateway implemented by the processor, wherein the normal path module processes data packets using one or more packet buffers;

in response to receiving the service request data packet from the fast path module, retrieving, by the normal path module, a first proxy session record created by the fast path module, wherein the first proxy session record is associated with a client session record of the client-side session;

creating, by the normal path module, a second proxy session record and a second client session record based on the service request data packet and the client session record associated with the first proxy session record, wherein the creating comprises:

obtaining, by the normal path module, a client session receive initial sequence number and a client session transmit initial sequence number from the client session record associated with the first proxy session record;

creating one or more TCP session state variables and one or more packet buffers for the client side session; and is

Storing the client session receive initial sequence number, the client session send initial sequence number, and the one or more TCP session state variables in the second client session record;

associating the second client session record with the second proxy session record; and

processing, by the normal path module, the service request packet according to the second proxy session record.

6. The method of claim 5, wherein determining that the service request packet cannot be processed by the fast path module comprises determining that the service request packet:

does not include a full HTTP header;

only partial URIs;

only partial HTTP header fields;

only a partial HTTP Cookie field;

indicating an IP data packet fragment;

including unexpected URIs;

does not include an expected Cookie field; or

Not including the expected HTTP header attributes.

7. The method of claim 5, further comprising:

determining that the service request data packet can be processed by the fast path module;

in response to determining that the service request packet can be processed by the fast path module, adjusting a sequence number in the service request packet using the calculated client session sequence number adjustment stored in the first proxy session record; and

sending the adjusted service request data packet through a server-side session between a server and the service gateway.

8. The method of claim 7, wherein adjusting the sequence number in the service request packet comprises:

adjusting the sequence number in the service request data packet by the calculated client session sequence number adjustment amount; and

adjusting the acknowledgment number in the service request packet by the calculated client session sequence number adjustment.

9. A system for expediting service processing using fast path TCP, comprising:

a processor; and

a computer readable storage medium having computer readable program code embodied therewith, the computer readable program code when executed by the processor configured to:

receiving, at a network interface, a service request packet from a client-side session between a client and a service gateway through a fast path module of the service gateway implemented by the processor, wherein the fast path module processes the packet without using a packet buffer;

determining that the service request packet cannot be processed by the fast path module;

in response to a determination that the service request data packet cannot be processed by the fast path module, sending the service request data packet from the fast path module to a normal path module of the service gateway implemented by the processor, wherein the normal path module processes data packets using one or more packet buffers;

in response to receiving the service request packet from the fast path module, retrieving, by a network interface of the normal path module, a first proxy session record created by the fast path module, wherein the first proxy session record is associated with a client session record of the client-side session;

creating, by the normal path module, a second proxy session record and a second client session record based on the service request data packet and the client session record associated with the first proxy session record;

associating the second client session record with the second proxy session record;

obtaining, by the normal path module, a client session receive initial sequence number and a client session transmit initial sequence number from the client session record associated with the first proxy session record;

creating one or more TCP session state variables and one or more packet buffers for the client side session; and is

Storing the client session receive initial sequence number, the client session send initial sequence number, and the one or more TCP session state variables in the second client session record; and

processing, by the normal path module, the service request packet according to the second proxy session record.

10. The system of claim 9, wherein the computer readable program code configured to determine that the service request packet cannot be processed by the fast path module is further configured to determine that the service request packet:

does not include a full HTTP header;

only partial URIs;

only partial HTTP header fields;

only a partial HTTP Cookie field;

indicating an IP data packet fragment;

including unexpected URIs;

does not include an expected Cookie field; or

Not including the expected HTTP header attributes.

11. The system of claim 9, wherein the computer readable program code is further configured to:

determining that the service request data packet can be processed by the fast path module;

in response to determining that the service request packet can be processed by the fast path module, adjusting a sequence number in the service request packet using the calculated client session sequence number adjustment stored in the first proxy session record; and

sending the adjusted service request data packet through a server-side session between a server and the service gateway.

12. The system of claim 11, wherein the computer readable program code configured to adjust the sequence number in the service request packet is further configured to:

adjusting the sequence number in the service request data packet by the calculated client session sequence number adjustment amount; and

adjusting the acknowledgment number in the service request packet by the calculated client session sequence number adjustment.