CIFS协议详解.docx

1、CIFS协议详解CIFS的概述什么是CIFS？通用Internet文件系统（CIFS），也称为服务器消息块（SMB），是一种网络协议，其最常见的用途是共享局域网（LAN）的文件。该协议允许客户端对文件进行操作，就好像他们在本地计算机上。如读，写，创建，删除，重命名操作都支持，唯一的区别是，该文件不是在本地计算机上，实际上是在远程服务器上。CIFS 协议的工作方式从客户端向服务器发送的数据包。每个数据包通常是某种，如打开文件、 关闭文件或读取的文件的基本要求。然后，服务器接收数据包，如果请求的是法律，验证客户端具有适当的文件的权限，最后执行请求，并返回到客户端的响应数据包检查。客户端然后分析响应

2、数据包，并可以确定初始请求成功。CIFS 是相当高级的网络协议。在 OSI 模型中，最可能描述在应用/表示层。这意味着 CIFS 依赖于其他运输的协议。可靠的运输所使用的最常见的协议是 NetBIOS 通过 TCP (NBT)，其将在下面的 NetBIOS 章描述。其他协议已用于传输层，但是随着互联网的巨大的普及，NBT 已成为事实标准。虽然 CIFS 的主要目的是，文件共享，但有 CIFS 通常与其相关联的其他功能。大多数 CIFS 实现也能够确定的其他 CIFS 服务器上网络 （浏览）、 印刷和更复杂的身份验证技术。没有这些主题将讨论本文档中但是，只有基本的 CIFS 文件操作。CIFS

3、在哪里？CIFS 协议最常用与微软的操作系统。Windows 的工作组是要使用 CIFS，第一次微软操作系统和每个微软操作系统自那时已经能够 CIFS 服务器和客户端的功能。Microsoft 操作系统使用 CIFS 的远程文件操作 （通常映射的网络驱动器），浏览 （通过网上邻居图标）、 （NT 和 Windows 2000）、 身份验证和远程打印机服务。它会公平地说，本机 Microsoft 网络的核心围绕其 CIFS 服务。CIFS 协议是因为微软的大型企业和家庭用户群，发现几乎到处都。口味的 Unix 操作系统还实现 CIFS 客户端/服务器通过 Samba 程序。苹果计算机也有 CIF

4、S 客户端和服务器可用，这可能会使 CIFS 的最常见的文件共享协议可用。CIFS 历史记录：1984 年，IBM 写了允许上小的子网的主机之间的基本网络通信应用编程接口 (API)。API，但是，所需实际发送和接收数据的传输层协议。第二年，IBM 发布能让来生活的 NetBIOS API 的传输层协议。API 和传输协议被合并成一个实体，并称为 NetBIOS 增强的用户界面或 NetBEUI。当时，其他传输协议是共同使用，和 NetBIOS API 很快，实施使用 DECnet、 IPX/SPX 和 TCP/IP 等各种其他的传输协议。API 变得相当流行。不久之后，微软和英特尔创建的第一

5、个节目的 SMB/CIFS 文件共享协议，标题为核心协议。微软和英特尔选择了使用上述的 NetBIOS API 的上层 CIFS 数据包传递。因此，通过 TCP 使用 NetBIOS CIFS 成为标准的网络文件共享 Microsoft 操作系统的机制。许多功能添加了初始的核心协议，随着时间的推移。目前，大多数 Windows 客户端支持至少 6 的不同变体 CIFS 协议中，每个版本，通常包含一些更多的功能，比上一次。到目前为止，至少 100 不同 CIFS 操作，列表中不断增长。小幅鲁棒特征集包括： 文件访问 文件和记录锁定 安全文件缓存 文件更改通知 协议协商 扩展的文件属性处理 批的请

