サーバーメッセージブロック

SMBプロトコルでは、オポチュニスティックロックは、クライアントによるネットワークファイルのキャッシュを制御することでパフォーマンスを向上させるように設計されたメカニズムです。 ^{[ 11 ]}従来のロックとは異なり、オポチュニスティックロック（OpLock）は厳密にはファイルロックではなく、相互排他を提供するためにも使用されません。

機会主義的ロックには4つの種類がある。

バッチロック

バッチ OpLock は、DOS バッチ ファイル実行操作の特定の動作をサポートするために作成されました。この動作では、短時間内にファイルが何度も開閉されるため、パフォーマンス上の問題が発生します。この問題を解決するために、クライアントはタイプ「batch」の OpLock を要求することができます。この場合、クライアントはクローズ要求の送信を遅延させ、後続のオープン要求が与えられた場合、2 つの要求は互いにキャンセルされます。^{[ 12 ]}

レベル1 OpLocks / 専用ロック

アプリケーションが「共有モード」で、他のプロセス（または他のクライアント）によって開かれていないSMBサーバー上のファイルを開くと、クライアントはサーバーから排他的なOpLockを受け取ります。これにより、クライアントはこの特定のファイルにアクセスできる唯一のプロセスであると想定でき、サーバーにコミットする前にファイルへのすべての変更をキャッシュすることができます。ファイルの読み書きに必要なラウンドトリップが少なくなるため、これはパフォーマンスの向上につながります。別のクライアント/プロセスが同じファイルを開こうとすると、サーバーはクライアントにメッセージ（ブレークまたはリボークと呼ばれます）を送信し、クライアントに以前付与されていた排他ロックを無効にします。その後、クライアントはファイルへのすべての変更をフラッシュします。

レベル2オペレーションロック

クライアントが排他的な OpLock を保持している状態で、ロックされたファイルが第三者によって開かれた場合、クライアントは排他的な OpLock を解放して、他のクライアントの書き込み/読み取りアクセスを許可する必要があります。その後、クライアントは サーバーから「レベル 2 OpLock」を受け取ることができます。レベル 2 OpLock は読み取り要求のキャッシュを許可しますが、書き込み要求のキャッシュは許可しません。

フィルタ OpLock

Windows NT 4.0 で追加されたフィルタ OpLock は、レベル 2 OpLock に似ています が、ファイルのオープンとロックの受信の間に共有モード違反が発生するのを防ぎます。Microsoft は、複数の読み取りを許可することが重要な場合にのみフィルタ OpLock を使用し、 それ以外の状況ではレベル 2 OpLock を使用することを推奨しています。OpLock を保持しているクライアントは、実際にはファイルのロックを保持しているわけではなく、別のクライアントがロックと矛盾する方法でファイルにアクセスしようとしたときに、ブレークによって通知されます。ブレークが処理されている間、他のクライアントの要求は保留されます。

休憩

SMBプロトコルの「標準」動作とは対照的に、サーバーからクライアントへブレーク要求が送信される場合があります。これは、OpLockが無効になったことをクライアントに通知するものです。例えば、別のクライアントがOpLockを無効にする方法でファイルを開こうとした場合などに発生します。最初のクライアントにはOpLockブレークが送信され、ローカルでの変更（バッチOpLockまたは排他OpL​​ockの場合）があればすべて送信し、OpLockブレークを承認する必要があります。この承認を受けて、サーバーは2番目のクライアントに一貫した方法で応答できます。

SMB プロトコルの使用は、ネットワーク上のブロードキャスト トラフィックの大幅な増加と相関関係にあることが多い。しかし、SMB 自体はブロードキャストを使用していない。SMB でよく見られるブロードキャストの問題は、実際にはNetBIOSサービス ロケーション プロトコルに起因する。デフォルトでは、Microsoft Windows NT 4.0サーバーは NetBIOS を使用してサービスを宣伝し、サービスを検索する。NetBIOS は、特定のホストで利用可能なサービスを一定間隔でブロードキャストすることで機能する。これは通常、ホスト数が少ないネットワークでは許容できるデフォルト設定となるが、ネットワーク上のホスト数が増えると、ブロードキャスト トラフィックの増加が問題を引き起こす可能性がある。Windows Internet Naming Service (WINS) またはDomain Name System (DNS) の形で名前解決インフラストラクチャを実装することで、この問題が解決される。WINS は Windows NT 4.0 ネットワークで使用される独自の実装であったが、Microsoft ネットワークの設計と保守において独自の問題と複雑さをもたらした。

