上一篇文章給大家揭示了一個事實——SMB文件共享的性能很拉胯。

今天也就給大家講講為什么大多數NAS上的文件共享的性能是“拉胯他媽給拉胯開門——拉胯到家了”。

“文件共享”這件事在現在大多數計算機用戶或者數碼用戶看來是一個再尋常不過的操作。但很多人并不自知“文件共享”的性能羸弱的問題。

我們先做一個腦補一個故事情節：

在一個閉塞的小山村里面，人們還保持著先秦時代的生活和運作方式，對外界一無所知。他們也會有一些貨運的需求，在這個小山村里面有兩種運輸工具，一種是牛車，另一種是馬車。

村里面的大聰明就會覺得馬車在馳騁起來的速度要比牛車快很多。

但村里還有更聰明的人，通過觀察得出來另一個結論——在走山路的時候，由于牛的力氣比馬大，在山路的運輸中牛車比馬車更有效率。

于是在村里就對到底是馬車還是牛車更有運輸效率一直爭吵了很多年，直到這個村子里的人看到有一條鐵路從村子邊上通過。

村里的人就開始嘲笑，用這些東西運輸還不如牛車吧？

其實大部分普通用戶就是生活在村子里面的村民，IT是一個“知道經濟”，它的價值在于你見過多少東西。如果村民們不到外面走走，哪怕是他們看到了村邊的火車，也難以想象到世界上還有這玩意：

這個故事情節，大家自行對號入座。

好了，說回SMB，今天我們對SMB要有一個比較全面的認知。

SMB（Server Message Block，服務器消息塊）是一個老古董了，老到了比看這篇文章的人都要古老，在1987年，微軟為了讓網絡上的計算機相互通訊開發了SMB協議。

如果對IT的歷史有所了解的話，會發現這個協議是在1983年TCP/IP協議制定之后被開發出來的。但是我們要知道，1983年internet網絡并不普及。因此SMB并不是針對于TCP/IP協議開發的。

SMB的再下一層實際上是NetBIOS（Network Basic Input/Output System，網絡基本輸入/輸出系統）。

因此，我們在看到一個網絡共享的時候，我們會發現在網絡共享的資源地址上有一個“主機名”。

這個主機名又別于TCP/IP網絡中的主機名，也和域名系統的主機名有所差別。就是簡簡單單的一個字符串。實際上這個在SMB中的主機名就來自于NetBIOS。

NetBIOS的這個歷史就更久遠了。這是1981年IBM立項，在1983年由sytek開發實施的IBM PC Network中的功能。IBM PC Network是第一個PC局域網標準。但是IBM當時并不看好這種形式，而采用了當時更先進的令牌環網，當然了，后面的事情我們也知道，令牌環網迅速的被以太網所取代……而NetBIOS標記主機的功能卻被一代代的沿襲下來。

直至現在，很多主機還是支持NetBios的功能的。

“直至現在”還在支持，這里面就牽扯到了早早年間的老技術如何適配到現在的新技術上的問題了。其實，我們在Windows PC上所使用的NetBIOS并不是原汁原味的。在Windows系統中一共出現了三種NetBIOS，最早期純的NetBIOS是配合令牌網絡存在的，還有 NetBIOS over IPX/SPX是對應IPX網絡的，以及NetBIOS over TCP/IP是對應于現在的TCP/IP網絡系統的。在當年計算機上網絡設置并不僅僅是要設置IP地址，還得設置一個IPX ID。其實在1995年左右的時間大部分可以局域網對戰的游戲都是只支持IPX網絡的……當時的聯眾之所以能讓大家在網絡上玩局域網互聯游戲也是因為聯眾本身就是一個IPX Proxy。

SMB協議的底層就是建立在對NetBIOS的支持下才能夠完成服務器消息塊的傳遞。在這個時候我們就可以看到，本身在TCP/IP協議下可以直達的一個信息通道，就非得往NetBIOS上再繞一圈。

