CIFS协议详解.docx
《CIFS协议详解.docx》由会员分享，可在线阅读，更多相关《CIFS协议详解.docx（16页珍藏版）》请在冰豆网上搜索。
CIFS协议详解
CIFS的概述
什么是CIFS？
通用Internet文件系统（CIFS），也称为服务器消息块（SMB），是一种网络协议，其最常见的用途是共享局域网（LAN）的文件。
该协议允许客户端对文件进行操作，就好像他们在本地计算机上。
如读，写，创建，删除，重命名操作都支持，唯一的区别是，该文件不是在本地计算机上，实际上是在远程服务器上。
CIFS协议的工作方式从客户端向服务器发送的数据包。
每个数据包通常是某种，如打开文件、关闭文件或读取的文件的基本要求。
然后，服务器接收数据包，如果请求的是法律，验证客户端具有适当的文件的权限，最后执行请求，并返回到客户端的响应数据包检查。
客户端然后分析响应数据包，并可以确定初始请求成功。
CIFS是相当高级的网络协议。
在OSI模型中，最可能描述在应用/表示层。
这意味着CIFS依赖于其他运输的协议。
可靠的运输所使用的最常见的协议是NetBIOS通过TCP（NBT），其将在下面的NetBIOS章描述。
其他协议已用于传输层，但是随着互联网的巨大的普及，NBT已成为事实标准。
虽然CIFS的主要目的是，文件共享，但有CIFS通常与其相关联的其他功能。
大多数CIFS实现也能够确定的其他CIFS服务器上网络（浏览）、印刷和更复杂的身份验证技术。
没有这些主题将讨论本文档中但是，只有基本的CIFS文件操作。
CIFS在哪里？
CIFS协议最常用与微软的操作系统。
Windows的工作组是要使用CIFS，第一次微软操作系统和每个微软操作系统自那时已经能够CIFS服务器和客户端的功能。
Microsoft操作系统使用CIFS的远程文件操作（通常映射的网络驱动器），浏览（通过网上邻居图标）、（NT和Windows2000）、身份验证和远程打印机服务。
它会公平地说，本机Microsoft网络的核心围绕其CIFS服务。
CIFS协议是因为微软的大型企业和家庭用户群，发现几乎到处都。
口味的Unix操作系统还实现CIFS客户端/服务器通过Samba程序。
苹果计算机也有CIFS客户端和服务器可用，这可能会使CIFS的最常见的文件共享协议可用。
CIFS历史记录：
1984年，IBM写了允许上小的子网的主机之间的基本网络通信应用编程接口（API）。
API，但是，所需实际发送和接收数据的传输层协议。
第二年，IBM发布能让来生活的NetBIOSAPI的传输层协议。
API和传输协议被合并成一个实体，并称为NetBIOS增强的用户界面或NetBEUI。
当时，其他传输协议是共同使用，和NetBIOSAPI很快，实施使用DECnet、IPX/SPX和TCP/IP等各种其他的传输协议。
API变得相当流行。
不久之后，微软和英特尔创建的第一个节目的SMB/CIFS文件共享协议，标题为"核心协议"。
微软和英特尔选择了使用上述的NetBIOSAPI的上层CIFS数据包传递。
因此，通过TCP使用NetBIOSCIFS成为标准的网络文件共享Microsoft操作系统的机制。
许多功能添加了初始的核心协议，随着时间的推移。
目前，大多数Windows客户端支持至少6的不同变体CIFS协议中，每个版本，通常包含一些更多的功能，比上一次。
到目前为止，至少100不同CIFS操作，列表中不断增长。
小幅鲁棒特征集包括：
∙文件访问
∙文件和记录锁定
∙安全文件缓存
∙文件更改通知
∙协议协商
∙扩展的文件属性处理
∙批的请求
∙Unicode支持
CIFS协议，但是，绝对显示年龄的迹象。
几次在最后13年，已扩展议定书》的功能集和造成的影响越来越明显。
有多个完成相同的任务的CIFS数据包和CIFS数据包的许多有记录的选项。
互联网工程任务组（IETF）和存储网络产业协会（SNIA）努力纠正这种困境。
它们正在朝着创建CIFS1.0规范，其中列出了只需要在未来的支持的当前CIFS操作的子集。
规范还试图定义更清楚各包选项。
有很多工作来做，但这绝对是一个好的开始。
NetBIOS：
本节将重点常用的上层CIFS服务的NetBIOS职能。
如上文所述，NetBIOS运行在许多级别的传输协议，但对于现代天实现，TCP/IP协议套件是目前为止最普遍使用的传输协议。
在1987年RFC1001和RFC1002中记录的技术和NetBIOS对运行的TCP/UDP（akaNBT）的概念。
这两个文件都非常完整；RFC1001涵盖概念和方法，而RFC1002包括详细的规格。
在这些文档中所述三个主要服务：
名称服务、会议服务和数据报服务。
每个这些服务和典型CIFS实现的关系将在下文讨论。
包括在这一节的最后是潜在未来NetBIOS变化的简短说明。
服务名称：
NetBIOS名称是人类可读的名称分配给网络上的计算机。
这些名称最常见的Windows操作系统在网上邻居中。
NetBIOS命名同样的目的为DNS系统在TCP/IP的世界；它允许调用的计算机的名称，人类和系统的可读名称映射到传输地址，如IP。
不过，非常不同的NetBIOS名称注册的IP和解析名称到IP的方法。
更好地理解的NetBIOS名称操作运作这一节首先涵盖主要性能的NetBIOS命名约定，，然后介绍常见NetBIOS命名程序的简要概述了。
NetBIOS命名属性：
广播和/或基于服务器。
NetBIOS名称注册和查找可以全部完成通过广播和局部区域网络或通过使用中央NetBIOS名称服务器（NBNS或WINS[1]）。
通常，通过DNS，可以使用只有一个集中的名称服务器。
是"和/或"的选项，必须由管理员使用任一配置所有的NetBIOS计算机在网络上：
∙广播唯一（b节点）
∙只有NBNS（p节点）
∙广播第一次和NBNS仅当没有响应广播（m节点）
∙NBNS，然后广播如果服务器没有响应（h节点）
由于这些选项，有两个，每个命名的活动，其中一个描述的广播的方法，其他描述的服务器的方法的说明。
动态注册。
DNS和NetBIOS命名也不同如何创建可读的名称和IP地址之间的关联。
与DNS，管理员通常有一次，添加到服务器的DNS条目和DNS名称和IP静态永远举行。
与NetBIOS，当计算机启动时，它在注册其名称/ip组合动态。
NetBIOS计算机也可以取消注册其名称每当它不再需要该名称。
名称语法。
NetBIOS名称必须符合一组严格的规则。
下面的列表描述了主要的属性的名称必须遵守。
1.注册的NetBIOS名称可以引用（唯一名称），或者单个的工作站或可以参考的工作组（组名称）的所有一部分的多个节点。
2.NetBIOS名称存在没有分层格式平面名称空间中。
这意味着有没有"点"（即。
'字符）的NetBIOS名称，作为在DNS名称[2]。
因为这个平面名称空间的任何唯一的名称（如上所述）只能注册在一台计算机。
3.NetBIOS名称必须只包含以下范围的字符、a-z、A-Z、0-9或以下字符之一！
@#$%^&（）-'{}.~
4.NetBIOS名称来描述该资源，使用最多15个字符，16届字节指的资源类型。
资源类型字节指示注册计算机有哪些属性[3].
NetBIOS常见过程概述：
两个最常见NetBIOS名称服务网络上的计算机程序名称注册和名称查询。
虽然名称查询确定与给定的名称关联的IP地址名称注册将IP，与相关联的NetBIOS名称。
下文为b节点和p节点列出这两个过程。
M节点和h节点，将会在一起，有时会尝试使用广播的方法第一，和有时会首先尝试使用NBNS方法合并这些程序。
名称登记（b节点）：
工作站希望登记的名称生成一个NetBIOS名称注册数据包（在RFC1002中定义），然后广播数据包通过UDP协议端口137上的子网。
此数据包中包含工作站欲注册的名称和该工作站的IP地址。
工作站然后重复此过程三次，等待250毫秒之间广播节目。
在此期间，工作站等着看是否任何其它工作站将发送回一个防御数据包。
从已注册此名称为其自己的任何其他工作站将发送此数据包（防御不应将发送一个组名称上如是合法的注册相同的组名称的多个工作站）。
如果收到没有防御反应，则工作站已成功注册名称。
名称登记（p节点）：
P节点还生成一个NetBIOS名称注册数据包（在RFC1002中定义），而是直接向通过UDP协议端口137NBNS服务器数据包单播数。
NBNS然后搜索它的内部名称的数据库，检查其他已注册了相同的唯一名称的工作站。
如果已注册名称，NBNS发送回负名称注册响应[4]。
如果没有工作站已注册名称，服务器将发送肯定名称注册响应和工作站已成功注册名称。
名称查询（b节点）：
欲获取IP地址的NetBIOS名称从工作站首先生成名称查询请求（在RFC1002中定义），然后广播数据包通过UDP协议端口137上的子网。
请求数据包包含工作站欲查询的NetBIOS名称。
工作站然后重复此过程3倍，等待5秒之间每个重新传输。
在此期间，工作站或者接收积极名称查询响应的计算机的名称，拥有来自或接收到什么。
如果接收到积极名称查询响应时，包将包含查询的NetBIOS名称的IP地址。
名称查询（p节点）：
P节点查询还生成名称的查询请求，但再次单播数直接向通过UDP协议端口137NBNS服务器数据包。
NBNS然后搜索匹配的NetBIOS名称为其内部数据库。
如果找到匹配项，NBNS将发送回请求的IP地址与工作站积极名称查询响应。
如果找不到匹配，NBNS将发送回工作站负名称查询响应。
会议服务：
RFC1001各国，"会话是可靠的消息交换，一对NetBIOS应用程序之间进行。
会话在全双工、顺序，以及可靠。
"会话服务的NetBIOS是哪个网络的计算机交换消息的泛型方法。
这些消息可以是任何类型；会话服务只关注到可靠地按顺序的两个点之间传输消息。
RFC1001去说TCP端口139上的应该用于模拟会议服务功能。
TCP与少数的例外情况极为类似的会议服务。
主要区别是TCP是面向流和不保留消息边界。
这是相对于这一次在网络上发送一条消息，并预期一次从网络读取一条消息的会话服务。
但是，解决这个问题很简单：
每个会话服务数据包只是封装与指示邮件的大小前小头发送。
CIFS使用会话服务发送和接收上层的所有命令，包括文件和打印机的所有操作。
因此，在任何CIFS网络通信中的第一步通常是建立在客户端和服务器之间的NetBIOS会话。
会话服务是由小组定义的网络基元的介绍如下。
描述还包括原始映射到TCP/IP的方式。
∙电话：
启动的NetBIOS会话。
这被映射到TCP，启动和创建全双工的TCP连接，然后发送NetBIOS调用的数据包。
呼叫数据包中包含客户端的NetBIOS名称和服务器的NetBIOS名称。
∙听：
等待NetBIOS调用命令。
这被映射到TCP作为服务器等待端口139传入的请求会话（TCP启动，随后通过接收呼叫数据包上文所述）。
∙挂断：
结束NetBIOS会话。
这是由只需启动正常的TCP拆卸序列映射到TCP。
∙发送：
通过NetBIOS会话发送一条消息。
这是由封装与小头包含邮件大小的数据，然后通过TCP流发送数据映射到TCP。
∙接收：
从NetBIOS会话接收消息。
这被映射到TCP作为接收从TCP流，直到到了整个邮件（由上面提到的小头的大小）。
∙会话状态：
从RFC1001"获取有关请求者的会话，根据指定的名称的所有信息"。
这不是由作者是意识到任何CIFS实现使用。
会话服务将很容易地映射到TCP，并因此，描述和实施不是过于复杂。
CIFS的每个数据包封装与指示邮件大小的4字节会话标题中，虽然是很容易忘记以本机CIFS是不只是通过TCP模式运行。
数据报服务：
RFC1001各国，"数据报服务是不可靠的、非顺序的、无连接的服务"。
数据报服务由NetBIOS应用程序用作快速、广播能力、低开销的方法来传输数据。
正如RFC说明指出，不过，数据报传递是不可靠的也可以到达顺序。
RFC继续状态端口138上的UDP协议应被用于实现tcp/ip协议内的NetBIOS数据报服务。
UDP是非常相似的NetBIOS数据报服务，但仍必须稍微修改要效仿的所有的数据报服务功能。
是通过UDP发送的所有的NetBIOS数据报包有头前暂停处理它们。
此标头包含两个重要信息:
NetBIOS名称的数据包发件人和NetBIOS数据报是否零碎，无法通过UDP发送。
使用此信息，可以完全模拟NetBIOS数据报服务，通过UDP协议。
CIFS实现通常使用NetBIOS数据报服务，进行浏览。
浏览是发现（Windows然后在网上邻居中显示此列表）在网络上的CIFS服务器的NetBIOS名称的过程。
浏览不属于标准的CIFS协议，不过。
虽然大多数CIFS实现还实现浏览，它们是单独的实体。
因此，纯的CIFS实现将不需要执行的NetBIOS数据报服务，只对会话和上文所述的名称服务。
未来的变化：
许多供应商目前正期待完全淘汰NetBIOS和只需运行CIFS直接通过TCP和UDP。
CIFS1.0的草案规范明确指出CIFS不取决于任何特定的传输协议和有简短的附录，它指示如何通过TCPCIFS将运行以本机方式。
NetBIOS仍然存在主要用于向后兼容性。
如果删除了NetBIOS，所做的更改不会十分激烈。
DNS和域的名称将替换NetBIOS命名服务。
会议服务所需的所有数据包会都运行直接通过TCP，并会有没有NetBIOS前暂停处理标头。
所需的数据报服务的所有数据包会都运行直接通过UDP，并再次，pre暂停处理标头将成为不必要。
如果这些变化，实际上将由供应商是未知的。
微软似乎很感兴趣提供无NetBIOSCIFS。
如果微软最终不会释放操作系统使用CIFSNetBIOS脱钩，其他供应商可能还使交换机。
CIFS塔内件
简而言之，通用的网络文件系统（CIFS）是允许文件共享网络节点之间的网络协议。
客户端发送到服务器的请求数据包，并响应数据包与客户端的服务器响应的客户端服务器设计基于议定书》。
每个发送的数据包中包含标准的头，再加上两个可变长度字段使用的包的特定信息。
每个数据包还包含命令字段，指示该数据包试图完成的一般用途。
常用命令字段指示包的目的，是要登录、打开文件、从文件中读取或写入文件。
要获得更深入的了解，议定书》上CIFS下面,有三个详细的部分。
第一节涵盖主要协议属性。
第二节介绍CIFS标准数据包报头通过关系图创建的各个字段和定义它们的目的。
最后一节有两个典型的数据包序列演练：
登录到服务器并打开/读取的文件。
协议属性：
客户端/服务器+请求/响应：
如上文所述，CIFS体系结构基于客户端发送请求，并答复每个请求的服务器发送[5]。
该协议是能有多个优秀的同时请求。
这被完成通过多重的id（MID）的使用。
客户端确保了每个请求发送到服务器具有独特的MID。
当在服务器响应给定请求时，该响应包含相同的MID。
这种方式，多个请求可以发送到服务器，以及客户端可以简单地匹配与它生成的知道哪些请求只是已回复的MID中期响应。
基于命令：
CIFS的每个数据包包含1字节命令中的一个字段。
目前100++命令，每个数据包的核心功能是围绕指定的命令。
对客户端响应总是有相同的命令代码，作为该请求。
可在CIFS1.0草案规范内的常见命令代码列表。
协议方言/谈判：
自成立以来，在八十年代有很多版本的CIFS协议。
每个协议版本称为方言和分配一个唯一的字符串以标识如"PC网络程序1.0"或"NTLM0.12"方言。
当客户端想要访问远程服务器上的文件时，发送的第一个CIFS数据包是协商协议数据包。
此CIFS的数据包，在客户端列出的所有方言字符串它有能力的认识。
在响应数据包中，服务器指示它希望进行交流，或指示服务器理解没有方言的方言。
这种方法，客户端和服务器可以协商哪些特定CIFS会话使用的方言。
/共享用户级安全性：
一个共享是一个服务器实体（通常是一个文件的文件夹或打印机）被标记为可用，以CIFS客户端的网络共享。
限制的访问共享是带来两种方式之一：
1.用户级安全性：
指示欲访问共享的客户端必须提供用户名和密码进行访问。
这提供了服务器管理员细粒对谁有权访问该共享的控制。
在WindowsNT和Windows2000中使用这种类型的安全。
2.共享级安全性：
指示共享本身需要密码才能访问，但没有用户名是必需的建立了没有用户标识。
例如，X的密码无法分配到一定的份额。
任何用户知道密码X然后可以访问的共享。
没有细致的控制，因为没有概念的单个用户和他们的权利。
在Windows95和98使用这种类型的安全。
加密：
上面的两个安全方法之一，实际密码发送到服务器[6]以加密格式。
有两种常用的加密方法：
较新的NT风格与较旧的LAN管理器样式。
这两种加密方法使用质询响应身份验证，服务器向客户端发送一个随机字符串，并预计证明客户知道随机字符串和用户密码的响应。
命令配料：
许多CIFS数据包都能借用其他CIFS数据包，以减少响应延迟和更好地利用网络带宽。
这种技术被称为效率与中国配料。
机会锁定：
当CIFS包指定打开的文件时，可以请求机会锁定操作（锁定）。
如果授予服务器，操作锁定指示客户端没有其他实体正在访问该文件。
这允许客户端对它想要的文件并不一定非要把它们写在作任何修改都立即向服务器。
有多种类型的机会锁定和他们有细微的差别。
请参见CIFS1.0草案规范的详细信息。
数据包报头：
每一个CIFS请求和响应作为模板使用下面的数据包报头。
模板后介绍了各个领域。
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
0xFF
'
我'
'B'
命令
错误类
必须为零
错误代码
错误代码（续）
标志
Flags2
垫或安全签名——通常垫，因此必须为零
树ID（工贸署）
进程ID（PID）
用户ID（UID）
多重ID（中）
字数统计
由字数统计变量指定ParameterWords[字数统计]——的可变大小本节中的单词数。
ByteCount
由ByteCount变量指定缓冲区[ByteCount]——在本条中可变大小的字节数。
标头：
CIFS的每个数据包的开头包含4个字节的标头。
第一个字节为0xFF，紧接着的字母的ASCII表示'，是'，和'B'。
命令：
命令字段包含一个字节代码指示CIFS数据包类型。
从该字段的CIFS1.0草案的例子是SMB_COM_READ_ANDX[7]（0x2E）、SMB_COM_TREE_CONNECT（0x70）和SMB_COM_NEGOTIATE（0x72）。
错误类：
服务器指示给定的请求非常成功，错误类的字段。
通常情况下，该字段是零，表示成功。
如果非零，该字段指示的错误代码是从哪个班。
错误类字段设置时，采用下列值之一：
∙ERRDOS（0x01）——错误是从核心DOS操作系统设置
∙ERRSRV（0x02）——由服务器的网络文件管理器生成错误
∙ERRHRD（0x03）——硬件错误
∙ERRCMD（0xFF）——命令不是"SMB"格式
错误代码：
这16位字段指示已发生的错误的类型。
它通常设置为零，指示没有错误。
如果设置，此数字与上面的错误类结合可以提供完整的错误说明，如"密码错误"或"文件不存在"CIFS1.0草案中抬头。
正如与错误类，此字段设置只能由上一个请求的响应中的服务器。
标志：
大多数的标志字段中的8位指定特定的选项。
注意在此字段中的唯一一个颇有点3。
3位设置为'1'，此特定的数据包中的所有路径名必须须都被当作为无壳。
3位设置为'0'，当所有的路径名是区分大小写的。
Flags2:
这16位字段指定更多的选项。
有用的位：
∙位0，如果设置，指示服务器可能会返回长文件名，在响应中。
∙位6，如果设置，指示任何请求中的路径名是长文件名。
∙如果位16，设置，指示该数据包中的字符串以UNICODE编码。
垫/安全签名：
此字段通常设置为零。
树ID（工贸署）：
工贸署是一个16位的数字标识的资源（磁盘共享或打印机，通常）所指的这个特定的CIFS数据包。
当数据包进行交换，的确没有任何与资源时，此数字将是毫无意义和被忽略。
如果客户希望获得对资源的访问权限，客户端将发送CIFS数据包与命令字段设置为SMB_COM_TREE_CONNECT_ANDX。
在此数据包，指定的共享或打印机名称（即//SERVER/DIR）。
然后，服务器将验证存在相应的资源，并在客户端具有访问权限，然后返回表示成功的响应。
在此响应数据包，服务器将设置工贸署随意的任何数字。
从此以后，如果客户机希望提出请求特定的资源，它将设置工贸署数它时获得。
进程ID（PID）：
PID是一个16位的数字标识哪个进程发出CIFS请求客户端上。
服务器使用此号码进行检查并发问题（通常以保证的文件将不损坏的竞争客户端进程）。
用户ID（UID）：
UID是16位的数字，发出CIFS请求客户端的用户标识。
通过发送包含用户名和密码的CIFS会话设置请求，客户端必须从服务器获取UID。
后验证用户名/密码，服务器响应设置的会话，并包括生成的UID。
客户端然后所有未来CIFS请求中使用已分配的UID。
如果这些客户端请求的任何要求被检查的文件/打印机权限，服务器将验证请求中的UID已执行的操作所需的权限。
UID的有效期仅为给定的NetBIOS会话。
其他会话可能使用相同的UID具有不同的用户相关联的服务器。
注意：
如果服务器运行在共享级安全模式（见上文），UID是毫无意义和被忽略。
多重ID（中）：
MID是一个16位值，用来让多个优秀的客户端请求存在不会产生混淆。
每当客户端发送一个CIFS数据包，它检查是否有任何其他悬而未决的请求挂起。
如果是这样，它确保新的请求会有不同的MID然后以前未完成的请求。
每当服务器答复CIFS请求，它确保它将发送的响应与中期，它收到请求相匹配。
在执行此过程，客户端可以总是知道究竟哪些优秀的请求传入的答复相关的。
升级会员 