前一篇《存储课堂:NAS存储系统性能优化攻略(一)》发布后，一位读者对smb和smb2的不同工作方式很感兴趣。为了检验“叫外卖”(如果对这个词感到困惑，请参考前一篇)的方式能提高多少效率，他在NAS和作为客户端的Windows 7上都启用了smb2，果然看到读写性能大幅度提升。

熟悉网络的读者可能会存疑：在局域网里的往返时间(RTT)很短，读写的总时间其实大多消费在服务器的响应上。smb2的改进看起来只节省了RTT，可能达到大幅度提升(比如数倍)的效果吗?这个质疑完全正确，但这位读者的实验结果也是真实的。怎么解释这个矛盾呢?答案就在TCP协议上。本文将详解TCP中影响NAS性能的各个因素，包括对以上矛盾的解释。

在逐条分析之前，先让我们复习一下TCP的重传机制，因为后面会多次谈及它。当有TCP包在网络上丢失时，TCP有两种机制来实现重传：超时重传和快速重传。下图展示了这两种情况：

图1, 发送方只给接收方传送了一个包。不幸的是这个包在网络上丢失了，所以发送方迟迟等不到来自接收方的确认。在经过一段时间(RTO)之后，发送方认为该包已经丢失了，所以重新传了一次。这个机制就是超时重传。RTO能达到数百毫秒，这在计算机世界可以算“浪费很长时间”了，NAS对一个读写请求的响应也就几个毫秒。除此之外，超时重传还会使TCP发送窗口降到最小，更是雪上加霜。如果网络中有超过0.1%的超时重传，我们就能看到明显的性能问题。减少超时重传对提高性能有明显的改善。

图2，发送方要给接收方传送5个包，不幸的是第一个就丢失了。由于这个发送窗口>=5个MTU，所以发送方在没有接收方确认的情况下继续发送了四个包。接收方在收到这些包的时候，可以通过包号知道第一个包丢失了。所以收到第n个时 (n=2,3,4,5)，接收方就发一个“收到n，但1还没收到呢”给发送方(如下图的红线所示)。发送方在收到四个“但是1还没收到呢”的消息后，意识到1可能已经丢失了，就赶紧重传一个。这个机制称为快速重传。由于这个过程没有等待时间，所以对性能影响较小。实现超时重传的条件是发送方在丢了一个包后，接下来还有4个或以上包可以传。