File-related content that traverses a WAN link over CIFS can range from just a few bytes to several gigabytes in size. CIFS, which is most commonly used between Microsoft Windows–based clients and servers, provides a protocol for accessing named pipes, network resources, and file shares. Given that CIFS works to make portions of a local file system accessible via a network, file system semantics must be supported over the network between client and server. As such, the CIFS protocol is rather robust, providing over 100 different types of messages that can be exchanged, spread over ten or more different dialects (protocol versions).

An accelerator that provides CIFS acceleration and caching for CIFS must be aware of how clients and servers negotiate the dialect to be used and how to handle the different types of messages that are exchanged between client and server. Some messages can be safely suppressed or otherwise handled locally by the accelerator, without compromise to data integrity or coherency. Other messages are so critical to data integrity and coherency that they must be handled in a synchronous fashion by the origin server, and the accelerator must be prepared to accelerate delivery of such messages to the server. Because CIFS is not dictated by published protocol standards, an accelerator must also be prepared to handle messages that are structured in a way that it does not understand and gracefully pass them through to ensure support for vendor-specific implementations that deviate from others.

When an accelerator with CIFS caching and acceleration capabilities resides in the path of the client to server session, several WAN traffic reduction benefits and performance improvements will be realized, including these:

The most important aspect of a cache is its ability to store entire objects or portions of objects that are usable at an application layer. This stored copy becomes the primary source of benefit when implementing an application-specific cache; the content does not need to be served by the origin server a second time if validation and freshness requirements are met, which also translates to a reduction of the number of bytes that must be served over the potentially low-bandwidth and high-latency WAN. The realized benefits of an application-specific cache increase with each additional request received for a piece of content that already resides within the cache and can be validated as coherent when compared to the copy on the origin server. The benefits of the cache’s ability to re-serve any given piece of cached content can be tracked linearly, based on the number of requests that are processed and serviced following the initial caching of content.

In addition to the reduction in the number of requests that must traverse the WAN, the CIFS messaging overhead is also significantly reduced by the application-specific cache and protocol optimization. Some messages might not be required to traverse the WAN for a client to successfully acquire a given piece of content or search a directory, while others require message exchanges with the origin server. For instance, an accelerator may have performed a read-ahead function (as discussed in the “Read-Ahead” section later in this chapter) and temporarily stored the results of the read-ahead data for use by a user. A request for this data may be satisfied locally, thereby removing the need to send the user’s read request to the origin server.

Many accelerators that optimize CIFS also prefetch large amounts of information about the directory structure and stage this data at the edge of the network. If a user browses a directory structure, the directory traversal data may be served out of the accelerator if it is considered valid. Most accelerators that optimize directory traversal use a very short window of validation on directory traversal data (for example, 30 seconds) to allow directory updates to be received by the user in a timely fashion.

It is those messages that do not need to communicate with the origin server that the application-specific cache will interpret and terminate or otherwise respond to locally at the accelerator. Messages that are critical to data integrity, security, or state, however, must traverse the WAN to ensure compliance with CIFS object freshness and protocol semantics. Such messages include those that provide protocol negotiation, user authentication, user authorization, file locking, file open requests, and write operations. These messages can, however, be optimized through WAN optimization techniques that operate in an application-agnostic manner, including compression, flow optimization, and loss mitigation.

CIFS natively creates a tremendous amount of overhead traffic in native client to server exchanges. In many instances, a seemingly simple operation such as a file open of a 1-MB document might require that over 500 messages be exchanged between the client and the server. In a WAN environment, the maximum throughput that can be achieved is directly impacted by the amount of total network latency and is easily calculated as the number of messages multiplied by the latency per operation.

For instance, in a 100-ms roundtrip WAN, 500 messages being exchanged can lead to upwards of 100 seconds of latency to open a simple document. With CIFS acceleration and CIFS caching, clients benefit from the elimination or reduction of certain types of overhead traffic and potentially the elimination of the redundant transfer of requested files. Reducing the amount of latency experienced by the client during client to server exchanges will improve the overall perceived performance of a given application, file transfer, or other operation. Coupling the accelerator’s capabilities to accelerate the protocol (mitigate latency and minimize bandwidth consumption) with WAN optimization capabilities (discussed in Chapter 6), accelerators can help to improve performance over the WAN to the degree that remote office file servers can be consolidated into a centralized data enter.

