NFS为何在v4版本将标准传输协议从UDP切换为TCP

早期NFSv3及之前版本选择UDP的核心逻辑 #

• 硬件与性能权衡：NFS在80-90年代设计迭代到v3时，主流局域网带宽仅10Mbps，服务器、客户端的CPU性能也十分有限。UDP没有三次握手开销、不需要内核维护连接状态、协议头开销远低于TCP，在低丢包、低延迟的同机房局域网场景下，RPC请求的处理时延、CPU占用都显著优于TCP，更适配当时的硬件条件。
• 匹配无状态协议设计：v3及更早的NFS是完全无状态设计，服务端不记录任何客户端的会话、操作上下文，每个独立请求都携带全量操作参数，本身不需要TCP的连接绑定、有序传输特性。UDP无连接的特性刚好匹配这一设计：请求丢包时由NFS上层逻辑自行做超时重传，早期客户端实现的重传粒度甚至比当时TCP默认的重传策略更适配文件操作场景。
• 适配当时的网络设备能力：早年企业级网络设备的TCP连接表容量非常小，若大量客户端同时和NFS服务端建立TCP长连接，很容易打满设备连接表导致全网断网，UDP无连接的特性完全不存在这个问题，部署门槛更低。

NFSv4切换TCP为标准传输的驱动因素 #

• 网络部署场景的变化：NFSv4在2000年前后定稿时，跨公网、跨安全域的远程文件挂载需求已经开始普及，不再局限于同机房局域网部署。UDP本身没有内置拥塞控制，在高丢包、高延迟的广域网环境下，不仅传输效率极低，还可能因为无节制发包加剧网络拥塞；而TCP自带的拥塞控制、丢包快速重传、乱序重组能力，在广域网场景下的传输效率远高于上层自行实现可靠性的UDP，同时期千兆局域网、主机CPU性能的普及，也让TCP的额外开销变得可以忽略。
• 协议架构的本质变更：和v3的无状态设计不同，NFSv4引入了强一致文件锁、操作委托、持久会话、权限缓存等一系列有状态特性，需要稳定、有序、可靠的传输层语义来绑定客户端与服务端的状态映射。UDP无连接、可能乱序丢包的特性会让上层状态处理的逻辑复杂度飙升，直接基于TCP实现可以把传输层的可靠性问题下沉，大幅降低协议本身的设计和实现复杂度。
• 安全与部署便利性的需求：NFSv4将原本分散在portmap、mountd、nlm等多个独立端口的服务全部收敛到2049单端口，TCP单端口的模式非常方便防火墙配置访问控制规则；而UDP的无状态特性让防火墙很难做细粒度的连接级访问管控，跨安全域部署的障碍极高。
• TCP性能优化的成熟：到NFSv4设计阶段，TCP的滑动窗口优化、网卡TSO/GSO卸载、长连接复用等特性已经在主流操作系统中全面落地，哪怕是在局域网场景下，TCP实现的NFS性能也已经追平甚至超过UDP实现，UDP原本的性能优势已经完全消失。

补充说明：NFSv3后期的不少实现也增加了TCP传输支持，但RFC标准始终将UDP作为必须兼容的默认传输；NFSv4的合规要求明确将TCP作为强制支持的标准传输，UDP变为可选扩展，绝大多数生产环境的NFSv4部署都默认使用TCP。

内容的提问来源于stack exchange，提问作者hmars