“TCP/IP一家獨大”是當初微軟開發SMB的時候所沒有預見到的。而微軟沒有預見到的事情還不止這點。SMB——服務器消息塊，如果我們從字面上看“服務器消息塊”怎么都難以和“文件傳輸”或者“文件共享”聯系到一起。要知道早期的開發人員都是王八吃筷子——腦子一根筋，起的名字各種名稱十分的專業務實但也必須必的土掉渣，像是FTP（File Transfer Protocol，文件傳輸協議）、HTTP（Hypertext Transfer Protocol，超文本傳輸協議）、TCP（Transmission Control Protocol，傳輸控制協議）、SMTP（Simple Mail Transfer Protocol，簡單郵件傳輸協議）……都是望文生義直接能讀出來就知道是做什么用的協議。

而“服務器消息塊”，我們也可以直接讀出來，并理解這是“服務器以塊數據包傳輸消息”的協議，注意這里是傳送消息，并不是傳送文件。基于SMB我們不僅僅可以傳輸文件、還能共享打印機、發送服務器控制指令、獲取服務器狀態信息……

微軟嘛……總是喜歡一不小心把事情搞大。這種公司的文化就是如此，當初搞個游戲機不叫游戲機，而叫做客廳電腦；搞個瀏覽器不叫瀏覽器而叫Internet Desktop；

搞個MP3不叫MP3而叫數字媒體播放器……

這個公司的企業文化就是這樣，總是喜歡把很多的功能集合在一起，再弄個一個大一統的名字，這是刻在骨子里的基因。

所以，SMB并不只是文件傳輸用的協議大家也就應該有所了解了——這是M$tyle。事情做好沒做好在其次，M$得有自己的架勢（Or 風格）。

但多功能、大一統就意味著樣樣都會也樣樣稀松。這類東西就得慢慢的打磨，有的實在打磨不下去了，就干脆舍棄掉，例如WindowsPhone

有的打磨的還不錯，就可以一直走下去，例如Windows Server；但在生或死之間則有更多的產品是處在薛定諤貓的狀態——半死不活。SMB就是一個很典型的案例。

它的根基扎在NetBIOS上，放眼的卻是未來。在SMB成長的階段中微軟沒有預見到文件共享、把文件在局域網上傳輸逐漸的成了一個使用計算機系統的常見場景。等到預見到的時候大家對SMB的依賴已經成了一個常態。在Windows Vista階段，微軟試圖給SMB改個名字叫做CIFS（Common Internet File System，通用互聯網文件系統），呃，呃，呃，聽聽這個名字，是不是很有M$tyle？

傳文件就傳文件，搞個毛毛的“通用互聯網文件系統”這么大的概念來嚇唬我們？相對于SMB微軟又在CIFS里面增加了大量的能夠實現“通用互聯網文件系統”的功能。

好在SMB大家都已經用慣了叫慣了，CIFS在短暫出現后，又被后面的SMB2、SMB3逐漸取代。雖然被逐漸打磨升級，但SMB本身的底層設計并沒有改變。

在SMB的邏輯中當一臺服務器響應了SMB客戶端后，客戶端會向服務器發送一系列消息（Message，知道為啥叫“服務器消息塊”了吧？），在獲得了服務器響應后，繼續再發消息到服務器，以完成相應的任務。

從現代計算機設計來看SMB有一些喋喋不休，用我們天津話說叫做“碎嘴子”。SMB的嘴有多碎呢？哪怕傳輸一個1字節的文件，客戶端也要和服務端交互12次。如果文件或者對象比較大，那么SMB就會在傳輸文件實體數據的時候進入一個單元循環（unitil Loop）

反復的喋喋不休的來回發送和確認數據包。這就是“請求-響應”式協議的固有缺陷了，而在循環中所需要的請求-響應次數則根據系統的最大傳輸單元（MTU）限制來決定。

