本文作者Michael Morris在網絡架構上具有長期經驗。
最近幾周的工作非常有趣。這幾周，我們一直在解決昂貴的富士通M8000服務器和網絡存儲在萬兆網吞吐性能上的問題。M8000通過TCP上的NFS訪問存儲。最后，我們才發現這不是網絡問題。作為網絡工程師，我們都見過這種情況：只要性能出現問題，就會有人說"這肯定是網絡的問題"。這需要一段時間去偽存真，先破除這一網絡上的錯誤觀點，再將重點放在服務器驅動程序和補丁上面。
應用團隊經常會對他們無法從單純的萬兆網絡中獲得應得利益而感到吃驚。"哥們，這可是萬兆網絡，會有什么問題？"
我們來快速的回顧一下相關知識，TCP是一項數據交換的工作。服務器發送一定量數據（數據量取決于網絡參數），然后服務器等待客戶端應答。如果服務器和客戶端的網絡延遲大（比如從美國通過廣域網傳輸到印度），那么應答時間就會很長。這會拖慢數據傳輸的持續吞吐量。盡管很多人其實不知道這一理論，不過在天生的理解力下他們都會給出"這些數據必須要漂洋過海"的解釋。好的，這已經和正確答案相差不遠了。
在10GbE數據中心中，并不是所有的連接都是內置的。對網絡不是很了解的人常常會說，"這可是萬兆，它應該以10Gbps傳輸。而且數據中心里也沒有什么海，只是一些配線板和交換機。"這也導致了人們心中會有一個簡單的外推法，只要出現緩慢的情況，那么必然是"網絡中的問題"，因為基礎設施都是在同一機架內的。
不幸的是，數據中心網絡的TCP，延遲和網絡參數同廣域網有著一樣的特性。而且，當你花了10GbE的錢卻沒享受到10Gbps的吞吐量的時候你就自然會開始抱怨。
因此，讓我們假設你有一個萬兆以太網網卡服務器，一個經過了3跳數（hops）的10GbE網絡，以及另一臺擁有萬兆以太網網卡的服務器。應用通過TCP使用NFS協議出書數據，TCP設置為默認：
帶寬 = 10Gbps
TCP Windows Size = 64K（65,536）
MTU = 1500
延遲= 1.00毫秒RTT
將這些數值輸入TCP計算器的話，我們看到結果是很差的525Mbps（是"M"，而不是"G"）。從系統管理員的角度來看："我把價值數百萬美元的服務器放在了10GbE網絡中，但是我得到的性能還不及千兆，你這網絡可真爛。"可是實際上，網絡根本就沒有發揮TCP的全部。
那么，我們該怎樣獲得性能提升？
首先，如果你可以購買一些更好的網卡和交換機，那么你可以將延遲減少到0.3毫秒（300微秒）。這樣的話吞吐量就可以擴充三倍到1.7 Gbps。這顯然好多了，但是我們仍然只用到了網絡的17％。接下來，讓我們來更改TCP網絡參數，將其改成262K。在3ms和262K網絡參數的情況下，吞吐量迅疾飆升到6.99Gbps！看，這就是我們所談到的。
最后，讓我們將目標轉移到在0.3毫秒RTT延遲下TCP網絡參數究竟應該設定到多少的問題上。375K是比較合適的一個值。這對于數據中心企業級系統非常實際。
此外，我還是要為這些計算做一下注腳。這些都是理論上的東西。這當然要比"網絡應該在10Gbps下運行"的傳統理論要好，不過其仍然只是理論。不同的環境，數據包丟失，錯誤，排隊延遲等等，都將影響數據中心兩個主機之間的實際吞吐速度。此外，這篇文章是基于上面提到的那個TCP計算器來寫的。其似乎是正確的，但它可能不是很準確。我在六年前寫了一個比較值得信賴的Excel電子表格，而這個表格算出的優化后的結果是4.2 Gbps，而不是6.99 Gbps。
不過這無傷大雅，我們的主題沒有偏離。如果沒有數據中心端到端監控和系統團隊的調優，你可能永遠不會實現10GbE網絡的投資。所以這才是真正的網絡工程！