Windows 2000 のリリース以降、マイクロソフトは名前解決に WINS を使用することを非推奨とし、現在では階層型ダイナミック DNSがすべての Windows オペレーティングシステムの既定の名前解決プロトコルとして構成されています。DNS による (短い) NetBIOS 名の解決には、DNS クライアントが短い名前を展開する必要があり、通常は接続固有の DNS サフィックスを DNS ルックアップ クエリに追加します。WINS は、従来の Windows 環境およびアプリケーションとの相互運用性を確保するために、クライアント上でセカンダリ名前解決プロトコルとして構成できます。さらに、マイクロソフトの DNS サーバーは、DNS をサポートしていない従来の (Windows 2000 より前の) 環境との名前解決統合をサポートするために、名前解決要求を従来の WINS サーバーに転送できます。

ネットワーク設計者は、レイテンシがSMB 1.0 プロトコルのパフォーマンスに大きな影響を与え、FTPなどの他のプロトコルよりもパフォーマンスが劣ることを発見しました。監視により、ホスト間のネットワークレイテンシを無視した「チャット」の度合いが高いことが明らかになりました。^{[ 13 ]}例えば、インターネット経由のVPN接続では、ネットワークレイテンシが発生することがよくあります。Microsoft は、パフォーマンスの問題は主に SMB 1.0 がストリーミングプロトコルではなくブロック レベルのプロトコルであり、元々は小規模LAN用に設計されたためであると説明しています。ブロック サイズは 64K に制限されており、SMB 署名によって追加のオーバーヘッドが発生し、TCP ウィンドウ サイズはWAN リンク用に最適化されていません。^{[ 14 ]}この問題の解決策には、更新された SMB 2.0 プロトコル、^{[ 15 ]}オフライン ファイル、TCP ウィンドウ スケーリング、 SMB 1.0 ^{[ 16 ]}および 2.0 ^{[ 17 ]}をキャッシュして最適化するさまざまなネットワーク ベンダーのWAN 最適化デバイスなどがあります。

バリー・ファイゲンバウムは、DOS INT 21hローカルファイルアクセスをネットワークファイルシステムに変えることを目的として、1983 年初頭にIBMで SMB を設計しました。 ^{[ 3 ]}マイクロソフトは、最も一般的に使用されているバージョンに大幅な変更を加え、1990 年頃に3Comと共同でOS/2向けに開発を開始したLAN Managerオペレーティングシステムに SMB サポートを組み込みました。 ^{[ 18 ] [ 19 ] [ 20 ]}マイクロソフトは、Windows for Workgroups ( 1992年頃) およびそれ以降の Windows バージョンで、プロトコルに機能を追加し続けました。LAN Manager 認証は、IBM の「LAN Manager」パスワードを使用するという元のレガシー SMB 仕様の要件に基づいて実装されましたが、DES の実装方法に欠陥があり、パスワードが解読される可能性がありました。^{[ 21 ]}その後、Kerberos認証も追加されました。 Windowsドメインログオンプロトコルは、当初、米国以外では40ビット暗号化を使用していた。これは、より強力な128ビット暗号化に対する輸出制限があったためである^{[ 22 ]} （その後、1996年にビル・クリントン大統領が行政命令13026に署名した際に解除された^{[ 23 ]}）。