Many accelerators rely on a built-in CIFS capability called the opportunistic lock, which is a message sent from the server that can effectively relay the state of a file in question to an end user. The original intent of the opportunistic lock was to enable the client to, when determined safe to do so by the server, leverage optimizations built into the CIFS redirector on the client. These optimizations include client-side read-ahead, write-behind, and other types of operations including local open and lock handling. All of these not only help to improve the client experience, but also minimize the workload on the origin server. In a way, this same information about state is leveraged by accelerators to determine how “safe” it is to apply a specific optimization or set of optimizations to a file that has been requested, and file caching is one of those optimizations. In essence, most accelerators maintain CIFS protocol semantics and apply only a level of optimization that is safe based on what the origin server says the state of the file is and, furthermore, based on what the origin server allows a client to do on his own. In this way, the accelerator is able to employ additional optimizations that work in concert with the capabilities that the server permits the client to utilize.

Opportunistic locks and standard locks are also used to inform any clients requesting a file that the requested file is already in use by another client. The level of access in multiuser, concurrent access, collaborative types of scenarios is largely dependent upon another security mechanism called a share mode, which determines whether or not multiple users have privileges to read, write, delete, or otherwise manipulate a file while someone else is accessing that same file. From the perspective of an accelerator, these state relay messages (authentication, authorization, locking, and others) must not be handled locally and must be passed to the origin server synchronously. This is to ensure full compliance with protocol correctness, content freshness, and security. For instance, if a user accesses a file on a CIFS file server, whether accelerators are optimizing the session or not, and another user is already accessing that same file, the server must notify the requesting user that the file is unavailable for read-write access, as shown in Figure 4-3. Some applications permit multiuser concurrent access scenarios and might permit users to have read privileges to certain areas of the object and read-write privileges to other areas that are not in use.

Figure 4-3. CIFS Notification of File in Use

There are three types of opportunistic locks in the latest CIFS dialect:

An application-specific cache for CIFS within an accelerator will commonly intercept requests over the standard TCP ports used by CIFS—TCP/139 and TCP/445 and many can be configured to accelerate CIFS on non-standard ports if necessary, which is not common. The main purpose of a CIFS application-specific cache is to minimize bandwidth consumption and improve response times for requested content or file transfers. The larger the objects stored in the application-specific cache, the faster the response times will be to any clients who request previously cached content, as compared to accessing the same object over the native WAN. Accelerator-based CIFS caching is useful in environments where file server consolidation is desired, especially environments where large files are present, because the performance provided by the accelerator is similar to that provided by a local file server. Accelerators with CIFS caching and acceleration are equally useful in environments where large objects are being used.

System administrators often use CIFS to distribute large objects across the network. Some of the more common applications that leverage large content objects include computer-aided design/computer-aided manufacturing (CAD/CAM) applications. The objects that these applications create might be as small as a few hundred kilobytes to as large as several hundred megabytes or gigabytes. Applications that focus on graphics and imaging involve a significant amount of detail and, thus, the objects in use consume a tremendous amount of storage capacity. With increased image resolution requirements, the amount of disk usage consumed increases as well. Medical applications that involve imaging consume large amounts of disk storage depending on the type of imaging being done. Enterprise network administrators also commonly leverage CIFS to distribute software updates, operating system patches, or entire operating system images. It is common for these applications to rely upon CIFS drive mappings to a central server in the data center (or a local software distribution server that can then be consolidated once accelerators are deployed).

Each of these large distribution jobs tax the WAN for each request. Regardless of the file’s purpose, an application-specific cache stores the object when safe to do so and can potentially serve it locally, thereby mitigating unnecessary transfer. For environments that require interactive read-write operations against large files, such as CAD/CAM applications, software development applications, and others, CIFS acceleration and caching can leverage the accelerator’s WAN optimization components (discussed in Chapter 6) along side object caching to further improve performance of both read and write operations over the WAN.

For CIFS, the accelerator intercepts and examines each message that is transferred between the client and server. The accelerator determines where the client and server are in their message exchange and what function is being performed, which enables the accelerator to make intelligent decisions on how to process and optimize the conversation. While observing the traffic between hosts, the accelerator can safely eliminate some messages after determining that they are not required by the origin server.

Beyond the messaging resides the requested file itself, which is evaluated within a process different from the CIFS messaging. Each file that traverses the accelerator may or may not be stored on the accelerator’s local disks depending on the level of optimization that the accelerator can safely apply. For content that is stored on the accelerator’s disks, the content might be whole content objects or portions of a given piece of content. A whole content object does not need to be received at the accelerator for the accelerator to successfully cache or serve the portions of traffic that traverse it. If a request arrives at the accelerator, the application-specific cache will deterministically serve the content that is stored on its disks to the client when safe to do so and fetch any missing portions of the partially cached object from the origin server. The application-specific cache will proactively read ahead of the client’s request to fetch the content missing from the partial cache. Overall, this dual method of content fetch and serve will improve the performance to the user and dynamically populate the remaining portions of the partially cached file’s missing data.