這種模式為什么在SMB出現之初沒有什么問題呢？原因在于1990年代計算機的存儲單元都比較小，iN在1994年購買的電腦只有40MB硬盤，即便是在10Mbps的網絡上將硬盤的全部容量傳輸到另外一臺電腦上，也只需要不到一分鐘的時間。SMB所帶來的額外開銷就并不顯著了。

但現在，我們拍一張照片也可能達到40MB的容量，即便是網絡升級到了1G或者2.5G，但是SMB的這種“請求-響應”的機制并沒有變化，而且咱們在討論SMB標準模型的時候并沒有考慮網絡的延遲

每次請求和響應之間的延遲也會極大的增加SMB的傳輸開銷，因此無論是在傳輸大文件或者大量小文件的時候，你都會覺得SMB的效率并不是那么高。——當然了，你得有和其他傳輸模式的比較，否則，我們的討論就停留在村里的牛車和馬車的討論上了。

這還不是SMB最糟糕的情況！

SMB是微軟的一個私有協議。理論上僅僅可以在微軟的Windows系統中使用。那么NAS上的SMB共享協議是什么呢？——這是一個“山寨”貨。

1992年還在澳大利亞大學上學的Tridge通過逆向工程（主要是嗅探）的方法實現了在UNIX上實現了一系列的Windows 網絡功能，在1993年這些功能逐漸形成了一個unix套件 “netbios for unix”，在1996年這套套件逐步升級發展，發布了Samba 1.9.17，同時這個套件也進入自由軟件領域。它的一個最重要功能就是實現了SMB。

由于Tridge在Samba和rsync（沒錯，常用的rsync也是他寫的）上的成就，Tridge在2020年1月26日被授予“澳大利亞勛章”——這是一個澳洲公民的極高榮譽。

當Samba進入自由軟件領域后，剛剛發行不久的Red Hat Linux和Debian迅速的將Samba納入到自己的默認安裝選項中。到了今天為止，幾乎所有的Linux系統中都有了Samba。unix用戶和大量的Linux用戶都利用Samba和Windows交換文件。這些用戶外加Windows原有的用戶也就讓SMB成為了目前使用最多的一個文件分享/傳輸系統。

SMB的真正普遍運用并不是因為SMB本身優異的性能，而是存量用戶加上開源社區的推動。

同時，在現在很多利用Linux的設備中（例如我們的很多NAS）也基于Samba的代碼實現了文件夾共享功能。

只不過這些linux中的Samba性能比較接近原生的Windows SMB而已，并沒有達到100%的Windows SMB性能水平。出現這樣的狀況的一個主要原因是在于SMB是反向工程的產物，另一個重要的原因是SMB并不完全是依靠C來寫的，還有部分是Python代碼，這是一種解釋性語言代碼，本身的效率就有瓶頸。

對于很多NAS的普通用戶來說Samba的共享文件夾其實還有性能沒有被釋放。如果我們打開一個群暉的Samba配置文件——這個文件在/etc/etc/samba目錄下：

映入眼簾的就是這部分內容了：在里面寫著“IMPORTANT: Synology will not provide technical support for any issues caused by unauthorized modification to the configuration.”翻譯過來就是 “重要提示：對配置進行未經授權的修改所引起的任何問題，Synology 將不提供技術支持。”

那么smb.conf是什么呢？這是Samba的配置文件，例如我們的建議配置方式是：

[global] log level = 1 socket options = TCP_NODELAY IPTOS_LOWDELAY read raw = yeswrite raw = yesoplocks = yesmax xmit = 65535dead time = 15getwd cache = yeslpq cache = 30[okplace] veto oplock files = this/that/theotherfile[badplace] oplocks = no

這是基于調試和測試的結果：

同時，也得配合網卡、系統和驅動本身的能力來細微調節，但很多NAS用戶根本不做這些優化，或者很多NAS系統會禁止用戶做優化，這就讓Samba本身就弱的性能更進一步降低。