SMB 1.0 (または SMB1) は、元々はNetBIOS フレーム( IEEE 802.2上の NetBIOS ) で動作するように設計されていました。その後、IPX/SPX (NBX) 上の NetBIOS やTCP/IP (NetBT) 上の NetBIOS に対応しました。また、Windows 2000以降、SMB はTCP ポート 445 を使用してTCP上で動作し、「ダイレクト ホスト SMB」と呼ばれる機能になっています。^{[ 24 ]} SMB と TCP の間には、依然として薄いレイヤー (NetBT のセッション サービスのセッション メッセージ パケットに類似) が存在します。^{[ 24 ]} Windows Server 2003 や従来のNASデバイスは、SMB1 をネイティブに使用します。

SMB1 は非常に通信量の多いプロトコルですが、低遅延のローカル エリア ネットワーク(LAN)ではそれほど問題になりません。しかし、広域ネットワーク(WAN) では、プロトコルの往復ハンドシェイクによってネットワーク固有の高い遅延が増幅されるため、非常に遅くなります。プロトコルの後のバージョンでは、ハンドシェイクの交換回数が削減されました。プロトコルの非効率性を軽減するアプローチの 1 つは、Riverbed、Silver Peak、Ciscoなどが提供するWAN 最適化製品を使用することです。より良いアプローチは、SMB を最新バージョンにアップグレードすることです。これには、NAS デバイスと Windows Server 2003 の両方をアップグレードすることが含まれます。SMB1 トラフィックを識別する最も効果的な方法は、Wiresharkなどのネットワーク アナライザー ツールを使用することです。Microsoft は、 SMB1 を使用するデバイスを追跡するための監査ツールをWindows Server 2016で提供しています。 ^{[ 25 ]}

Microsoft は2013 年 6 月にSMB1 を非推奨としました。 ^{[ 26 ]} Windows Server 2016 およびWindows 10 バージョン 1709には、デフォルトでは SMB1 はインストールされていません。^{[ 27 ]}

1996 年、Sun Microsystems がWebNFS を発表したとき^{[ 28 ]}、 Microsoft は SMB を Common Internet File System (CIFS) ^{[ 3 ]}に改名するイニシアチブを開始し、シンボリック リンク、ハード リンク、より大きなファイル サイズのサポート、およびNetBIOS をトランスポートとして必要とせずに TCP ポート 445 を介して直接接続をサポートする最初の試み(主に実験的な取り組みであり、さらなる改良が必要) など、より多くの機能を追加しました。Microsoft は、インターネット ドラフトとしていくつかの部分的な仕様をIETFに提出しました。^{[ 6 ]}これらの提出はその後期限切れになりました。

Microsoft は 2006 年にWindows VistaおよびWindows Server 2008でプロトコルの新しいバージョン (SMB 2.0 または SMB2) を導入しました。^{[ 29 ]}このプロトコルは独自規格ですが、新しいプロトコルを使用する Microsoft オペレーティングシステムと他のシステムが相互運用できるように、その仕様が公開されています。^{[ 30 ]}

SMB2 は、コマンドとサブコマンドの数を 100 以上から 19 に減らすことで、SMB 1.0 プロトコルの「チャット性」を低減します。^{[ 13 ]}パイプライン処理のメカニズムを備えており、前のリクエストに対する応答が到着する前に追加のリクエストを送信することで、高遅延リンクでのパフォーマンスを向上させます。複数のアクションを単一のリクエストにまとめる機能が追加され、クライアントがサーバーに対して行う必要があるラウンドトリップの数が大幅に削減され、結果としてパフォーマンスが向上します。^{[ 13 ]} SMB1 にも、複数のアクションをまとめる AndX と呼ばれる複合メカニズムがありますが、Microsoft クライアントは AndX をほとんど使用しません。また、「永続ファイル ハンドル」の概念も導入されています。これにより、無線ネットワークでよく見られるような短時間のネットワーク障害が発生しても、新しいセッションを再ネゴシエートするオーバーヘッドを発生させることなく、SMB サーバーへの接続を維持できます。