An application-specific cache might cache only portions of a given file based on the needs of the requesting application; a partially cached file does not demonstrate a faulty application-specific cache. Figure 4-4 illustrates a partially cached object being served from the accelerator’s cache, while the accelerator is acquiring any missing segments of the content from the origin server.

Figure 4-4. Logical Partial Object Cache Serve

Caching and read-ahead functionality combine to provide a dramatic performance improvement when accessing objects over the WAN. For content requests that can be served locally, the accelerator can respond to data requests when doing so is safe. For content requests that cannot be satisfied by the accelerator, the accelerator can choose to apply additional optimizations such as read-ahead, discussed later in the chapter, to proactively fetch a larger degree of an object, which helps to satisfy future requests for portions of the object locally.

When CIFS requests arrive at the accelerator, cached content is not served to the requesting client until the accelerator has performed validation and it has been deemed safe to do so. The validation process is dependent on a number of factors, including the state of the opportunistic lock supplied to the client and verification with the origin server that the object has not changed. The process of determining the file’s coherency is automated and subject to the origin server’s proper delivery of state and response to inquiries from the accelerator. In any scenario, the origin server will always own the state of the data, thereby ensuring that in hybrid accelerated and nonaccelerated environments where users access from remote locations with accelerators and locations without accelerators, the security, safety, and freshness characteristics are identical with or without the presence of an accelerator that is optimizing or caching CIFS data.

As noted earlier, when an application-specific cache receives a request for content that already partially exists within the cache’s storage, the accelerator may generate additional read requests on behalf of the client to acquire the remaining portions of the partially cached file. The application-specific cache will recognize the pattern created by a client requesting a series of small content reads for a larger content item. Once this pattern has been observed, the application-specific cache will initiate read-ahead requests for the remainder of the content item prior to the actual client’s request for the remaining data. Several applications exhibit the trait of smaller data reads, ultimately building to request an entire file. When operating in this default mode, the application-specific cache transitions from content request cache misses to content request cache hits proactively. To the requesting client, the overall throughput of the WAN appears dramatically faster in the presence of accelerators. With the read-ahead requests having been pipelined between the accelerator and server, latency is significantly reduced.

Optimizations gained by the accelerator are not limited just to the process of caching or read-ahead. Accelerators commonly also provide pipelining for user write requests when safe to do so, which is discussed later in this chapter. Prior to an application-specific cache’s implementation, the origin server would receive write requests directly from the client. When the write requests are intercepted by an application-specific cache, these writes are batched by the application accelerator when applicable, allowing for the writes to be pipelined and streamlined over the WAN. In many cases, write requests are also filtered against the known contents of the cached object to ensure that unnecessary write operations need not traverse the WAN.

When writes are made to the origin server directly by the client, each write requires the origin server to provide acknowledgment to the client for each operation. When writes are sent to a server with accelerators in the network, the accelerator can make a determination, based on safety, on whether or not optimization can be applied that would allow the accelerator to generate acknowledgments on behalf of the server. These acknowledgements allow the accelerator to temporarily buffer data while managing the process of transferring the writes on behalf of the user to the origin server in a more write-optimized fashion. Figure 4-5 illustrates the process of automated write responses from the accelerator to the server.

Figure 4-5. Accelerators and Write-Back Optimization

Many accelerators employ acceleration capabilities for file access protocols other than CIFS, such as the Network File System (NFS) for UNIX environments. The concepts of file protocol acceleration are largely similar to the concepts of acceleration that can be provided to other file access protocols and other application protocols in general. The primary differences among them are the structuring of the messages and the way state is maintained. CIFS, for instance, is an extremely stateful protocol, whereas NFS is stateless and requires that all operations be idempotent. Regardless of the file system protocol in use, an accelerator that performs acceleration and object caching must be employed in a way that preserves data integrity and coherency.

The HTTP application-specific cache functions of an accelerator allow for reactive caching of objects that are requested through on-demand HTTP content requests. To appropriately intercept HTTP traffic via traditional caching, the accelerator must have the ability to natively speak the HTTP protocol. Although HTTP and the secured HTTPS share the same foundational transfer methods, HTTPS is treated differently by accelerators. Session encryption is the primary difference between the protocols, and some accelerators can become a man-in-the-middle through a process of decryption, optimization, and re-encryption. Any responses served locally are re-encrypted, and any requests that must be sent upstream are re-encrypted to maintain security semantics.