6、求 Unicode 支持CIFS 协议，但是，绝对显示年龄的迹象。几次在最后 13 年，已扩展议定书 的功能集和造成的影响越来越明显。有多个完成相同的任务的 CIFS 数据包和 CIFS 数据包的许多有记录的选项。互联网工程任务组 (IETF) 和存储网络产业协会 （SNIA） 努力纠正这种困境。它们正在朝着创建 CIFS1.0 规范，其中列出了只需要在未来的支持的当前 CIFS 操作的子集。规范还试图定义更清楚各包选项。有很多工作来做，但这绝对是一个好的开始。NetBIOS：本节将重点常用的上层 CIFS 服务的 NetBIOS 职能。如上文所述，NetBIOS 运行在许多级别的传输协议，但

7、对于现代天实现，TCP/IP 协议套件是目前为止最普遍使用的传输协议。在 1987 年 RFC1001 和 RFC1002 中记录的技术和 NetBIOS 对运行的 TCP/UDP （aka NBT) 的概念。这两个文件都非常完整 ；RFC1001 涵盖概念和方法，而 RFC1002 包括详细的规格。在这些文档中所述三个主要服务： 名称服务、 会议服务和数据报服务。每个这些服务和典型 CIFS 实现的关系将在下文讨论。包括在这一节的最后是潜在未来 NetBIOS 变化的简短说明。服务名称：NetBIOS 名称是人类可读的名称分配给网络上的计算机。这些名称最常见的 Windows 操作系统在网上

8、邻居中。NetBIOS 命名同样的目的为 DNS 系统在 TCP/IP 的世界 ；它允许调用的计算机的名称，人类和系统的可读名称映射到传输地址，如 IP。不过，非常不同的 NetBIOS 名称注册的 IP 和解析名称到 IP 的方法。更好地理解的 NetBIOS 名称操作运作这一节首先涵盖主要性能的 NetBIOS 命名约定，然后介绍常见 NetBIOS 命名程序的简要概述了。NetBIOS 命名属性：广播和/或基于服务器。NetBIOS 名称注册和查找可以全部完成通过广播和局部区域网络或通过使用中央 NetBIOS 名称服务器 （NBNS 或 WINS 1 ）。通常，通过 DNS，可以使用只

9、有一个集中的名称服务器。是和/或的选项，必须由管理员使用任一配置所有的 NetBIOS 计算机在网络上： 广播唯一 （b 节点） 只有 NBNS （p 节点） 广播第一次和 NBNS 仅当没有响应广播 （m 节点） NBNS，然后广播如果服务器没有响应 （h 节点）由于这些选项，有两个，每个命名的活动，其中一个描述的广播的方法，其他描述的服务器的方法的说明。动态注册。DNS 和 NetBIOS 命名也不同如何创建可读的名称和 IP 地址之间的关联。与 DNS，管理员通常有一次，添加到服务器的 DNS 条目和 DNS 名称和 IP 静态永远举行。与 NetBIOS，当计算机启动时，它在注册其名称

10、 /ip 组合动态。NetBIOS 计算机也可以取消注册其名称每当它不再需要该名称。名称语法。NetBIOS 名称必须符合一组严格的规则。下面的列表描述了主要的属性的名称必须遵守。1. 注册的 NetBIOS 名称可以引用 （唯一名称），或者单个的工作站或可以参考的工作组 （组名称） 的所有一部分的多个节点。2. NetBIOS 名称存在没有分层格式平面名称空间中。这意味着有没有点(即。 字符） 的 NetBIOS 名称，作为在 DNS 名称2 。因为这个平面名称空间的任何唯一的名称 （如上所述） 只能注册在一台计算机。3. NetBIOS 名称必须只包含以下范围的字符、 a-z、 A-Z、

11、0-9 或以下字符之一 ！ # $ % & ( ) - .4. NetBIOS 名称来描述该资源，使用最多 15 个字符，16届字节指的资源类型。资源类型字节指示注册计算机有哪些属性3 .NetBIOS 常见过程概述：两个最常见 NetBIOS 名称服务网络上的计算机程序名称注册和名称查询。虽然名称查询确定与给定的名称关联的 IP 地址名称注册将 IP，与相关联的 NetBIOS 名称。下文为 b 节点和 p 节点列出这两个过程。M 节点和 h 节点，将会在一起，有时会尝试使用广播的方法第一，和有时会首先尝试使用 NBNS 方法合并这些程序。名称登记 （b 节点）：工作站希望登记的名称生成一个

12、 NetBIOS 名称注册数据包 （在 RFC1002 中定义），然后广播数据包通过 UDP 协议端口 137 上的子网。此数据包中包含工作站欲注册的名称和该工作站的 IP 地址。工作站然后重复此过程三次，等待 250 毫秒之间广播节目。在此期间，工作站等着看是否任何其它工作站将发送回一个防御数据包。从已注册此名称为其自己的任何其他工作站将发送此数据包 （防御不应将发送一个组名称上如是合法的注册相同的组名称的多个工作站)。如果收到没有防御反应，则工作站已成功注册名称。名称登记 （p 节点）：P 节点还生成一个 NetBIOS 名称注册数据包 （在 RFC1002 中定义），而是直接向通过 UD

