Why does NFS use UDP by default? Why does NFS use UDP by default? unix unix

Why does NFS use UDP by default?


  • NFS was originally designed to be used on a LAN where loss rates are very low.
  • UDP is faster, and has less overhead
  • NFS is stateless, so it's simple for clients to retry

Note that NFS v3+ can use TCP.


UDP is the default for NFSv2 (which nobody should really use these days) but NFSv3 use TCP by default. TCP mounts are more reliable and you know you have a network problem much faster than with UDP.


UDP is stateless, TCP isn't, but TCP has many predefined properties that didn't suite NFS, or rather that NFS wanted to govern the specifics. In particular, when TCP is doing packet transfers, it does govern timeouts, etc.

With UDP, you lose the overheads that you don't particularly want any way. When the NFS filesystem, the thought originally was, the system does a write, and if it only half finishes, that would be bad ... so NFS (in hard mode) will continue to retry to complete the transaction forever, 1 minute, 5, 10, and hour, a day ... when the connection comes back the transaction could continue to completion...

NFS looks after the "state" instead of TCP, whose design sets up a new state on the new connection (or reconnection), that connection (and state) could die for whatever (hardware) reason and a new connection wouldn't persist that state ... Think about processing a file ... you just leave the process alone, the NFS connection drops out for a bit, but when it comes back, everything will just continue.. These days applications are smarter, routes are numerous, things are more modular, and we are a lot more impatient... if its not going to plan .. someone gets a phone call and has to log on and get it going anyway they can ... back in the day, when it could be left, it was a more seamless thing ... The way that it works is still good today, but have so many more options now, and tend to have more people fixing everything more promptly now. Also the idea of each end passing session objects back and forth and not committing in between jobs, until both sides agree that they're done -- back in the day NFS did a lot of this for you ....

The analogy is somewhat similar to how the RS232 stuff worked ... electronics would do its thing and load their buffers and will get full and have to stop (or lose infomation), they could pass that stream of info (and empty their buffers and continue) when the CTS (Clear to send pin- as in metal pin on the plug) was high or low (what ever its supposed to be).