An HTTP cache can transparently or explicitly intercept HTTP requests from devices such as personal computers or even personal digital assistants. An HTTP request consists of a connection commonly established over TCP port 80. From a client to a given origin server, the majority of enterprise web traffic uses port 80 and is commonly classified as intranet traffic. If the origin server resides on the public Internet, this traffic is considered Internet traffic. HTTP requests are not limited to TCP port 80 but have been observed on TCP ports 8000, 8001, 8080, 3128, and many other ports. Each one of these ports and any other custom port number can be intercepted by the HTTP application-specific cache based on predefined port number understanding or administrator configuration.

Depending on the version of HTTP supported between the client and origin web server, requests might be sequential, as with HTTP version 1.0 traffic. HTTP 1.0 also requires that a new TCP connection be established between the client and server for each object that is being requested. HTTP 1.1 addresses these limitations by providing support for multiple concurrent connections to be established between the client and the server, thereby minimizing the amount of time that is spent establishing TCP connections. Request pipelining is also supported with HTTP 1.1, although it might not be implemented in some specific web-server or application-server instances. HTTP 1.0 sequential requests require a response for each request, prior to the next request being issued by the client to the web server after establishing a new TCP connection. HTTP 1.0 requests are very inefficient, due to the start and stop nature of the protocol and the start and stop use of TCP as a transport protocol. When combined with a WAN that has a significantly high latency, HTTP 1.0 becomes extremely inefficient to the requesting client and can present a severe performance bottleneck.

Traditional application-specific caches rely on HTTP headers or relative time values to determine the freshness validity of a given piece of content. When a client initiates a request for content from an origin server, through an accelerator with HTTP caching and protocol acceleration, the accelerator first checks the object cache to see if the content already resides within storage. If the content does not exist in storage, the accelerator forwards the request upstream toward the origin server to fetch the content and update the local object cache. When the origin server responds to the request, a copy of the content is served to the user while simultaneously updating the local object cache with the object itself. At this point, the object may be a candidate for use upon receipt of a subsequent request.

If the content already resides in the application-specific cache, the accelerator initiates an HTTP If-Modified-Since (IMS) request to the origin server, checking the date, time, and entity tag, or “ETag,” properties of the content on the origin server within the response header. If the date, time, or ETag properties have changed at the origin server, the server provides the updated content to the accelerator. To prevent the serving of stale content from the accelerator’s cache, newer content will always be acquired, stored, and served to the requesting client. Example 4-1 illustrates the common structure of an HTTP response header that the accelerator will inspect to determine object validity.

NameValueDelimHTTP Status Code: HTTP/1.1 200 OK
Date:Thu, 09 Nov 2006 03:51:20 GMT
Server:Apache/2.0
Last-Modified:Mon, 02 Oct 2006 03:02:18 GMTETag:"345"Accept-Ranges:bytes
Content-Length:837
Content-Type:image/gif
Connection:Close

When an HTTP application-specific cache is combined with compression and other optimization techniques such as read-ahead, the overall traffic that traverses the WAN between a core accelerator and edge accelerator is significantly minimized. Although many web servers today apply gzip or DEFLATE compression to served objects, a cache still bases its decisions on the header properties provided by the web server. Many times, the objects served by the web server contain data patterns that the accelerator can leverage through data suppression algorithms, as discussed in Chapter 6. An object served from a web server might contain patterns that the core and edge accelerators have already recorded, eliminating the traffic patterns found within the response to the client’s HTTP GET. When combined, HTTP caching, read-ahead, transport optimization, compression, and data suppression provide a vast improvement to the requesting user’s web experience.

Although similar to HTTP, HTTPS adds security through encryption to the transfer of content between a client and web server. Unless the accelerator is able to actively participate in the session with the use of a valid key and certificate, the accelerator can provide only WAN optimization components. Both in-session (man-in-the-middle) and out-of-session (TCP flow optimization only) optimization services provide performance improvements to the end user. To provide a greater degree of optimization for HTTPS traffic, accelerators that are participating in the optimization of such flows must either be preloaded with the keys necessary to decrypt encrypted flows or be able to participate in the secure session establishment as a man-in-the-middle using single-sided key distribution and session keys (as opposed to private keys).

To establish a successful HTTPS session between a client and server, the two hosts must establish a secure session based on a successful exchange of certificates and keys. If the negotiation process of the certificate and key cannot be established, the attempt to establish an HTTPS session fails. With a failed HTTPS session, content is not transferred between the origin server and requesting client, and the client must reattempt the certificate and key negotiation or seek an alternative method of access to the origin server.