13、P 协议端口 137 NBNS 服务器数据包单播数。NBNS 然后搜索它的内部名称的数据库，检查其他已注册了相同的唯一名称的工作站。如果已注册名称，NBNS 发送回负名称注册响应4 。如果没有工作站已注册名称，服务器将发送肯定名称注册响应和工作站已成功注册名称。名称查询 （b 节点）：欲获取 IP 地址的 NetBIOS 名称从工作站首先生成名称查询请求 （在 RFC1002 中定义），然后广播数据包通过 UDP 协议端口 137 上的子网。请求数据包包含工作站欲查询的 NetBIOS 名称。工作站然后重复此过程 3 倍，等待 5 秒之间每个重新传输。在此期间，工作站或者接收积极名称查询响应的

14、计算机的名称，拥有来自或接收到什么。如果接收到积极名称查询响应时，包将包含查询的 NetBIOS 名称的 IP 地址。名称查询 （p 节点）：P 节点查询还生成名称的查询请求，但再次单播数直接向通过 UDP 协议端口 137 NBNS 服务器数据包。NBNS 然后搜索匹配的 NetBIOS 名称为其内部数据库。如果找到匹配项，NBNS 将发送回请求的 IP 地址与工作站积极名称查询响应。如果找不到匹配，NBNS 将发送回工作站负名称查询响应。会议服务：RFC1001 各国，会话是可靠的消息交换，一对 NetBIOS 应用程序之间进行。会话在全双工、 顺序，以及可靠。会话服务的 NetBIOS

15、是哪个网络的计算机交换消息的泛型方法。这些消息可以是任何类型 ；会话服务只关注到可靠地按顺序的两个点之间传输消息。RFC1001 去说 TCP 端口 139 上的应该用于模拟会议服务功能。TCP 与少数的例外情况极为类似的会议服务。主要区别是 TCP 是面向流和不保留消息边界。这是相对于这一次在网络上发送一条消息，并预期一次从网络读取一条消息的会话服务。但是，解决这个问题很简单： 每个会话服务数据包只是封装与指示邮件的大小前小头发送。CIFS 使用会话服务发送和接收上层的所有命令，包括文件和打印机的所有操作。因此，在任何 CIFS 网络通信中的第一步通常是建立在客户端和服务器之间的 NetBI

16、OS 会话。会话服务是由小组定义的网络基元的介绍如下。描述还包括原始映射到 TCP/IP 的方式。 电话： 启动的 NetBIOS 会话。这被映射到 TCP，启动和创建全双工的 TCP 连接，然后发送 NetBIOS 调用的数据包。呼叫数据包中包含客户端的 NetBIOS 名称和服务器的 NetBIOS 名称。 听： 等待 NetBIOS 调用命令。这被映射到 TCP 作为服务器等待端口 139 传入的请求会话 （TCP 启动，随后通过接收呼叫数据包上文所述）。 挂断： 结束 NetBIOS 会话。这是由只需启动正常的 TCP 拆卸序列映射到 TCP。 发送： 通过 NetBIOS 会话发送一

