CIFS Optimization
CIFS Optimization
This chapter describes the Common Internet File System (CIFS) protocol optimization module on the SteelHead. This chapter includes the following sections:
•  Overview of CIFS Protocol
•  RiOS CIFS Optimization Techniques
CIFS, also referred to as the Server Message Block (SMB) protocol, has been in existence since the early 1990s. The protocol provides shared access to files and printers, along with other communication between hosts on a network, including an authenticated Inter-Process Communication (IPC) mechanism. It is one of the most common protocols used for network file access by Microsoft operating systems.
The protocol originated as SMB and was created by combined work from IBM and Microsoft. SMB was initially designed to run on top of NetBIOS/NETBEUI but has run directly on top of TCP since the Microsoft Windows 2000 version. SMB was primarily a LAN-based protocol, which accounts for some of the challenges you see when it is used across WAN links. The rename and relaunch from SMB to CIFS occurred in 1996, which was the same time that Sun Microsystems announced WebNFS.
Although CIFS is known as the generic name for the protocol, technical discussions and documents continue to use the term SMB. Since the initial release of SMB, Microsoft has continued to change and enhance the protocol, each time assigning a new version number to SMB. The most recent versions are SMB2, SMB 2.1, SMB3, SMB 3.02, and SMB 3.1.1.
For information about SMB versions, see Overview of SMB Versions 2, 2.1, 3, 3.02, and 3.1.1.
Note: For the purpose of this chapter, the terms SMB and CIFS are used interchangeably.
RiOS has provided CIFS optimization since version 1.0, with ongoing enhancements in each subsequent version. CIFS optimization focuses on reducing the impact of WAN round-trip latency of common application and system behavior, including the Microsoft Office product suite, general file access, and remote printing. Ongoing work has been necessary to adjust to new incremental changes introduced to the protocol from Microsoft, typically with each new Microsoft operating system version. Additionally, new features have been added that enhance and broaden the applicability of the CIFS optimization.
RiOS includes optimization for SMB signed traffic. SMB signed refers to an optional feature in which the client and server, using the CIFS protocol, use cryptographic techniques to sign each protocol datagram exchanged in a CIFS session. This technique does not encrypt data passing through the network; it merely authenticates that the client and server receive datagrams that have not been modified by unauthorized middle devices. Through specific configuration and integration into the Windows security domain, RiOS can perform full latency and bandwidth optimization securely for SMB signed traffic, while still maintaining the end-to-end authentication that SMB signing was designed to achieve.
While SMB signing does not encrypt the data, SMB3 can encrypt traffic. If you use the correct RiOS release with the appropriate configuration settings, RiOS can continue to provide full-latency and bandwidth optimization while maintaining a secure client-server communication.
For information about configuring CIFS optimization, see the SteelHead Management Console User’s Guide.
Overview of CIFS Protocol
This section describes the base CIFS protocol and how RiOS performs CIFS optimization. For example, for a client to access a file on a CIFS server, the following steps generally occur on the client:
1. Parse the full filename to determine the server name.
2. Establish a TCP connection to the server.
3. Negotiate what type of SMB dialect and option is used with the server.
4. Transfer credentials and authenticate access to the server.
5. Open the file for operations by sending the filename and desired access to the server.
6. Perform read, write, or other operations on the file, typically in a serial fashion.
7. Close the file for operation.
After a connection to the server is established, client systems tend to leave the connection open for some amount of time, even when there are no open files by the client. This has an impact on CIFS optimization, because RiOS can optimize CIFS connections only when it detects the beginning of the CIFS connection. This is due to the negotiation of SMB options and SMB dialect that allow RiOS to understand what client and server operating systems are in use, which revision of the CIFS protocol is in use, and other options relevant to optimizing the connection.
The following table shows CIFS protocol commands that traverse the network during a session set up and subsequent simple file read.
Client Command
Server Response
Must be the first message sent by a client to the server. Includes a list of SMB dialects supported by the client. Server response indicates which SMB dialect should be used.
Transmits the user authentication information. Successful server response has the user ID (UID) field set in the SMB header and is used for subsequent SMBs on behalf of this user.
Transmits the name of the disk share the client wants to access. Successful server response has a Tree Connect ID (TID) field set in the SMB header that is used for subsequent SMBs referring to this resource.
Transmits the name of the file, that relative to the TID, the client wants to open. Successful server response includes a file ID (FID) that the client supplies for subsequent operations on this file.
Client supplies TID, FID, file offset, and number of bytes to read. Successful server response includes the requested file data.
Client closes the file represented by TID and FID. Server responds with success code.
Client disconnects from resource represented by TID.
Source: (Sep. 4, 2010)
This sequence represents the example protocol flow for a specific use case. Notice that SMB_COM_SESSION_SETUP_ANDX contains the user's authentication information. This is also particularly relevant when there are signed SMB sessions and Windows domains as part of the client-server environment. For details, see Windows Security Concepts.
READ_ANDX and other commands can be used (in some cases) several hundreds of times before the end of file is reached. There are many additional round trips across a WAN link that contribute to the overall performance degradation compared to the same operation across a LAN.
CIFS File Locking and Oplocks
The CIFS protocol allows for different types of file locking and concurrent access to be used by client and servers. Separately, the CIFS protocol allows servers to notify clients (when requested) when they are the only client accessing a file, or when all clients for a file are performing only reads.
Requesting an oplock is when a client opens a potentially shared file and requests to be notified by the server when it is the only client accessing the file, or when it is accessing the file with other clients that are performing only reads (and no writes). When a client is granted an oplock on a file, it can perform some types of actions on the file completely locally, without notifying the server. Oplock breaks occur when servers notify a client if additional clients request access to the file and remote operations performed at the client must be synchronized with the server before granting that access.
The following types of oplocks are available:
•  Batch - This oplock is generally used by command-line applications that repeatedly open many of the same files. The term batch is used for this type of access, which is most often experienced by batch (or script) command sets. Batch applocks allow clients to perform file opens completely, without notifying the server.
•  Exclusive - This oplock is granted to a client if the file is not already opened by another client. This means that the client has sole access to the file, so it is safe to cache changes until the file closes or when requested by the server.
•  Level 2 - This oplock is never requested by a client directly. Instead, a client that holds an exclusive oplock might be downgraded to a level 2 oplock at any time by the server, indicating that some additional client has accessed the file but has not yet performed any write operations.
Note: Do not confuse oplocks with file locks. File locks control access to files, and oplocks notify clients about the state of concurrency for a file.
Clients can request a specific type of shared-access control for a file when they open it. Examples of the types of shared access are do not share, share for read only, share for write only, or share for read/write. Clients can also apply more granular control by requesting locks on specific portions of a file, known as byte-range locks. The CIFS server tracks all of the access requests that it detects, and it grants or denies operations based on the requests from live clients. The shared access control, or shared mode access, is the most prevalent in most user applications. Typically, only database and similar applications can make use of byte range locks.
RiOS registers these concurrency controls: file locks, share access controls, and oplocks. The RiOS CIFS module tracks the state of every file opened between the client and server, and it uses this state to determine what types of optimized connections can safely be applied to file requests on the clients.
For example, when a client is granted an exclusive oplock on a file, RiOS can safely perform read-ahead and write-behind of file data because it is the only client accessing the file. Some of the CIFS features in RiOS enable more in-depth recognition of concurrency control, like the overlapping open optimization and the applock optimization feature.
Safe Reading and Writing
The concurrency controls—file locks, shared-access controls, and oplocks—ensure that clients can coordinate their reads and writes in an orderly fashion. In particular, when a client wants to read from a file, it knows that reading from a local cache is safe (for example, through oplocks), or that its reads and writes are coordinated with other clients (for example, through byte range locks).
When a client wants to write data to a file, there are two modes of writing that are supported in CIFS environments: write-through and write-back. The application using CIFS can decide which of these two modes to use every time it needs to write.
For write-through mode, the process falls into a pattern in which the client sends data to the server for writing, waits for an acknowledgment from the server, sends some more data, waits, and repeats this process, until all the data is written and acknowledged. At this point the client sends a CIFS command to close the file on the server. The acknowledgment from the server that the file is closed signals that all data is safely written to disk. The server releases any lock on the file and makes it available for read-write access to other clients. Although this might be the safest way when writing data, when sending data across the WAN, it is not the most efficient method because the round-trip time across the WAN is typically several magnitudes higher than across the LAN.
Write-back mode is a form of optimization in which the client does not need to wait until the write is acknowledged before proceeding with the next operation. Synchronization is forced by the client flushing its cache or closing the file. Microsoft Word and Excel are good examples of applications that use CIFS in a write-back mode. If for any reason there is a problem when the file is closed, the user is informed and the data is recovered using the automatic save mechanism.
In write-back mode, there are several places where data can linger on its way to the disk: the client machine can gather writes, the server file system can delay pushing to disk, and even the server's physical disk subsystem can cache writes in RAID cards or on memory in the disk itself. RiOS provides another place for this temporary buffering between client and long-term storage to occur during write-back mode.
RiOS honors the client-specified write-back or write-through mode for each write operation. In general, most clients use write-back mode, because the performance of write-through mode—even on local disks, without the added performance impact of WAN based usage—is unacceptable to end users. RiOS can deliver fast write performance over the WAN in a way that is analogous to how file servers and network attached storage (NAS) appliances deliver fast write performance.
Security Signatures
The CIFS protocol includes a feature to cryptographically sign every CIFS protocol datagram between the client and server. The file data that traverses the network is still sent in the clear, even when this option is used, so this CIFS feature does not protect against network snooping. However, it does protect against man-in-the-middle attacks.
The security signature feature is typically controlled through Windows group policy settings, with a separate client-side and server-side three-way setting that controls whether signing is used or not. This policy setting is then used during the initial CIFS session by the client and server to determine whether or not to sign their CIFS sessions. The following table shows the result when a client attempts to connect to a server—either the connection fails due to incompatible settings, or the session can sign the CIFS datagrams.
Server - Disabled
Server - Enabled
Server - Required
Client - Disabled
Not signed
Not signed
No connections
Client - Enabled
Not signed
Client - Required
No connections
Several options are available for RiOS to optimize connections that are signed:
•  Do nothing - RiOS can apply bandwidth and TCP-level optimization but does not perform CIFS latency optimized connections. This is because the client-side SteelHead needs to generate CIFS datagrams to the client as if it were the server, and the server-side SteelHead needs to generate CIFS datagrams to the server as if it were the client.
•  Enable the Optimize Connections with Security Signatures (that do not require signing) feature - This is only useful when neither the client nor the server use the required setting. When you enable this feature, RiOS alters the negotiation of signing between the client and server so that they each detect the disabled setting.
•  Join the server-side Steelhead appliance to the Windows domain, and possibly configure user delegation if necessary - Although this requires the most configuration, it maintains the end-to-end security guarantees that security signatures allow. Sessions continue to be signed between the clients and client-side SteelHead, between the SteelHeads, and between the server-side SteelHead and server. Maintaining this end-to-end status can be a requirement for some security mandates. For details, see Windows Security Concepts.
Overview of SMB Versions 2, 2.1, 3, 3.02, and 3.1.1
Since the initial release of SMB, Microsoft has continued to change and enhance the SMB protocol. These changes have usually coincided with the release of a new version of the Windows client and server operating system:
•  SMB2 was introduced with Windows Vista and Windows Server 2008.
•  SMB 2.1 was introduced in Windows 7 and Windows Server 2008 R2.
•  SMB3 was introduced with Windows 8 and Windows Server 2012.
•  SMB 3.02 was introduced with Windows 8.1 and Windows Server 2012 R2.
•  SMB 3.1.1 was introduced with Windows 10 and Windows Server 2016.
Using the appropriate version of RiOS, you can configure your environment so that full-latency and bandwidth optimizations are possible regardless of the SMB version or dialect.
Not all SMB features are relevant when considering optimizing SMB traffic with RiOS; however, consider the following features:
•  SMB2
–  Request compounding, which allows multiple SMB 2 requests to be sent as a single network request.
–  Larger reads and writes.
–  Caching of folder and file properties.
–  Improved message signing (HMAC SHA-256 replaces MD5 as hashing algorithm).
•  SMB 2.1
–  Client oplock leasing model.
–  Large MTU support.
–  Support for previous versions of SMB (allowing Windows 7 clients and Server 2008 R2 servers to negotiate for backwards compatibility).
•  SMB3
–  Secure negotiation (allows the client and server to detect a man-in-the-middle that modifies the negotiation process).
–  Directory leases (allows the client to safely cache directory contents).
–  Encrypted traffic (encryption of the SMB3 traffic on a per-server or per-share basis).
•  SMB 3.02
–  Some additional capabilities (for example, Instancing and read and write flags). These capabilities are not relevant for WAN optimization on their own, but because they are in the client-server session setup dialog, the SteelHead needs to understand the dialect to respond correctly.
•  SMB 3.1.1
–  Preauthentication integrity (improved protection from man-in-the-middle attacks tampering with SMB connection establishment and authentication).
–  Per connection crypto algorithm negotiation (options for AES-128-CCM and AES-128-GCM).
For more information about SMB3, see SMB3 Optimization with Windows 8, Windows 2012 Server, and Later Operating Systems.
More Information
Although the low-level detail of the CIFS protocol is beyond the scope of this document, there are many public reference materials available. For a starting point, go to
RiOS CIFS Optimization Techniques
The CIFS optimization module comprises many separate techniques. Many of these techniques are enabled by default, so when configuring a new SteelHead (or creating a new SteelCentral Controller for SteelHead Mobile package), minimal, if any, CIFS-specific configuration is required.
Note: Typically, new features in RiOS, even ones that are widely applicable, are not enabled by default until they have been present for several releases. Some optimization features that are not enabled by default can provide benefit in your environment, and you can consider enabling them on an individual basis.
Modern CIFS servers generally listen on TCP port 445; for compatibility, they also listen to port 139. The CIFS optimization module within RiOS is designed to intercept traffic on these two ports for acceleration of file-sharing and remote Windows printing traffic.
After a CIFS connection is intercepted for optimization, the RiOS CIFS optimization module monitors the negotiation and session setup commands to detect which client and servers are in use and what types of CIFS options are understood by each. As clients initiate requests to the server, RiOS applies its optimization techniques to reduce the time that the client awaits a response from the server.
For specific information about CIFS optimization features, see the SteelHead Management Console User’s Guide.