SMB2 にはシンボリック リンクのサポートが含まれています。その他の改善点としては、ファイル プロパティのキャッシュ、HMAC SHA-256ハッシュ アルゴリズムによるメッセージ署名の改善、サーバーあたりのユーザー数、共有数、オープン ファイル数の増加によるスケーラビリティの向上などがあります。^{[ 13 ]} SMB1 プロトコルは 16 ビットのデータ サイズを使用するため、最大ブロック サイズが 64K に制限されます。SMB2 は 32 ビットまたは 64 ビット幅のストレージ フィールドを使用し、ファイル ハンドルの場合は 128 ビットを使用するため、ブロック サイズに関する以前の制約がなくなり、高速ネットワークでの大容量ファイル転送のパフォーマンスが向上します。^{[ 13 ]}

Windows Vista/ Server 2008以降のオペレーティングシステムは、SMB2を使用できる他のマシンと通信する際にSMB2を使用します。SMB1は、古いバージョンのWindowsやさまざまなベンダーのNASソリューションとの接続に引き続き使用されます。Samba 3.5には、SMB2の実験的なサポートも含まれています。^{[ 31 ]} Samba 3.6は、Windowsのクォータ管理ツールを使用したユーザー クォータの変更を除いて、SMB2を完全にサポートしています。^{[ 32 ]}

