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 和 Windows 2000）、 身份验证和远程打印机服务。它会公平地说，本机 Microsoft 网络的核心围绕其 CIFS 服务。
CIFS 协议是因为微软的大型企业和家庭用户群，发现几乎到处都。口味的 Unix 操作系统还实现 CIFS 客户端/服务器通过 Samba 程序。苹果计算机也有 CIFS 客户端和服务器可用，这可能会使 CIFS 的最常见的文件共享协议可用。
CIFS 历史记录：
1984 年，IBM 写了允许上小的子网的主机之间的基本网络通信应用编程接口 (API)。API，但是，所需实际发送和接收数据的传输层协议。第二年，IBM 发布能让来生活的 NetBIOS API 的传输层协议。API 和传输协议被合并成一个实体，并称为 NetBIOS 增强的用户界面或 NetBEUI。
当时，其他传输协议是共同使用，和 NetBIOS API 很快，实施使用 DECnet、 IPX/SPX 和 TCP/IP 等各种其他的传输协议。API 变得相当流行。
不久之后，微软和英特尔创建的第一个节目的 SMB/CIFS 文件共享协议，标题为"核心协议"。微软和英特尔选择了使用上述的 NetBIOS API 的上层 CIFS 数据包传递。因此，通过 TCP 使用 NetBIOS CIFS 成为标准的网络文件共享 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 （aka NBT) 的概念。这两个文件都非常完整 ；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 协议端口 137 NBNS 服务器数据包单播数。NBNS 然后搜索它的内部名称的数据库，检查其他已注册了相同的唯一名称的工作站。如果已注册名称，NBNS 发送回负名称注册响应[4] 。如果没有工作站已注册名称，服务器将发送肯定名称注册响应和工作站已成功注册名称。
名称查询 （b 节点）：欲获取 IP 地址的 NetBIOS 名称从工作站首先生成名称查询请求 （在 RFC1002 中定义），然后广播数据包通过 UDP 协议端口 137 上的子网。请求数据包包含工作站欲查询的 NetBIOS 名称。工作站然后重复此过程 3 倍，等待 5 秒之间每个重新传输。在此期间，工作站或者接收积极名称查询响应的计算机的名称，拥有来自或接收到什么。如果接收到积极名称查询响应时，包将包含查询的 NetBIOS 名称的 IP 地址。
名称查询 （p 节点）：P 节点查询还生成名称的查询请求，但再次单播数直接向通过 UDP 协议端口 137 NBNS 服务器数据包。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 不取决于任何特定的传输协议和有简短的附录，它指示如何通过 TCP CIFS 将运行以本机方式。
NetBIOS 仍然存在主要用于向后兼容性。如果删除了 NetBIOS，所做的更改不会十分激烈。DNS 和域的名称将替换 NetBIOS 命名服务。会议服务所需的所有数据包会都运行直接通过 TCP，并会有没有 NetBIOS 前暂停处理标头。所需的数据报服务的所有数据包会都运行直接通过 UDP，并再次，pre 暂停处理标头将成为不必要。
如果这些变化，实际上将由供应商是未知的。微软似乎很感兴趣提供无 NetBIOS CIFS。如果微软最终不会释放操作系统使用 CIFS NetBIOS 脱钩，其他供应商可能还使交换机。
CIFS 塔内件
简而言之，通用的网络文件系统 (CIFS) 是允许文件共享网络节点之间的网络协议。客户端发送到服务器的请求数据包，并响应数据包与客户端的服务器响应的客户端服务器设计基于议定书 》。每个发送的数据包中包含标准的头，再加上两个可变长度字段使用的包的特定信息。每个数据包还包含命令字段，指示该数据包试图完成的一般用途。常用命令字段指示包的目的，是要登录、 打开文件、 从文件中读取或写入文件。
要获得更深入的了解，议定书 》 上 CIFS 下面, 有三个详细的部分。第一节涵盖主要协议属性。第二节介绍 CIFS 标准数据包报头通过关系图创建的各个字段和定义它们的目的。最后一节有两个典型的数据包序列演练： 登录到服务器并打开/读取的文件。
协议属性：
客户端/服务器 + 请求/响应：如上文所述，CIFS 体系结构基于客户端发送请求，并答复每个请求的服务器发送[5] 。该协议是能有多个优秀的同时请求。这被完成通过多重的 id （MID） 的使用。客户端确保了每个请求发送到服务器具有独特的 MID。当在服务器响应给定请求时，该响应包含相同的 MID。这种方式，多个请求可以发送到服务器，以及客户端可以简单地匹配与它生成的知道哪些请求只是已回复的 MID 中期响应。
基于命令：CIFS 的每个数据包包含 1 字节命令中的一个字段。目前 100++ 命令，每个数据包的核心功能是围绕指定的命令。对客户端响应总是有相同的命令代码，作为该请求。可在 CIFS1.0 草案规范内的常见命令代码列表。
协议方言/谈判：自成立以来，在八十年代有很多版本的 CIFS 协议。每个协议版本称为方言和分配一个唯一的字符串以标识如"PC 网络程序 1.0"或"NT LM 0.12"方言。当客户端想要访问远程服务器上的文件时，发送的第一个 CIFS 数据包是协商协议数据包。此 CIFS 的数据包，在客户端列出的所有方言字符串它有能力的认识。在响应数据包中，服务器指示它希望进行交流，或指示服务器理解没有方言的方言。这种方法，客户端和服务器可以协商哪些特定 CIFS 会话使用的方言。
/共享用户级安全性：一个共享是一个服务器实体 （通常是一个文件的文件夹或打印机） 被标记为可用，以 CIFS 客户端的网络共享。限制的访问共享是带来两种方式之一：
1. 用户级安全性： 指示欲访问共享的客户端必须提供用户名和密码进行访问。这提供了服务器管理员细粒对谁有权访问该共享的控制。在 Windows NT 和 Windows 2000 中使用这种类型的安全。
2. 共享级安全性： 指示共享本身需要密码才能访问，但没有用户名是必需的建立了没有用户标识。例如，X 的密码无法分配到一定的份额。任何用户知道密码 X 然后可以访问的共享。没有细致的控制，因为没有概念的单个用户和他们的权利。在 Windows 95 和 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 请求，它确保它将发送的响应与中期，它收到请求相匹配。在执行此过程，客户端可以总是知道究竟哪些优秀的请求传入的答复相关的。
字数统计和参数的话：CIFS 数据包使用这两个字段来保存特定命令的数据。CIFS 数据包页眉模板上面不能每个可能的 CIFS 数据包的每种可能的数据类型。若要纠正此问题，参数词字段创建具有可变长度。字数统计指定参数词字段实际上将包含多少 16 位字。这种方式，每个 CIFS 数据包可以调整执行它自己的特定命令的数据所需的大小。
对于每个数据包类型的字数统计通常是常量和 CIFS1.0 草案中定义的。有两个 wordcounts 定义的每个单独的命令 ；为客户端请求，另一个用于服务器响应的一个字数统计。因为有必要，可请求的数据量不一定是发出答复所需的相同数额需要两项罪名。
ByteCount 和缓冲区：这些字段是非常类似于以上 ； 字数统计和参数词字段他们持有数量可变的数据指定每个包的基础上的。Bytecount 指示数据的字节数将下面的缓冲区字段中存在。
上述参数数据部分和缓冲区之间的主要区别是它们存储的数据类型。缓冲区数据节通常持有大量原始数据 （例如文件数据），参数字数据部分通常用于保存少量的数据包的选项。
数据包序列演练：
两个常见 CIFS 客户端/服务器数据包交换列示如下。第一次交换显示哪些数据包被发送时客户端将首次启动与服务器的联系人： 建立 NetBIOS 会话、 CIFS 方言协商、 发送用户名和密码，和最后，连接到一个资源 （例如，打印机或目录的共享）。第二个 exchange 会检查打开文件并从中读取所需的数据包。
对于每个 exchange，初始的摘要概述的整个过程。此外，发送和接收的每个数据包是详细的 （通过上市出各种数据包标头值），也总结了。
请注意在所有示例中，客户端总是发送对 TCP 端口 139 和在服务器总是响应客户端选择的暂时端口数。此外，下列 CIFS 数据包字段不会为每个个人的数据包所述：
∙ 错误码类— — 总是零点时从客户端发送，并假定当从服务器 （示例不包括错误情形） 返回零。
∙ 标志— — 设置为 0x00 所有数据包 （区分大小写的路径名）
∙ Flags2— — 设置为 0x0001 的所有数据包 （长支持文件名称)
∙ 垫/安全签名— — 所有的数据包中设置为 0
初次接触、 登录和树连接：
当 CIFS 客户端确定它希望访问 CIFS 服务器上的资源时，下面的数据包序列被交换。第一，为了提供的可靠消息序列运输服务建立 NetBIOS 会话。然后，客户端和服务器协商会沟通的 CIFS 方言。客户端然后登录到服务器时，发送用户名和密码 （对于此示例，服务器将运行在用户级安全性）。最后，客户端连接到所需的资源。
# 1 数据包请求，客户端 –► 服务器
目的： 建立 NetBIOS 会话
摘要：客户端，欲与服务器交换 CIFS 数据包启动本身和服务器之间的 NetBIOS 会话 （称为"调用服务器"前面的 NetBIOS 部分）。这提供了两个端点之间的已编序的、 可靠的消息传递。注意客户端必须知道该服务器的 NetBIOS 名称才能调用它，也必须表明自己的 NetBIOS 名称。
要建立 NetBIOS 会话事件如下所示。第一，在客户端建立与服务器的端口 139 全双工的 TCP 连接。这实现的一旦客户端建立并通过 TCP 连接发送 NetBIOS 会话请求数据包 （不图解上面，NetBIOS 部分但 RFC1002 中所述）。总之，会话请求数据包包含客户端的 NetBIOS 名称、 服务器的 NetBIOS 名称和整型常数指示包的目的是建立一个 NetBIOS 会话。请有关更多详细信息，参阅 RFC1002。
# 2 数据包响应，服务器 –► 客户端
目的： 积极的 NetBIOS 会议确认
摘要：如果上述会议请求数据包包含服务器的 NetBIOS 名称，和数据包格式设置正确，与简单会话的服务器答复设立的确认。RFC1002 还描述了这 4 个字节的数据包。总之，它指示会议成功建立或错误代码。
# 3 数据包请求，客户端 –► 服务器
目的： 谈判 CIFS 方言
摘要：现在，建立 NetBIOS 会话，可以随时发送第一次真正 CIFS 请求客户端。客户端发送 SMB_COM_NEGOTIATE 命令和包括可识别 CIFS 方言的列表。
数据包：
命令： SMB_COM_NEGOTIATE （0X72）
工贸署： 忽略此数据包中。
PID ： 设置来处理客户端进程的 ID。
UID ： 忽略此数据包中。
MID ： 任何的唯一编号。
字数统计: 0
ParameterWords ： 有没有因为字数统计为 0。
Bytecount ： 设置为 119 （取决于客户端知道多少 CIFS 方言的变量）。
缓冲区： 包含 119 个字节，价值的方言说明、 示例会如下："PC 网络程序 1.0"、"MICROSOFT 网络 3.0"、"DOS LM1.2X002"、"DOS LANMAN2.1"，"3.1a"，"NT LM 0.12"中的。
# 4 数据包响应，服务器 –► 客户端
目的： 从请求列表中选择 CIFS 方言
摘要：服务器现在响应协商协议请求通过选择中进行通信的方言。
数据包：
命令： SMB_COM_NEGOTIATE （0x72）
工贸署： 忽略此数据包中。
PID ： 当数据包是从服务器时忽略。
UID ： 忽略此数据包中。
MID ： 匹配唯一号码选择了上面。
字数统计： 此数目取决于选择的方言。对于本示例，我们将假定服务器选择了"NT LM 0.12" [8] 。在此情况下，字数统计是 17。
ParameterWords ： 此处包含的 17 字显示所选择的方言和许多服务器属性。注意的是 MaxMpxCount （其中规定挂起的请求，客户端可以启动的最大数目） 和 32 位能力的标志 （如果这如果支持 UNICODE，则表示支持大文件，如果支持 NT 命令，等等）。
Bytecount ： 变量，通常大于 8。
缓冲区： 通常包含客户端加密目的使用下一个数据包中的 8 个字节的随机字符串。
# 5 数据包请求，客户端 –► 服务器
目的： 用户登录
摘要：现在，CIFS 方言已获通过后，客户端发送数据包包含一个用户名和密码以获取用户 ID (UID)。此数据包还中继到服务器，客户端功能，因此必须发送数据包，即使服务器正在使用共享级别安全。
数据包：
命令： SMB_COM_SESSION_SETUP_ANDX （0x73）
工贸署： 忽略此数据包中。
PID ： 设置来处理客户端进程的 ID。
UID ： 忽略此数据包中。
MID ： 任何的唯一编号。
字数统计: 12
ParameterWords ： 这一节是非常类似于服务器的谈判协议参数字响应。然而，上市服务器的功能，而不是它列出了客户端的。它还包含在下面的缓冲区部分中提供的密码的大小。
Bytecount ： 变量，在下面的缓冲区中包含加密的密码、 用户名、 操作系统和本机 LAN 管理器的名称。因此，在此处列出的大小取决于所有这些实体的字符串大小。
缓冲区： 如上文所述，此字段实际上包含密码、 用户名和其他识别操作系统所涉及的字符串。
# 6 数据包响应，服务器 –► 客户端
目的： 指示用户 ID (UID) 或返回错误，如果坏密码
摘要：一旦服务器收到的加密的密码和用户名，它会检查结合是否有效。如果密码无效，将返回此响应数据包与错误类和代码设置为相应的错误值。如果用户名/密码是正确的则此数据包包含客户端将开始从这里发送的每个数据包的 UID。
数据包：
命令： SMB_COM_SESSION_SETUP_ANDX （0x73）
工贸署： 忽略此数据包中。
PID ： 当数据包是从服务器时忽略。
UID ： 16 位的数字，服务器已分配给代表客户端的用户标识。
MID ： 匹配唯一编号选择了上面。
字数统计: 3
ParameterWords ： 没有相关的正常运行。
Bytecount ： 变量，在下面的缓冲区中包含说明服务器操作系统和本机 LAN 管理器类型的字符串。
缓冲区： 包含该值指示服务器操作系统和 LAN 管理器类型的字符串。
# 7 数据包请求，客户端 –► 服务器
目的： 连接到特定的资源
摘要：此时，客户端验证自身到服务器，并可以继续连接到实际的共享。此数据包，在客户端指定它希望访问的共享。共享名称指定 UNC 格式 （即 //SERVER/SHARE）。
数据包：
命令： SMB_COM_TREE_CONNECT_ANDX （0x75）
工贸署： 忽略此数据包中。
PID ： 设置来处理客户端进程的 ID。
UID ： 从以上的会话设置响应中返回的 UID 的服务器设置。
MID ： 任何的唯一编号。
字数统计: 4
ParameterWords ： 没有相关的正常运行。
Bytecount ： 变量，取决于下面请求的 UNC 字符串的大小。
缓冲区： 包含客户机希望访问的共享名称。
# 8 数据包响应，服务器 –► 客户端
目的： 指示树 ID （工贸署） 或错误，如果不存在的共享名称
摘要：如果上面指定的共享存在并且用户具有访问权限，则服务器将返回与工贸署成功的响应设置数它希望，请参阅作为资源。如果不存在共享或用户没有访问权限，服务器会返回相应的错误类和这里的错误代码。假定此数据包表示成功，客户端现在有它从指定的共享访问文件所需要的一切。这是最后的邮包在此客户端/服务器交换。
数据包：
命令： SMB_COM_SESSION_SETUP_ANDX （0x73）
工贸署： 哪个服务器已分配给代表所请求的资源的 16 位数字。
PID ： 当数据包是从服务器时忽略。
UID ： 16 位数字表示该用户。
MID ： 匹配唯一编号选择以上。
字数统计: 3
ParameterWords ： 没有相关的正常运行。
Bytecount ： 变量，在下面的缓冲区中包含说明请求的资源的本机文件系统和设备类型的字符串。
缓冲区： 包含状态本机文件系统和设备类型的字符串。
文件打开并读取：
一个客户端完成以上所述的初始数据包交换序列，它可能会打开并读取文件从共享请求。打开的文件包括一个 CIFS 请求和一个 CIFS 响应。读取的请求还包括一个请求和一个响应数据包。
# 1 数据包请求，客户端 –► 服务器
目的： 打开文件
摘要：为了读取或写入文件，首先必须打开它。此 CIFS 数据包会正是这样做。
数据包：
命令： SMB_COM_OPEN_ANDX （0x2D）
工贸署： 设置为返回工贸署从树的服务器连接以上的响应。
PID ： 设置来处理客户端进程的 ID。
UID： 从上述的会话设置响应返回的 UID 的服务器设置。
MID ： 任何的唯一编号。
字数统计: 15
ParameterWords ： 指定许多打开选项如模式 （读取、 写入或读写） 和共享模式 （无、 读取、 写入）。
Bytecount ： 变量，取决于包含文件名的字符串的大小。
缓冲区： 包含要打开的文件的名称。
# 2 数据包响应，服务器 –► 客户端
目的： 指示文件 ID 或错误代码，如果问题
摘要：服务器检查是否上面的文件名存在，并且如果在指定的用户 UID 有访问该文件的权限。如果不满足这些条件，则服务器会返回相应的错误类和错误代码，指示该问题什么。如果没有错误，则服务器返回响应数据包包括后续的访问该文件包中的文件 ID （FID） 可以使用。请注意 FID 返回到客户端的响应参数词字段中。标准 CIFS 头上没有 FID 字段。
数据包：
命令： SMB_COM_OPEN_ANDX （0x2D）
工贸署： 16 位的数字，其中服务器分配给代表所请求的资源。
PID ： 当数据包是从服务器时忽略。
UID ： 16 位数字表示该用户。
MID ： 匹配唯一编号选择以上。
字数统计: 15
ParameterWords ： 指示哪种类型的操作发生的很多标志和非常重要的 16 位 FID。
Bytecount: 0
缓冲区： 没有缓冲区中的数据。
# 3 数据包请求，客户端 –► 服务器
目的： 从文件中读取
摘要：假设以上的响应表示 FID 的客户端使用，现在可以发出实际的读取的请求的文件数据。
数据包：
命令： SMB_COM_READ_ANDX (0x2E)
工贸署： 工贸署从树设置为服务器返回连接以上的响应。
PID ： 设置来处理客户端进程的 ID。
UID ： 从会话设置响应上述设置为服务器返回的 UID。
MID ： 任何的唯一编号。
字数统计: 10
ParameterWords ： 在这里，FID 说所以知道服务器，打开的文件所指的客户端。此外在这里表示的是 32 位的文件偏移量和 16 位计数值。这两个数字听写的位置和多少文件从返回的数据。
Bytecount: 0
缓冲区： 没有缓冲区中的数据。
# 4 数据包响应，服务器 –► 客户端
目的： 返回文件请求的数据
摘要：此包包含请求的文件的数据。假设 UID，工贸署和 FID 只是所有有效数字在请求中，错误在这里应该是不太可能。
数据包：
命令： SMB_COM_READ_ANDX (0x2E)
工贸署： 哪个服务器已分配给代表所请求的资源的 16 位数字。
PID ： 当数据包是从服务器时忽略。
UID ： 16 位数字表示该用户。
MID ： 匹配唯一编号选择以上。
字数统计: 12
ParameterWords ： 在这里，表示被实际读取的字节数。这不一定匹配请求 （如请求超出文件边界） 的数目。
Bytecount ： 变量，缓冲区将保存文件数据，所以此号码也被实际读取的字节数。
缓冲区： 请求的文件数据。
最后的评论:
CIFS 协议的讨论到此结束。有关详细信息，请参考书目节或 www.codefx.com。意见或错误的意见呢？请通过电子邮件details@codefx.com.
这是很有可能在此文档中的错误。CodeFX 提供本文仅用于提供信息。CodeFX 否认所有的担保、 表示或暗示担保，包括适销性或特定用途适用性的担保。
参考书目：
奥尔巴赫，卡尔。Tcp/Udp 传输上的 Netbios 服务协议标准：
概念和方法。RFC1001，1987 年 3 月。
[关于如何实施各种 NetBIOS 呈现的概念和方法
TCP/UDP 网络上的服务。没有 CIFS 的信息，但是，CIFS 使用
NetBIOS，所以仍然相关的信息的传输协议。自由
可得到各地的网站。
奥尔巴赫，卡尔。Tcp/Udp 传输上的 Netbios 服务协议标准：
详细的规范。RFC1002，1987 年 3 月。
[相同特征以上，除此 RFC 给出实际的数据包格式和
仿真代码实现。也可在 web 上自由。]
埃克斯坦，庄-布朗和彼得 · 凯利。使用 Samba 。奥赖利。1999 年 11 月
[这本书虽然主要是有关使用和学习桑巴，它提供了质量
NetBIOS 和良好的常见 CIFS 问题的描述信息。第章
1 是最相关的。这本书是可用网上自由在
http://www.oreilly.com/catalog/samba/chapter/book/index.html.]
赫特尔克里斯"桑巴： 介绍"。Samba 网页。1999 年 6 月 10 日。桑巴
网页。2000。 http://www.samba.org/samba/docs/SambaIntro.html.
[CIFS 的体面的概述。包含对潜在未来 CIFS 的好信息。
可用网上自由在上面链接。]
霍。"CIFS： 常见的不安全因素失败审核"。禽的研究。
1997 年 1 月。http://web.textfiles.com/hacking/cifs.txt.
[标题说明了一切。这漫长的纸上安全给伟大的概述
CIFS 的缺陷。很好的信息，可自由地在上面链接网上。]
互联网工程任务组 (IETF) 存储网络工业协会
(SNIA)。常见的网络文件系统 (CIFS)
协议。因特网草案版本，2000 年 5 月。
[这是在这中引用了大量的规范 CIFS1.0 草案
文档。这是查找详细信息排名第一。
最好的地方找到最新的版本可能是 SNIA 网站
(www.snia.org ）。要从"产品和服务"链接
"工作组"到"nas"到"cifs"到"技术活动"。有一次，
检查"工作完成"节]。
公开组中。X 协议 / 打开 PC 互联网络： SMB，第 2 版.
伯克希尔公司，英国： X/打开有限，1992 年 9 月的公司。
[本文档是 X / SMB 协议规范的打开的 1992年尝试。
总之，很全面、 彻底，但是，所有的材料是有些过时
在这点上。不可用自由，必须购买直接从 X / 打开。]
夏普，理查德。"什么是 SMB"。Samba 网页。1999 年 9 月 27 日。Samba 网页
2000. http://www.samba.org/cifs/docs/what-is-smb.html.
[可能最佳 SMB/CIFS 介绍可用。也有许多有趣的链接。]
采煤机、 也很激动"SMB 的历史"。Samba 网页。1996 年 11 月 16 日。Samba 网页
2000. http://www.samba.org/cifs/docs/smb-history.html.
[包含 SMB 协议的历史记录。基本上的各种文档列表
这了 SMB 发展，他写过他们，以及何时。]
Tridgell，安德鲁。"内部 Microsoft 网络连接"。Samba 的 Ftp 站点。
ftp.samba.org/pub/samba/slides/inside_SMB.tar.gz 。1999 年 7 月 31 日。
[另一种很好的介绍 CIFS。这还包括一些浏览和
NetBIOS 名称服务的信息。写的原始桑巴的核心作者。]
附加信息：
有关其他信息，获取对上面列出的参考书目的全部或部分的访问。如果仍然需要更多的信息，请参考下面的链接。
∙ Samba 网站包含的信息，从 web 链接到演示文稿幻灯片的财富。这可以通过单击文档链接在www.samba.org找到。请注意上面的书目链接直接到此站点上的几个优秀文章。
∙ 可以在http://www.ubiqx.org/cifs/index.html找到的 NetBIOS 非常详细的解释和 CIFS 的简要概述.
∙ 微软自己的 FTP 站点上有一些 CIFS 文件。这可以位于ftp.microsoft.com/developr/drg/cifs 。其中许多文件描述了旧方言的 CIFS 协议。阅读"index.txt"文件上的 ftp 站点的详细信息可用的文件上。
∙ 以下网站包含许多有用的、 有趣的 CIFS 链接。http://ourworld.compuserve.com/homepages/TimothyDEvans/nbf.htm
∙ 有两个 CIFS 社区用途的邮寄列表。更多活动的两个是 Samba 列表中，可以搜索和订阅了通过以下链接。http://samba.org/samba/archives.html 。微软赞助商列表 ；可以查看或订阅了在http://discuss.microsoft.com/archives/cifs.html.
∙ 理解 CIFS 协议的最佳方法之一是看着它在行动中。从www.ethereal.com下载缥缈的数据包嗅探器的副本。如果您有的 GTK + GUI 库使用 Win32 和 Unix 机器 Ethereal。它是完全免费的并包括一个很正常的 CIFS 解析器。
∙ 最后，还可用于搜索和发布新闻组 comp.protocols.smb。
《CIFS协议详解》相关文档：
《我爱你中国》歌词详解最新09-01
采购合同必备条款详解09-14
第十五期青年大学习答案详解09-14
房屋租赁合同法律规定详解09-27
详解网络广告服务合同有哪些11-26
SAP-MM功能详解11-28
SAP功能详解-物料管理(1)11-28
P2P借贷平台(详解)12-25
中考作文写作指导：《我以______ 为知己》(附审题详解及满分作文16篇)01-19
个人租房合同注意事项大全【详解】01-31
