如果知道NAS (Network Attached Storage)的朋友应该都听过NFS或者SMB (CIFS)协议？简单的说这个两种协议都是为了支持文件的网络共享而生的， 一个服务器上创建好一个共享文件夹，随后多个不同的客户端主机就可以通过网络对这个文件夹读写实现文件共享或者存储。
NFS和SMB协议都实现了客户端缓存机制来提高读写性能，不同的是NFS之缓存字节锁，而SMB除了可以缓存元数据外，也能缓存数据。NFS的缓存机制被称为代理 (Delegation), 而SMB的缓存被称为机会锁和租约 (Oplock, Lease)
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_OPLOCK_LEVEL_LEASE (0xFF)
租约(Leasing)，一种在SMB2.1引入的全新客户端缓存机制，能够完全取代Oplock所以之前的功能，成为目前在SMB协议中默认
且主流的一直缓存机制（Windows7以后的客户端默认模式）
从SMB2.1开始(Windows7， Windows2008R2)，一种新的客户端缓存机制"租约(Leasing)"被引入进来, 进一步的提高了读写性能和减少了网络包的数量。由于其功能和机制类似于OpLock，所
以租约在很多场合大家约定俗成仍然成为OpLock, 准确的说: OpLock在SMB2.02以前就是OpLock, 在SMB2.1及以后的版本OpLock其实就是指的Lease. 当前多数环境下所使用的机制。
租约(Lease)类型Oplock请求
从上图网络包可以看出，客户端对于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 场景
租约所带来的客户端缓存从而提供读写性能的场景仅限于在客户端应用对于文件独占是访问的前提下，那么在多个不同客户端同时访问同一个文件的场景下，租约是如何运作的呢？我们分几种场景分别看看
- 客户端A只读方式打开SMB共享目录下的文件demo.txt
-
客户端B以只读方式打SMB共享目录下的文件demo.txt
两个不同的客户端对同一个文件进行只读操作。便于精确地请求只读类型，我们以代码的方式来替代手动的文件打开，在两个不同的windows2012客户端分别运行以下代码，同时在服务器端抓包
只读打开文件获取租约Lease
通过对服务器端的抓包解析
$ 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客户端协议还是会以最高级别的租约请求目标文件:
客户端A拿到的Lease
随后客户端B也已只读方式打开同一个文件，可以看到它也是请求的最高级别的租约:
客户端B拿到的Lease
此时，由于多个客户端打开统一文件，客户端A所拿到的最好权限的租约(RWH)需要更新成只读(RH)，随后B才能成功打开目标文件
image.png
对照上图分析一下其过程
- Frame #88: 客户端B请求只读方式打开目标文件testfile.txt
- Frame #90: 服务器回复延缓客户端B的Open请求，原因是检测到了租约冲突
-
Frame #91: 服务器通知客户端A需要召回之前已发放的租约(lease)
Frame #91
-
Frame #92: 客户端A按照要求发起了召回租约请求
Frame #92
-
Frame #93: 服务器确认之前租约已经回收并且发放更新后的新租约(只读)
Frame #93
-
Frame #94: 最后服务器授予客户端B租约(只读)
Frame #94
- Frame #97: 客户端B读取文件内容
Lease关闭场景
如果服务器关闭了Oplock的话，那么客户端将不能够再缓存任何数据了，甚至连文件句柄也缓存不了，那么理论上读写性能会有显著的下降, 对应的网络包下图:
Create在Oplock关闭情况下的回应
网友评论