Why does NFS use UDP by default?

Question

I'm sure there's some ancient legacy reason for it, but what is it? It seems like a service that's geared towards reliable data delivery.

Answer 1

• 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.

Answer 2

UDP is used when the protocol is going to be managed by the application itself. The app may have a better idea for how to do it, or it may be faster (under the special conditions of the application). TCP is very nice but has a lot of overhead associated with it.

Answer 3

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.

Answer 4

The stateless UDP connection minimizes network traffic, as the NFS server sends the client a cookie after the client is authorized to access the shared volume. This cookie is a random value stored on the server's side and is passed along with RPC requests from the client.

Answer 5

UDP was also used because it could greatly reduce the memory usage. In the 1980s when NFS was originally developed, you'd have a UNIX system with like 4-8MB of RAM, and (at least in academic environment) the "server" may have simply been one of these 4-8MB systems with a few extra disks hooked up to it. RAM use on the server was a big concern, you could have lost several MBs to TCP buffers that my have been better used as disk cache. It also made it easy to handle memory pressure, an overtaxed NFS server could simply drop requests.

Answer 6

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).