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.
相关问题
- IPAddress.[Try]Parse parses 192.168 to 192.0.0.168
- Why should we check WIFEXITED after wait in order
- What would prevent code running in a Docker contai
- UNIX Bash - Removing double quotes from specific s
- How to run tcp and udp on a single port at same ti
相关文章
- 为什么nfs在不同版本的Linux下安装的文件都不一样
- RMI Threads prevent JVM from exiting after main()
- Making new files automatically executable?
- Reverse four length of letters with sed in unix
- fsc.exe is very slow because it tries to access cr
- Extracting columns from text file using Perl one-l
- Problem with piping commands in C
- MountVolume.SetUp failed for volume “nfs” : mount
Performance. UDP has a much lower overhead than TCP. On the other hand NFS has to handle reliable transport on its own then (compared to TCP) but as this is a protocol for LANs where connection problems and package drops are (or better: should be) not a problem, it's optimized for performance.
My guess is that it's probably for legacy (historical) reasons. Originally NFS was probably used on low latency networks where there was very little possibility of error, so the overhead of initiating the 3-way handshake to set up the TCP connection (together with the bi-directional acknowledgement of all messages) outweighed the simplicity of using a connectionless protocol like UDP.
When UDP is used as a transport protocol, presumably it would be up to the NFS client to manage retransmissions if necessary.