SteelHead™ Deployment Guide - Protocols : CIFS Optimization : Overview of CIFS Protocol
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:
Parse the full filename to determine the server name.
Establish a TCP connection to the server.
Negotiate what type of SMB dialect and option is used with the server.
Transfer credentials and authenticate access to the server.
Open the file for operations by sending the filename and desired access to the server.
Perform read, write, or other operations on the file, typically in a serial fashion.
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.
  • 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 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 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 so on, 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, and 3.02
    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
  • SMB2.1 was introduced in Windows 7 and Windows Server 2008 R2
  • SMB3 was introduced with Windows 8 and Windows Server 2012
  • SMB3.02 was introduced with Windows 8.1 and Windows Server 2012 R2
  • 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.
    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)
  • SMB2.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)
  • SMB3.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.
  • For more information about SMB3, see SMB3 Optimization with Windows 8 Clients and Windows 2012 Server.
    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