初涉tcp基础一例

昨天很多同学抱怨说ftp的下载速度慢得要死。ssh进入服务器看了看
ifconfig
发现eth0的txqueuelen是10，其它几个界面都是1000. 某只告诉我，eth0的那个网络接口被学校给搞了，只能等下周去找那帮混蛋

今天起床之后搜索了一下txqueuelen，发现它是可以用
ifconfig eth0 txqueuelen 1000
进行设置的。但是改成1000之后，RTT变成了800ms左右（之前txqueuelen是10的时候RTT是150ms左右）。又尝试了几个不同数量级的txqueuelen值，发现这个值越大，RTT越大，感觉上的网络延迟也越大。但是txqueuelen又无法再继续小下去了，也就是说RTT最小就只能是150ms左右了。
于是，目前的情况看起来是这样：RTT不知道为什么变得十分大，系统自己为了减小RTT而把txqueuelen往小里调了。如果假设系统还没有自动调整的话，RTT可能已经800ms，比起平时的2ms增大了400倍。

那么RTT是如何影响带宽的呢？
根据这篇文章的介绍，我查看了服务器的相应参数
rmem_max=131071
wmem_max=131071
tcp_rmem=4096 87380 4194304
tcp_wmem=4096 16384 4194304
上面这些参数算下来神奇的跟提到的这篇文章中的计算参数十分吻合，算下来接收传输速度是400kbytes/s。而该服务器发起的传输速度为82kbytes/s，对于局域网的ftp，在10kB/s左右，几乎是不可忍受的. 更何况即使是这样高的RTT也是在系统自动调整之后达到的，如果其它参数保持不变，RTT可能会达到800ms，传输速度就只有不到2kB了。

然后就是处理的问题？应该人为的把tcp_rmem和tcp_wmem设定得大一点，还是应该把RTT降低呢？
除了前面提到的那篇文章外，这篇文章也指出，linux内核从2.6.17开始，就支持了自动调整tcp参数以达到最佳。查看了一下/proc/sys/net/ipv4/tcp_moderate_rcvbuf，确实是1，也就是说确实开启了自动调整。那么目前的状态，包括tcp_rmem、tcp_wmem和txqueuelen甚至是RTT，应该都是自动调整后系统认为的最佳状态，而其中系统自动调整作用不大的，应该只有RTT，因为照我的理解，RTT是一个数据交换过程的时间，某一端的处理不会对已经很大的RTT有太大的改善。此外，还可以推断，RTT明显增大是系统进行这一系列自动调节的原因之一。
那就来看一下调整RTT的收益：如果RTT能够恢复原来的2ms左右，那么传输速度可以加快70~80倍，也就是达到6400kbyte/s。另外，此时系统可能会自动对tcp_rmem、tcp_wmem和txqueuelen等参数再次进行微调，实际收益可能不止于此（当然只是我的推测）。不过现在我是没有办法调整RTT了，等下周如果那帮人发善心把RTT恢复到以前的状态，再来核对一下前面的那些参数会发生怎样的变化，再来算算实际传输速度吧