SMB2 が導入されたとき、SMB プロトコルのサードパーティ実装者にとって、SMB1 に比べて多くの利点がもたらされました。元々IBMが設計した SMB1 はリバースエンジニアリングされ、後にXenix、OS/2、VMS ( Pathworks )など、さまざまな非 Windows オペレーティングシステムの一部となりました。X /Open は部分的に標準化しました。Microsoft は、2000 年 12 月にIETF がネットワーク ファイルシステムバージョン 4 を正式に標準化したことへの対応として、 SMB2 を記述したインターネット ドラフトをIETFに提出しました。 ^{[ 33 ]}しかし、これらの SMB 関連のインターネット ドラフトは、IETF の標準化トラックの承認やその他の IETF の承認を得ることなく期限切れとなりました。(歴史的詳細については、 http://ubiqx.org/cifs/Intro.html を参照してください。) SMB2 は、過去との比較的明確な決別でもあります。Microsoft の SMB1 コードは、さまざまな SMB クライアントとサーバーで動作する必要があります。 SMB1では、 Unicodeサポートなどの機能が後から追加されたため、コマンド（特定の要求に対して返される構造体を選択する）に関する情報に多くのバージョンが存在します。SMB2では、プロトコル実装者にとって互換性テストが大幅に削減されます。また、SMB2のコードは、変動要素がはるかに少ないため、複雑さが大幅に軽減されます（例えば、SMB2ではUnicodeサポートが必須となるため、Unicode以外のコードパスは不要になります）。

Apple はOS X 10.9 "Mavericks"からSMB2 (独自のApple Filing Protocol 、現在はレガシー) に移行しました。^{[ 34 ]}ただし、この移行には互換性の問題がつきまといました。^{[ 35 ] [ 36 ]}実際、Samba がGPLv3を採用した後、Apple が Samba を放棄して SMBX と呼ばれる独自の SMB 実装を採用した OS X ^10.7で、SMB2 の非デフォルト サポートが登場しました。^{[ 34 ] [ 37 ] [ 38 ]}

LinuxカーネルのCIFSクライアントファイルシステムは、バージョン3.7以降SMB2をサポートしています。^{[ 39 ]}

Windows 7およびServer 2008 R2で導入されたSMB 2.1は、新しい機会的ロック機構により、わずかなパフォーマンス向上を実現した。^{[ 40 ]}

SMB 3.0（以前はSMB 2.2と呼ばれていた）^{[ 41 ]}は、Windows 8 ^{[ 41 ]}およびWindows Server 2012 ^{[ 41 ]}で導入されました。これは、特に仮想化データセンターにおいて、機能を追加しSMB2のパフォーマンスを向上させることを目的としたいくつかの重要な変更をもたらしました^{[ 42 ]}。

• SMBダイレクトプロトコル（リモートダイレクトメモリアクセス[RDMA]経由のSMB）
• SMBマルチチャネル（SMBセッションごとに複数の接続）、^{[ 43 ] [ 44 ]}
• SMB透過フェイルオーバー^{[ 45 ] [ 46 ]}

また、エンドツーエンド暗号化や新しいAESベースの署名アルゴリズムなど、いくつかのセキュリティ強化も導入されています。^{[ 47 ] [ 48 ]}

SMB 3.0.2 (当時は 3.02 と呼ばれていました) は Windows 8.1 および Windows Server 2012 R2 で導入されました。^{[ 49 ] [ 50 ]}これらのバージョンおよびそれ以降のバージョンでは、セキュリティを強化するために、以前の SMB バージョン 1 をオプションで無効にすることができます。^{[ 51 ] [ 52 ]}

SMB 3.1.1 はWindows 10およびWindows Server 2016で導入されました。^{[ 53 ]}このバージョンでは、SMB3 で追加された AES-128 CCM暗号化に加えてAES-128 GCM暗号化がサポートされ、 SHA-512ハッシュを使用した事前認証整合性チェックが実装されています。また、SMB 3.1.1 では、それをサポートする SMB バージョンを使用するクライアントに接続する場合にセキュア ネゴシエーションが必須となります。^{[ 54 ]}

1991年、Andrew Tridgellは、 Unix系システム向けのSMB/CIFSネットワークプロトコルのフリーソフトウェアによる再実装（リバースエンジニアリングを使用）であるSambaの開発を開始しました。当初の目的は、 DEC Pathworksクライアントを実行しているPCクライアントがSunOSマシン上のファイルにアクセスできるようにするSMBサーバーを実装することでした。^{[ 3 ] [ 56 ]} SMBプロトコルは広く普及しているMicrosoft Windowsプラットフォームとのやり取りにおいて重要であるため、Sambaは、Unix系オペレーティングシステムなどのWindows以外のオペレーティングシステムがWindowsと相互運用できるようにする、互換性のあるSMBクライアントおよびサーバーのフリーソフトウェア実装として人気を博しました。

Sambaはバージョン3（2003年）以降、Microsoft Windowsクライアントにファイルおよび印刷サービスを提供し、プライマリドメインコントローラー（PDC）またはドメインメンバーとしてWindows NT 4.0サーバードメインと統合できます。Samba4のインストールは、Windows 2008ドメインおよびフォレスト機能レベルでActive Directoryドメインコントローラーまたはメンバーサーバーとして機能します。 ^{[ 57 ]}

Linuxディストリビューションのパッケージマネージャーは、cifs-utilsパッケージを検索できます。このパッケージはSambaのメンテナーによって提供されています。

NSMB (Netsmb および SMBFS) は、 BSDオペレーティングシステムのカーネル内 SMB クライアント実装のファミリーです。これは、Boris Popov によってFreeBSD 4.4 に初めて貢献され、現在ではNetBSDやmacOSを含む他のさまざまな BSD システムで見られます。^{[ 58 ]}実装はそれ以来大きく分岐しています。^{[ 59 ]}

macOS 版の NSMB は、現在では一般的なシンボリックリンクの表現方法で知られています。この「Minshall-French」形式では、シンボリックリンクは.symlink拡張子とXsym\nマジックナンバーが付いたテキストファイルとして表示され、常に 1067 バイトの長さになります。この形式は、ネイティブ SMB サーバーやサポートされていないファイルシステムにシンボリックリンクを保存するためにも使用されます。Samba はこの形式をmfsymlinkオプションでサポートしています。^{[ 60 ]} Windows 上の Docker もこの形式を使用しているようです。

NQ は Visuality Systems が開発したポータブル SMB クライアントおよびサーバー実装のファミリーです。^{[ 61 ]} NQ ファミリーは、組み込み SMB スタック (C 言語で記述)、純粋な Java SMB クライアント、およびストレージ SMB サーバー実装で構成されています。すべてのバージョンは SMB  3.1.1 方言をサポートしています。Linux、Windows CE、iOS、Android、VxWorks およびその他のオペレーティングシステムをサポートしています。

MoSMBはLinux用のユーザー空間SMB実装です。SMB 2.xとSMB 3.xをサポートしています。主な機能には、クラウド規模のアクティブ/アクティブ・スケールアウト・クラスタ、SMBダイレクト（RDMA）、SMBマルチチャネル、透過的フェイルオーバー、継続的な可用性などがあります。MoSMBは、ext4、ZFS、Lustre、CephなどのPOSIXファイルシステムに加えて、ストレージバックエンドとしてAmazon S3オブジェクトストレージもサポートしています。 ^{[ 62 ]}

Tuxera の Fusion File Share は、 Tuxeraが開発した独自の SMB サーバー実装で、カーネル空間またはユーザー空間のどちらでも実行できます。^{[ 63 ]} SMB 3.1.1 およびそれ以前のすべてのバージョンをサポートし、さらに、継続的な可用性 (永続ハンドル)、スケールアウト、RDMA (SMB Direct)、SMB マルチチャネル、透過的圧縮、シャドウコピーなどの高度な SMB 機能もサポートしています。

同様に、Likewiseは2009年にCIFS/SMB実装（バージョン1.0、2.0、2.1、およびSMB 3.0）を開発しました。これは、 Linux/Unixベースのデバイスで構築されたOEMストレージ製品で使用されるファイルへのネットワークアクセスを実現する、マルチプロトコル対応のID認識プラットフォームを提供するものでした。このプラットフォームは、従来のNAS、クラウドゲートウェイ、クラウドキャッシングデバイスで使用でき、ネットワーク経由でファイルへの安全なアクセスを提供しました。Likewiseは2012年にEMC Isilonに買収されました。

KSMBDは、Linuxカーネル向けのオープンソースのカーネル内CIFS/SMBサーバー実装です。ユーザー空間実装と比較して、パフォーマンスが向上し、SMB Directなどの機能の実装が容易になります。SMB 3.1.1およびそれ以前のバージョンをサポートしています。

• 「[ MS-CIFS]: 共通インターネットファイルシステム（CIFS）プロトコル」。オープン仕様。マイクロソフト。2020年10月30日。
  • 共通インターネットファイルシステム（CIFS）プロトコルを規定する。これはクロスプラットフォームでトランスポートに依存しないプロトコルであり、クライアントシステムがネットワーク経由でサーバーシステムによって提供されるファイルおよび印刷サービスを利用するためのメカニズムを提供する。
• 「[ MS-SMB]: サーバーメッセージブロック（SMB）プロトコル」。オープン仕様。マイクロソフト。2021年6月25日。
  • サーバーメッセージブロック（SMB）プロトコルを規定します。このプロトコルは、既存の共通インターネットファイルシステム（CIFS）仕様に対する拡張機能を定義しており、CIFS仕様の公開以降、マイクロソフトによって実装されています。
• 「[ MS-SMB2]: サーバーメッセージブロック（SMB）プロトコルバージョン2および3」。オープン仕様。マイクロソフト。2021年12月14日。
  • サーバーメッセージブロック（SMB）プロトコルバージョン2および3を規定する。これらのバージョンは、マシン間でのファイルおよび印刷リソースの共有をサポートし、サーバーメッセージブロックプロトコルの概念を拡張する。
• 「[ MS-SMBD]: SMB2 リモートダイレクトメモリアクセス (RDMA) トランスポートプロトコル」。オープン仕様。マイクロソフト。2021年6月25日。
  • SMB2リモートダイレクトメモリアクセス（RDMA）トランスポートプロトコルを規定します。これは既存のSMB2プロトコルのラッパーであり、iWARPやInfinibandなどのRDMA対応トランスポート上でSMB2パケットを配信し、これらのトランスポートのダイレクトデータ配置（DDP）機能を活用できるようにします。利点としては、CPUオーバーヘッドの削減、レイテンシの低減、スループットの向上などが挙げられます。