検索
連載

第22回 ファイル共有プロトコルSMB/CIFS(その3)基礎から学ぶWindowsネットワーク(1/3 ページ)

SMB/CIFSプロトコルのパケットの構造やコマンド・コードの詳細。Windowsネットワークのトラシューには必須の情報だ。

PC用表示 関連情報
Share
Tweet
LINE
Hatena
連載 基礎から学ぶWindowsネットワーク ―― Windowsネットワーク管理者への道 ―― 
Windows Server Insider

 

「連載 基礎から学ぶWindowsネットワーク ―― Windowsネットワーク管理者への道 ―― 」のインデックス

連載目次


 今回はSMB/CIFSプロトコル解説の最後として、SMB/CIFSパケットの構造やコマンド・コード、SMB/CIFSプロトコルの例について見ていく。

SMB/CIFSコマンドの概要

 SMB/CIFSプロトコルで定義されているコマンドの一覧は、いくつかのカテゴリに分けられる。主なカテゴリとしては次のようなものがある。

セッション管理 SMB/CIFSサーバの利用開始におけるセッションの接続や切断などの管理
ファイル/フォルダ操作 ファイルやフォルダの読み出しや書き込み、作成、削除などの操作。SMB/CIFSのバージョン(ダイアレクト)により、サポートされている機能に差がある(以下同じ)
属性操作 ファイル属性の読み出しや設定
スプール操作 プリンタ・スプールの操作
ファイル・ロック操作 多重アクセス時の排他制御
セキュリティ/認証 ユーザー認証やアクセス・コントロール・リストの設定/操作など
DFSサポート 分散ファイル・ステムDFSの操作。Windows NT以降のOSでのみ利用可能
プロセス間通信(IPC) メール・スロット(ファイルと似た操作でメッセージをマルチキャストする機能)や名前付きパイプ(ファイルと似た操作で相互通信する機能)による、プロセス間通信機能(2つのプロセス間で通信を行う機能)のサポート
デバイス・サポート COM:ポートなどのハードウェア・デバイスのサポート
主なSMB/CIFSプロトコルの機能

 なおSMB/CIFSプロトコルでは、物理的なファイルのほかに、名前付きパイプやメール・スロットといったプロセス間通信機能も扱うことができるが、RPCや、より高度なネットワーク・サービス(WINSやネットワーク・ブラウザ・サービスなど)については特に規定されているわけではない。これらのサービスはSMB/CIFSプロトコル上で名前付きパイプなどを使って実装されたサービスであり、SMB/CIFSプロトコルから見れば、単なる上位アプリケーションにすぎない。

SMB/CIFSプロトコルにおける通信モデル

 SMB/CIFSプロトコルにおける通信の形態は、いわゆるサーバ/クライアント方式であり、図にすると次のようになる。


SMB/CIFSプロトコルにおける通信モデル
SMB/CIFSプロトコルでは、クライアントからコマンドを1つ送信すると、それに対する応答がサーバから1つ返される。ただし場合によっては、1つのコマンドに対して複数の応答が行われたり、複数のコマンドを多重化(マルチプレックス)して送受信したりすることもある。

 クライアントから送信されたコマンドはサーバで1つずつ処理され、結果がクライアントに返される。一般的なコマンドでは1つのコマンドに対して1つの応答が返されて処理が完結するが、場合によっては複数回のコマンドのやりとりが発生することがある。例えば転送効率を上げるために大きなデータ・ブロックで読み書きすることもあるし、ファイル名の検索結果を返す場合には、一致するパス名をすべて返すために、何度かやりとりが行われる。またこれとは逆に、パケットの送受信回数の総数を抑えるために、連続する何個かコマンドをまとめて1つのパケットにまとめる場合もある。

SMB/CIFSパケットの構造

 SMB/CIFSプロトコルは、下位のトランスポート層プロトコルとして、NetBIOSのセッション・サービスを利用するものと、TCPのポート445番を直接利用するものの2種類があることはすでに述べた。この2つを分類して、前者をSMB、後者をCIFSと呼ぶことがあるが、現在では特に区別せず、まとめてSMB/CIFSプロトコルと呼ばれている。本連載でも、特に断らない限り同じものを指すことにする。


