本文作者Michael Morris在网络架构上具有长期经验。

       最近几周的工作非常有趣。这几周，我们一直在解决昂贵的富士通M8000服务器和网络存储在万兆网吞吐性能上的问题。M8000通过TCP上的NFS访问存储。最后，我们才发现这不是网络问题。作为网络工程师，我们都见过这种情况：只要性能出现问题，就会有人说"这肯定是网络的问题"。这需要一段时间去伪存真，先破除这一网络上的错误观点，再将重点放在服务器驱动程序和补丁上面。

       应用团队经常会对他们无法从单纯的万兆网络中获得应得利益而感到吃惊。"哥们，这可是万兆网络，会有什么问题？"

       我们来快速的回顾一下相关知识，TCP是一项数据交换的工作。服务器发送一定量数据（数据量取决于网络参数），然后服务器等待客户端应答。如果服务器和客户端的网络延迟大（比如从美国通过广域网传输到印度），那么应答时间就会很长。这会拖慢数据传输的持续吞吐量。尽管很多人其实不知道这一理论，不过在天生的理解力下他们都会给出"这些数据必须要漂洋过海"的解释。好的，这已经和正确答案相差不远了。

       在10GbE数据中心中，并不是所有的连接都是内置的。对网络不是很了解的人常常会说，"这可是万兆，它应该以10Gbps传输。而且数据中心里也没有什么海，只是一些配线板和交换机。"这也导致了人们心中会有一个简单的外推法，只要出现缓慢的情况，那么必然是"网络中的问题"，因为基础设施都是在同一机架内的。

       不幸的是，数据中心网络的TCP，延迟和网络参数同广域网有着一样的特性。而且，当你花了10GbE的钱却没享受到10Gbps的吞吐量的时候你就自然会开始抱怨。

       因此，让我们假设你有一个万兆以太网网卡服务器，一个经过了3跳数（hops）的10GbE网络，以及另一台拥有万兆以太网网卡的服务器。应用通过TCP使用NFS协议出书数据，TCP设置为默认：

       带宽 = 10Gbps

       TCP Windows Size = 64K（65,536）

       MTU = 1500

       延迟= 1.00毫秒RTT

       将这些数值输入TCP计算器的话，我们看到结果是很差的525Mbps（是"M"，而不是"G"）。从系统管理员的角度来看："我把价值数百万美元的服务器放在了10GbE网络中，但是我得到的性能还不及千兆，你这网络可真烂。"可是实际上，网络根本就没有发挥TCP的全部。

       那么，我们该怎样获得性能提升？

       首先，如果你可以购买一些更好的网卡和交换机，那么你可以将延迟减少到0.3毫秒（300微秒）。这样的话吞吐量就可以扩充三倍到1.7 Gbps。这显然好多了，但是我们仍然只用到了网络的17％。接下来，让我们来更改TCP网络参数，将其改成262K。在3ms和262K网络参数的情况下，吞吐量迅疾飙升到6.99Gbps！看，这就是我们所谈到的。

       最后，让我们将目标转移到在0.3毫秒RTT延迟下TCP网络参数究竟应该设定到多少的问题上。375K是比较合适的一个值。这对于数据中心企业级系统非常实际。

       此外，我还是要为这些计算做一下注脚。这些都是理论上的东西。这当然要比"网络应该在10Gbps下运行"的传统理论要好，不过其仍然只是理论。不同的环境，数据包丢失，错误，排队延迟等等，都将影响数据中心两个主机之间的实际吞吐速度。此外，这篇文章是基于上面提到的那个TCP计算器来写的。其似乎是正确的，但它可能不是很准确。我在六年前写了一个比较值得信赖的Excel电子表格，而这个表格算出的优化后的结果是4.2 Gbps，而不是6.99 Gbps。

       不过这无伤大雅，我们的主题没有偏离。如果没有数据中心端到端监控和系统团队的调优，你可能永远不会实现10GbE网络的投资。所以这才是真正的网络工程！