17、条消息。这是由封装与小头包含邮件大小的数据，然后通过 TCP 流发送数据映射到 TCP。 接收： 从 NetBIOS 会话接收消息。这被映射到 TCP 作为接收从 TCP 流，直到到了整个邮件 （由上面提到的小头的大小）。 会话状态： 从 RFC1001获取有关请求者的会话，根据指定的名称的所有信息。这不是由作者是意识到任何 CIFS 实现使用。会话服务将很容易地映射到 TCP，并因此，描述和实施不是过于复杂。CIFS 的每个数据包封装与指示邮件大小的 4 字节会话标题中，虽然是很容易忘记以本机 CIFS 是不只是通过 TCP 模式运行。数据报服务：RFC1001 各国，数据报服务是不可靠的、

18、 非顺序的、 无连接的服务。数据报服务由 NetBIOS 应用程序用作快速、 广播能力、 低开销的方法来传输数据。正如 RFC 说明指出，不过，数据报传递是不可靠的也可以到达顺序。RFC 继续状态端口 138 上的 UDP 协议应被用于实现 tcp/ip 协议内的 NetBIOS 数据报服务。UDP 是非常相似的 NetBIOS 数据报服务，但仍必须稍微修改要效仿的所有的数据报服务功能。是通过 UDP 发送的所有的 NetBIOS 数据报包有头前暂停处理它们。此标头包含两个重要信息: NetBIOS 名称的数据包发件人和 NetBIOS 数据报是否零碎，无法通过 UDP 发送。使用此信息，可以

19、完全模拟 NetBIOS 数据报服务，通过 UDP 协议。CIFS 实现通常使用 NetBIOS 数据报服务，进行浏览。浏览是发现 （Windows 然后在网上邻居中显示此列表） 在网络上的 CIFS 服务器的 NetBIOS 名称的过程。浏览不属于标准的 CIFS 协议，不过。虽然大多数 CIFS 实现还实现浏览，它们是单独的实体。因此，纯的 CIFS 实现将不需要执行的 NetBIOS 数据报服务，只对会话和上文所述的名称服务。未来的变化：许多供应商目前正期待完全淘汰 NetBIOS 和只需运行 CIFS 直接通过 TCP 和 UDP。CIFS1.0 的草案规范明确指出 CIFS 不取决于

20、任何特定的传输协议和有简短的附录，它指示如何通过 TCP CIFS 将运行以本机方式。NetBIOS 仍然存在主要用于向后兼容性。如果删除了 NetBIOS，所做的更改不会十分激烈。DNS 和域的名称将替换 NetBIOS 命名服务。会议服务所需的所有数据包会都运行直接通过 TCP，并会有没有 NetBIOS 前暂停处理标头。所需的数据报服务的所有数据包会都运行直接通过 UDP，并再次，pre 暂停处理标头将成为不必要。如果这些变化，实际上将由供应商是未知的。微软似乎很感兴趣提供无 NetBIOS CIFS。如果微软最终不会释放操作系统使用 CIFS NetBIOS 脱钩，其他供应商可能还使交

21、换机。CIFS 塔内件简而言之，通用的网络文件系统 (CIFS) 是允许文件共享网络节点之间的网络协议。客户端发送到服务器的请求数据包，并响应数据包与客户端的服务器响应的客户端服务器设计基于议定书 。每个发送的数据包中包含标准的头，再加上两个可变长度字段使用的包的特定信息。每个数据包还包含命令字段，指示该数据包试图完成的一般用途。常用命令字段指示包的目的，是要登录、 打开文件、 从文件中读取或写入文件。要获得更深入的了解，议定书 上 CIFS 下面, 有三个详细的部分。第一节涵盖主要协议属性。第二节介绍 CIFS 标准数据包报头通过关系图创建的各个字段和定义它们的目的。最后一节有两个典型的数据

