深入NAS协议系列: 召唤SMB2 OpLock/Lease

这是从事存储行业十年以来我写的第一篇博客，希望借此开始把自己这些年所积累的一些干货借这个平台做分享。

虽然NAS协议众多，但核心的就那个几个：NFS，SMB/CIFS, FTP/SFTP, 其中SMB以及NFS可谓重中之重，相互竞争，相互借鉴，你追我赶，使得网络文件系统世界精彩纷呈。 因此，我的系列博客就从SMB协议开始，为大家呈现一个深入(Deep Dive)系列，让这些让很多人望而却步的协议不再神秘。

这个系列可能对入门的读者不太友好，因为我不想把这个系列仅仅做成'另一个入门教程', 而是要让有志于深入掌握网络存储的朋友有所收获，并且能在实际工作中得到实际的帮助。所以稳重所出现的抓包，解包，I/O 工具的具体操作都不会有特别详细的步骤，都是建立在读者有一定网络基础和相关经验的基础上的。

系列的每一篇内容有较强的的独立性，可以看做对某个协议单独一个功能特性的研究，但并不排除其中有对其它功能特性的依赖，对此我尽量穿插一些注解以求最大程度平滑过渡。

内容安排的先后顺序可能比较随意，并未有循序渐进的特点，如果有机会可能会根据知识内容的难度做一次整理，这次的主题是Oppturnistic Lock, 简称Oplock, SMB协议中Oplock和Leasec概念之间的相互缠绕以及功能的类似性让人非常迷惑，这篇随笔的目的就是通过实际的抓包分析来解惑。

Oplock/Lease 目的

先说说Oplock的好处，简单一句话：利用客户端的缓存机制的来提高SMB协议的I/O性能，其实基本思想其实就是客户端缓存(client cache)，操作方式近似于NFS4之后引入的代理模式(delegation), 有别于Delegation的是，Oplock不但缓存字节锁(Record Lock)而且可以缓存数据部分。这使得客户端在对于某个文件在独占模式下的I/O性能可以与操作本地文件操作媲美。

Oplock 与 Lease 区别

首先要强调一点OpLock与Lease的不同，最简单的理解方式，OpLock是在SMB2.02以前所实现的客户端缓存机制(Client Cache), 而Lease是从SMB2.1开始的客户端缓存的实现方式，注意，两者在同一版本的SMB协议中并不共存！换句话说，如果服务器协商好双方所支持的最高Dialect以后，只能使用其中一种(either OpLock or Lease)。但是，由于惯例，Lease在SMB2.1以后的版本中仍然被称作为OpLock， 只是此OpLock非彼OpLock.

在功能上，Lease的在OpLock的基础上，进一步提高了SMB2的性能，主要体现在对于文件句(File Handle)柄缓存的支持, 借此减少大量的网络包来回。SMB2.02及以前的Oplock并不支持文件句柄的缓存，所以即便是同一个客户端的不同应用对相同文件的操作也会触发客户端与服务器对于目标句柄操作的网络包，在Lease里，文件句柄背缓存后，这些职责就被移交到(offlaod)客户端自己处理，无需服务器参与，从而在网络不佳的环境里极大的提高了性能。

Oplock/Lease的类型

OpLock在SMB1的时候只有四种类型:

SMB2_OPLOCK_LEVEL_NONE 0x00	无锁，不会触发客户端的缓存机制
SMB2_OPLOCK_LEVEL_II 0x01	读锁，在只读模式下会预读(read-ahead)数据缓存至客户端
SMB2_OPLOCK_LEVEL_EXCLUSIVE 0x08	独占锁，也就是读/写锁，读时可以预读数据到客户端，写时可以将数据以回写方式(write-back)先写道客户端缓存. 性能最好
SMB2_OPLOCK_LEVEL_BATCH 0x09	Batch 锁，一种针对于office类型文件的优化锁，针对于同一文件的多次打开和关闭而设计一种性能优机制

从SMB2.1开始(Windows7，Windows2008R2)，一种新的客户端缓存机制"租约(Leasing)"被引入进来, 进一步的提高了读写性能和减少了网络包的数量。由于其功能和机制类似于OpLock，所以租约在很多场合大家约定俗成仍然成为OpLock, 准确的说: OpLock在SMB2.02以前就是OpLock, 在SMB2.1及以后的版本OpLock其实就是指的Lease.

SMB2_OPLOCK_LEVEL_LEASE 0xFF

