2009-02-24 192 views
23

我確定這有一些古老的遺留原因,但它是什麼?這看起來像是一項面向可靠數據交付的服務。爲什麼NFS默認使用UDP?

+1

出現NFS默認不再使用UDP,請參閱一些答案。 NFSv4甚至可能只使用TCP? – rogerdpack 2012-10-17 15:18:05

+1

是的,對於NFSv4,請參閱https://tools.ietf.org/html/rfc7530#section-3.1。 UDP在這一點上大部分都會消失。 – 2017-02-24 21:38:08

回答

22
  • NFS最初設計用於損失率非常低的局域網。
  • UDP更快,而且具有更少的開銷
  • NFS是無狀態的,所以它的簡單客戶端重試

需要注意的是NFS V3 +可以使用TCP。

1

當協議將由應用程序本身管理時使用UDP。應用程序可能會有更好的想法,或者可能會更快(在應用程序的特殊條件下)。 TCP非常好,但有很多與之相關的開銷。

1

表現。 UDP的開銷比TCP低得多。另一方面,NFS必須自己處理可靠的傳輸(與TCP相比),但由於這是LAN連接問題和包丟失(或更好:應該是)不成問題的LAN協議,因此它針對性能進行了優化。

+0

這只是誤導。作爲默認傳輸方式的UDP是導致NFS快速鏈接(例如Gbit/s或10 GBit/s以太網)配置不當的最重要原因。 – Feuermurmel 2014-05-27 08:39:34

2

我的猜測是,這可能是遺留(歷史)原因。最初,NFS可能在低延遲網絡中使用,其中幾乎沒有出錯的可能性,因此啓動三次握手以建立TCP連接(連同雙向確認所有消息)的開銷超過了簡單性使用像UDP這樣的無連接協議。

當使用UDP作爲傳輸協議時,可能需要NFS客戶端來管理重傳。

6

UDP是NFSv2的默認值(現在沒人真的應該使用),但NFSv3默認使用TCP。 TCP掛載更可靠,並且您知道您的網絡問題比UDP更快。

0

無狀態UDP連接使網絡流量最小化,因爲NFS服務器在客戶端被授權訪問共享卷後向客戶端發送cookie。這個cookie是一個存儲在服務器端的隨機值,並且與來自客戶端的RPC請求一起傳遞。

2

UDP是無狀態的,TCP不是,但TCP有很多預定義的屬性,它們並沒有包含NFS,或者說NFS想管理這些細節。特別是,當TCP正在進行數據包傳輸時,它確定超時等。

使用UDP,您將失去不需要任何方式的開銷。如果NFS文件系統原本就是這樣,那麼系統會執行寫操作,如果它只有一半完成,那將會很糟糕......所以NFS(在硬模式下)將繼續重試以永久完成事務,1分鐘, 5,10和小時,一天...當連接回來時,交易可以繼續完成...

NFS在「狀態」而不是TCP之後,它的設計設置了一個新的狀態新的連接(或重新連接),該連接(和狀態)可能會因爲任何(硬件)原因而死亡,並且新的連接不會持續該狀態...考慮處理文件...您只需將該過程獨立, NFS連接會退出一段時間,但是當它回來時,一切都會繼續。這些日子裏,應用程序更智能,路線更多,事物更模塊化,我們更加不耐煩......如果它不打算計劃..有人接到一個電話,並且必須登錄,然後才能繼續......可以回到當天,當它可以離開時,這是一個更加無縫的事情......它的工作方式今天仍然很好,但現在有更多的選擇,並且現在更傾向於有更多的人更快地修復所有事情。此外,每個結束會話對象的想法來回對象,而不是在兩個工作之間進行,直到雙方都認爲他們完成了 - 當天NFS爲你做了很多這樣的事情......

這個比喻有點類似於RS232的工作原理......電子設備會做它的事情並加載它們的緩衝區並且會變滿並且不得不停止(或者失去信息),他們可以傳遞信息流(並且清空它們的緩衝區並且繼續)當CTS(清除發送引腳 - 如在插頭上的金屬引腳)高或低時(它應該是)。

1

還使用了UDP,因爲它可以大大減少內存使用量。在20世紀80年代,最初開發NFS時,你將擁有一個帶有4-8MB RAM的UNIX系統,並且(至少在學術環境中),「服務器」可能只是這些4-8MB系統中的一個,額外的磁盤連接到它。在服務器上使用RAM是一個大問題,你可能已經損失了幾個MB到TCP緩衝區,我已經更好地用作磁盤緩存。它還可以輕鬆處理內存壓力,過載的NFS服務器可以簡單地刪除請求。