22、包序列演练： 登录到服务器并打开/读取的文件。协议属性：客户端/服务器 + 请求/响应：如上文所述，CIFS 体系结构基于客户端发送请求，并答复每个请求的服务器发送5 。该协议是能有多个优秀的同时请求。这被完成通过多重的 id （MID） 的使用。客户端确保了每个请求发送到服务器具有独特的 MID。当在服务器响应给定请求时，该响应包含相同的 MID。这种方式，多个请求可以发送到服务器，以及客户端可以简单地匹配与它生成的知道哪些请求只是已回复的 MID 中期响应。基于命令：CIFS 的每个数据包包含 1 字节命令中的一个字段。目前 100+ 命令，每个数据包的核心功能是围绕指定的命令。对客户端响

23、应总是有相同的命令代码，作为该请求。可在 CIFS1.0 草案规范内的常见命令代码列表。协议方言/谈判：自成立以来，在八十年代有很多版本的 CIFS 协议。每个协议版本称为方言和分配一个唯一的字符串以标识如PC 网络程序 1.0或NT LM 0.12方言。当客户端想要访问远程服务器上的文件时，发送的第一个 CIFS 数据包是协商协议数据包。此 CIFS 的数据包，在客户端列出的所有方言字符串它有能力的认识。在响应数据包中，服务器指示它希望进行交流，或指示服务器理解没有方言的方言。这种方法，客户端和服务器可以协商哪些特定 CIFS 会话使用的方言。/共享用户级安全性：一个共享是一个服务器实体 （

24、通常是一个文件的文件夹或打印机） 被标记为可用，以 CIFS 客户端的网络共享。限制的访问共享是带来两种方式之一：1. 用户级安全性： 指示欲访问共享的客户端必须提供用户名和密码进行访问。这提供了服务器管理员细粒对谁有权访问该共享的控制。在 Windows NT 和 Windows 2000 中使用这种类型的安全。2. 共享级安全性： 指示共享本身需要密码才能访问，但没有用户名是必需的建立了没有用户标识。例如，X 的密码无法分配到一定的份额。任何用户知道密码 X 然后可以访问的共享。没有细致的控制，因为没有概念的单个用户和他们的权利。在 Windows 95 和 98 使用这种类型的安全。加密

25、：上面的两个安全方法之一，实际密码发送到服务器6 以加密格式。有两种常用的加密方法： 较新的 NT 风格与较旧的 LAN 管理器样式。这两种加密方法使用质询响应身份验证，服务器向客户端发送一个随机字符串，并预计证明客户知道随机字符串和用户密码的响应。命令配料：许多 CIFS 数据包都能借用其他 CIFS 数据包，以减少响应延迟和更好地利用网络带宽。这种技术被称为效率与中国配料。机会锁定：当 CIFS 包指定打开的文件时，可以请求机会锁定操作 （锁定）。如果授予服务器，操作锁定指示客户端没有其他实体正在访问该文件。这允许客户端对它想要的文件并不一定非要把它们写在作任何修改都立即向服务器。有多种类

26、型的机会锁定和他们有细微的差别。请参见 CIFS1.0 草案规范的详细信息。数据包报头：每一个 CIFS 请求和响应作为模板使用下面的数据包报头。模板后介绍了各个领域。012345670123456701234567012345670xFF我 B命令错误类必须为零错误代码错误代码 （续）标志Flags2垫或安全签名 通常垫，因此必须为零树 ID （工贸署）进程 ID (PID)用户 ID (UID)多重 ID （中）字数统计由字数统计变量指定 ParameterWords 字数统计 的可变大小本节中的单词数。ByteCount由 ByteCount 变量指定缓冲区 ByteCount 在本条中