租约(Leasing)，一种在SMB2.1引入的全新客户端缓存机制，能够完全取代Oplock所以之前的功能，成为目前在SMB协议中默认且主流的一直缓存机制（Windows7以后的客户端默认模式）

[此网络包出于SMB2.11(SMB3)当中]

 

从上网络包可以看出，客户端对于Oplock的请求类型会被规定在对于目标文件的Open请求中(通过Create Request实现)， 一般情况下这样的请求如果在Windows7和之后版本的客户端发出的话，它的值只可能是两种，Lease 或者 No Oplock （除非在客户端手动关闭Lease，这个之后再详细讲)，那么在取代了Oplock之后，Lease如何规定具体的锁类型呢(租约类型)呢？不急，再往下看，在同一个Create Request请求的ExtraInfo部分，我们就能找到答案, ExtraInfo详细描述了Lease的请求信息:

从上图的Lease State可以看到，Lease的具体类型可以分为三种，Read Caching, Write Caching以及Handle Caching。三种类型可以同时启用或者禁用。

Read Caching	等同于OpLock的 SMB2_OPLOCK_LEVEL_II 锁
Write Caching	等同于OpLock的 SMB2_OPLOCK_LEVEL_EXCLUSIVE锁
Handle Caching	这个是Lease独有的文件句柄缓存功能，有了它在同一个客户端的不同应用程序在打开同一个文件时，可以直接在客户端进行管理，无需server端参与从而极大的减少了网络包的数量。

Lease 的工作原理

租约其实就是客户端缓存策略(Client Cache)的一种具体方式。

以Read Caching举例分析，看下图，当应用程序在第一次读取服务器端的数据后会将数据保留在客户端的缓存当中，以便于应用随后对于此数据的再次使用。并且，考虑到顺序局部性(Locality)，被缓存的数据通常是多个页的大小而并非仅仅是应用所请求的那一部分。借此以提高应用程序的后续请求的读性能(建立在顺序局部性的基础之上), 通常我们称这种行为为预读(read-ahead)。

[此图来自网络，侵删]

再来看看Write Caching, 和传统操作系统的内存管理策略近似，以回写(write back)的方式现将数据写到缓存当中，再在适当的时机(Close Request等)将脏数据(dirty page)刷会服务器端。从而显著提高写性能。

 

Lease 场景1

租约所带来的客户端缓存从而提供读写性能的场景仅限于在客户端应用对于文件独占是访问的前提下，那么在多个不同客户端同时访问同一个文件的场景下，租约是如何运作的呢？我们分几种场景分别看看

两个不同的客户端对同一个文件进行只读操作。

• 客户端A只读方式打开SMB共享目录下的文件demo.txt
• 客户端B以只读方式打SMB共享目录下的文件demo.txt

便于精确地请求只读类型，我们以代码的方式来替代手动的文件打开，在两个不同的windows2012客户端分别运行以下代码，同时在服务器端抓包。

[Python使用os模块使用系统调用的方式打开文件]

通过对服务器端的抓包解析 (网络包见附件）

(抓包) tcpdump -i eth2 -s 1024 -w /tmp/ro_open_server.cap

(解包) tcpdump -t ud -O smb2 -Y "ip.addr==<server_ip>" -r /tmp/ro_open_server.cap

通过对服务器端的SMB2包的分析，可以看到客户端A几遍以只读的方式打开文件(O_RDONLY), SMB2客户端协议还是会以最高级别的租约请求目标文件:

 

随后客户端B也已只读方式打开同一个文件，可以看到它也是请求的最高级别的租约：

此时，由于多个客户端打开统一文件，客户端A所拿到的最好权限的租约(RWH)需要更新成只读(RH)，随后B才能成功打开目标文件:

网络包分析:

88 客户端B向服务器请求最好级别的租约(lease) RWH

90 服务器让客户端B等一等(STATU_PENDING)，因为检测到了租约冲突(同一个文件不能被不同客户端同时以RW的方式打开）

91 服务器通过Break Response的非主动请求(unsolicited request) 告知客户端A因为冲突原因需要回收租约

92 客户端A得到通知后变主动通过Break Request撤销(更新)租约

93 服务器确认客户端A之前的租约撤销并发放新的只读租约(RH)

 

94 最终，在服务器解决了租约冲突以后, 客户端B也如愿拿到了只读租约(RH).

下一篇文章我们将探索Oplock在NFS4当中的

对手(counterpart), 代理(Delegation)， 来看看NFS在应对SMB在性能提升方面的回应。

附件, tcpdump 文件：