SMBとCIFSの関係
Windowsネットワークでは、もともとSMBというファイル共有プロトコルを利用している。これは下位にNetBIOSインターフェイスを利用するプロトコルであり、実際のトランスポート層としてはNetBEUIやNBT、IPX/SPXが利用できる。だがNetBIOSはネットワーク管理の点から見ると望ましくないので(複数のポートを利用するし、ルーティングも困難、ブロードキャストが多い、ほかのインターネット・プロトコルとなじまない、など)、TCP/IPをダイレクトに利用するCIFSというプロトコルが開発された。CIFSはWindows 2000以降のWindows OSで利用できる。ただし現在では特に区別せず、まとめてSMB/CIFSプロトコルと呼ばれることも多い。

 SMB/CIFSプロトコルで利用されるパケット構造は、以下に示すように、SMBでもCIFSでもほぼ同じであるる。トランスポート層のペイロード部分(データ格納領域)の先頭には、SMBの「データ長」を表すフィールドが用意されている。このデータ長は、SMBのヘッダ部分とSMBのデータ部分を合わせたサイズを表しており、トランスポート層プロトコルからペイロード部分を取り出しても、そのSMB/CIFS部分のサイズを容易に知ることができる。


SMBパケットとデータ長フィールドの配置
SMBヘッダの直前には、このようにSMB/CIFS部分のサイズを表す「データ長」フィールドが置かれている。NBTの場合は、もともとNBTのセッション・サービスのヘッダ中にこのデータ長フィールドが置かれているが(連載第18回の「2.NBTパケットの構造」を参照)、CIFS(TCPの445番を利用するサービスの場合)では、わざわざ互換になるように1byteの0と3bytesの「データ長」フィールドを用意し、どちらも同じ形になるようにしている。これにより、下位のトランスポート層サービスのプロトコルによらず、両者をほぼ同じように扱うことができる。

 データ長フィールドに続いてSMBのデータ(ヘッダ+データ)が置かれている。具体的なパケットの構造は次のようになっており、先頭の32bytesはコマンドによらずほぼ同じ内容になっている。33byte目から先は、コマンドで利用するパラメータや読み書きするデータなどに使われ、コマンドごとにその内容は異なっている。


SMB/CIFSパケット・フォーマット
SMB/CIFSパケットの構造は、クライアントからサーバへ送られるコマンドも、サーバからクライアントへ送り返される応答も、このような同じ構造を持っている。先頭から32bytesはほぼ固定的な内容、その後はコマンドごとに異なるパラメータや読み書きするデータなどに使われる。

 以下簡単に、SMB/CIFSヘッダ中の各フィールドについて説明しておく。

■IDデータ(先頭4bytes)
 SMBパケットの先頭には、SMB/CIFSプロトコルのパケットであることを示す4bytesの特別な識別用文字列データが置かれている。先頭は0xffで、その後に“SMB”と続いているので、パケットをダンプして解析したりする場合には、パケットの先頭を見つける目印として役に立つ。

■コマンド(1byte)
 サーバに対するコマンドを表すコード(番号)を指定する。SMB/CIFSプロトコルでは100個近いコマンドが定義されている。詳細は後述。

■エラー・クラス(1byte)
 エラーのクラス(種類)。DOSエラーやサーバ側のエラー、ハードウェア・エラーなどの分類を表す。エラーなしの場合は0。

■エラー・コード(2bytes)
 エラー・コード。エラーなしの場合は0。エラー・クラスごとにエラーの原因を表すコード。詳細は後述。

■フラグ/フラグ2(1byte/2bytes)
 コマンドに対する補助フラグ・データ。例えばこのパケットがクライアントからサーバへのコマンドか、それともその逆の応答であるかどうかや、パス名の大文字/小文字を無視するかどうかの設定といった設定が含まれる。

■ツリーID(TID)(1byte)
 ツリーID。詳細については前回の記事を参照。

■プロセスID(PID)(1byte)
 
プロセスID。このSMB/CIFSプロトコルを呼び出したプロセスの識別番号。詳細については前回の記事を参照。

■ユーザーID(UID)(1byte)
 ユーザー(セッション)ID。このSMBセッションで利用される認証ユーザーの情報。詳細については前回の記事を参照。

■マルチプレックスID(MID)(1byte)
 マルチプレックスID。同一のサーバ/クライアント間で、複数のコマンドを多重化(マルチプレックス)して送受信する場合に、どのプロセスから送受信されているかを識別するためのID。

■ワード・データとバイト・データ(可変長)
 コマンドごとのパラメータや読み書きするデータ、拡張コマンド・コードなど。コマンドごとに内容は異なる。それぞれデータ部分の長さを表す「ワード・カウント」と「バイト・カウント」に続いて、データ部が続く。


Copyright© Digital Advantage Corp. All Rights Reserved.

       | 次のページへ
ページトップに戻る