27、可变大小的字节数。标头：CIFS 的每个数据包的开头包含 4 个字节的标头。第一个字节为 0xFF，紧接着的字母的 ASCII 表示 ，是，和 B。命令：命令字段包含一个字节代码指示 CIFS 数据包类型。从该字段的 CIFS1.0 草案的例子是 SMB_COM_READ_ANDX 7 （0x2E）、 SMB_COM_TREE_CONNECT （0x70） 和 SMB_COM_NEGOTIATE （0x72）。错误类：服务器指示给定的请求非常成功，错误类的字段。通常情况下，该字段是零，表示成功。如果非零，该字段指示的错误代码是从哪个班。错误类字段设置时，采用下列值之一： ERRDOS (0x0

28、1） 错误是从核心 DOS 操作系统设置 ERRSRV (0x02） 由服务器的网络文件管理器生成错误 ERRHRD (0x03) 硬件错误 ERRCMD (0xFF) 命令不是SMB格式错误代码：这 16 位字段指示已发生的错误的类型。它通常设置为零，指示没有错误。如果设置，此数字与上面的错误类结合可以提供完整的错误说明，如密码错误或文件不存在CIFS1.0 草案中抬头。正如与错误类，此字段设置只能由上一个请求的响应中的服务器。标志：大多数的标志字段中的 8 位指定特定的选项。注意在此字段中的唯一一个颇有点 3。3 位设置为 1，此特定的数据包中的所有路径名必须须都被当作为无壳。3 位设置为

29、 0，当所有的路径名是区分大小写的。Flags2:这 16 位字段指定更多的选项。有用的位： 位 0，如果设置，指示服务器可能会返回长文件名，在响应中。 位 6，如果设置，指示任何请求中的路径名是长文件名。 如果位 16，设置，指示该数据包中的字符串以 UNICODE 编码。垫/安全签名：此字段通常设置为零。树 ID （工贸署）：工贸署是一个 16 位的数字标识的资源 （磁盘共享或打印机，通常） 所指的这个特定的 CIFS 数据包。当数据包进行交换，的确没有任何与资源时，此数字将是毫无意义和被忽略。如果客户希望获得对资源的访问权限，客户端将发送 CIFS 数据包与命令字段设置为 SMB_COM

30、_TREE_CONNECT_ANDX。在此数据包，指定的共享或打印机名称 （即 /SERVER/DIR）。然后，服务器将验证存在相应的资源，并在客户端具有访问权限，然后返回表示成功的响应。在此响应数据包，服务器将设置工贸署随意的任何数字。从此以后，如果客户机希望提出请求特定的资源，它将设置工贸署数它时获得。进程 ID (PID)：PID 是一个 16 位的数字标识哪个进程发出 CIFS 请求客户端上。服务器使用此号码进行检查并发问题 （通常以保证的文件将不损坏的竞争客户端进程）。用户 ID (UID)：UID 是 16 位的数字，发出 CIFS 请求客户端的用户标识。通过发送包含用户名和密码的

31、 CIFS 会话设置请求，客户端必须从服务器获取 UID。后验证用户名/密码，服务器响应设置的会话，并包括生成的 UID。客户端然后所有未来 CIFS 请求中使用已分配的 UID。如果这些客户端请求的任何要求被检查的文件/打印机权限，服务器将验证请求中的 UID 已执行的操作所需的权限。UID 的有效期仅为给定的 NetBIOS 会话。其他会话可能使用相同的 UID 具有不同的用户相关联的服务器。注意： 如果服务器运行在共享级安全模式 （见上文），UID 是毫无意义和被忽略。多重 ID （中）：MID 是一个 16 位值，用来让多个优秀的客户端请求存在不会产生混淆。每当客户端发送一个 CIFS 数据包，它检查是否有任何其他悬而未决的请求挂起。如果是这样，它确保新的请求会有不同的 MID 然后以前未完成的请求。每当服务器答复 CIFS 请求，它确保它将发送的响应与中期，它收到请求相匹配。在执行此过程，客户端可以总是知道究竟哪些优秀的请求传入的答复相关的。