For accelerators to actively participate in and optimize an HTTPS session, the accelerators in the network path between the client and the server must have access to the proper certificates and keys needed by the origin server. HTTPS certificates and keys must be administratively applied to the accelerators prior to the first secure session traversing the accelerator.

Alternatively, accelerators may employ techniques that allow for single-sided distribution of keys to the data center accelerators and leverage the session establishment and session keys to participate in the encryption and decryption of traffic. In this way, the data center accelerator must become an SSL proxy on behalf of the origin server and may also use its own encryption between the user and itself, as opposed to using the server’s encryption. This type of deployment, which minimizes the distribution of keys outside of the data center, may also create complications in environments with client keys.

Once keys have been distributed to an accelerator, the accelerator can then safely inject itself into the message exchange through the process of decryption and re-encryption. When an accelerator is actively a part of the HTTPS session and receives HTTPS traffic, the secure traffic is first decrypted. After the traffic is decrypted, the accelerator has visibility to the clear-text data being exchanged between the user and the server. With clear-text data visibility, the accelerator can then parse the data for any cacheable content or requests that can be optimized and employ any optimizations that are safe to employ for that particular request.

For content requests that cannot be satisfied locally, the request and any optimized requests are passed through WAN optimization components such as compression and data suppression (discussed in Chapter 6) and then encrypted and sent upstream toward the origin server through the optimized transport. For content requests that can be satisfied locally, the accelerator can fetch the requested object from the local object cache and apply the encryption necessary to serve the object to the user. Other forms of optimization, such as read-ahead and pre-fetching, are employed in a similar fashion. Figure 4-6 illustrates the data flow of an accelerator that is an active participant in an HTTPS session between a client and server.

Figure 4-6. Accelerator with HTTPS Certificate and Key

The next section takes a more in-depth look at SSL and Transport Layer Security (TLS) and how accelerators that provide optimization for encrypted traffic interact with these security layers.

Secure Sockets Layer (SSL) is a cryptographic protocol. This protocol provides session-layer encryption for users and servers to ensure that exchange of application traffic over the network is done in an encrypted manner. For HTTP, SSL provides secured browsing access to targeted hosts that have been configured to support the SSL protocol at the application server. Although SSL can be used for a plethora of application protocols, HTTPS is the most common implementation of SSL and thus is the focus of this section. Not all web servers support SSL, nor do all web servers have SSL enabled, but SSL is becoming progressively more popular given customer security requirements and demands from regulatory bodies. SSL sessions create added requirements and workload on the server and client to properly encrypt and decrypt data, which impacts components such as the CPU and memory subsystems. In many cases, SSL can have an impact on performance given how compute intensive it can be, unless SSL processing is offloaded to a secondary processor, which may be installed as a PCI or PCI/X card within a workstation or server.

SSL has progressed to version 3.0, which offers encrypted authentication and communication between the client and server. When an accelerator is introduced in the path of an SSL session, the client establishes a session with and through the accelerator, which in turn provides the predefined credentials to the origin server.

For an accelerator to actively participate in an HTTPS session between a client and server, a hardware decoder card may be used to offload SSL processing to hardware, thereby nearly eliminating the performance bottleneck that is created by managing SSL in software on the CPU. Such hardware acceleration cards for SSL are intended to reside in an open PCI slot within an accelerator. Although external dedicated HTTPS decryption devices exist today, it is rare to find a dedicated SSL decryption device installed in a remote network location. Many can be found in the data center, however, and are typically deployed in existing server load balancing (SLB) devices.

When implemented in an accelerator, the SSL acceleration card handles the decryption and re-encryption of the session with the requesting client and the origin server. Without such a card present, these functions must be handled by the accelerator CPU and software. The accelerator itself is still responsible for establishing the session setup, key exchanges, and any negotiations required during the establishment of the SSL session. The use of an active SSL card in an accelerator does not completely eliminate the need for added resources at the accelerator but does greatly reduce the processing requirements that consume resources at the accelerator device while optimizing an SSL session.

Transport Layer Security (TLS) version 1.1 is the successor to SSL version 3.0. The primary differences between the two involve recent RSA enhancements to TLS 1.1 that did not exist in SSL 3.0. TLS 1.1 supports RSA, DSA, RC2, triple DES, AES MD2, MD4, MD5, and SHA algorithms. Depending on which is negotiated at the time a session is being established, a TLS 1.1 session might become an SSL 3.0 session. If HTTPS interception and SSL acceleration are enabled on an accelerator, and the required key and certificate have not been provided to the accelerator or are otherwise unavailable, the request transparently passes through the application-specific acceleration capabilities of the accelerator yet may still leverage the benefits provided by the WAN optimization capabilities between accelerator appliances to improve the performance of the connection.