软件开发: 12 2009存档

      linux下的tc可以操纵网络，比如分配带宽给不同的应用、模拟网络时延、模拟糟糕网络环境下的丢包等。

      但在实际使用模拟丢包时，我们 发现了问题：两台服务器，一台跑tcp的server，一台跑tcp的client，client只send，server只recv（并打印出来），在 网络环境正常时，发送100万条消息只要40秒，但如果我们在两台服务器的任一台设上 " tc qdisc add dev eth0 root netem loss 1% " （在eth0设上1%的丢包率），消息的收发就戛然而止，strace发现时client阻塞在sendto上了（并没有发生我们送想象的“重传”机 制），把丢包率改回来（即恢复成正常网络），程序还是阻塞在sendto上。我们程序没写好？仔细检查，程序没问题（代码），而且我们发现，scp也会受同样的影响，表现和我们自己写的程序一样。难道tcp不可靠？

      结果发现时tc的用法不对。tc不是这样用的。中间需要用一个路由器。

      于是我们拿一台linux机当router，单网卡，两个虚拟ip，让它连接两台服务器再试。更滑稽了，tc不起作用，两台服务器间的流量刷刷的走，tc却显示没有多少packet经过。tc不能用于router吗？
后来看了tc的详细手册（注意4.1节），终于知道了：tc标准用法是两台服务器中间一个双网卡的router，在router上用tc。

       最后测试成功。丢包率越高，tcp传输的速度越慢；如果丢包率很高，tcp可能会顿住，但是只要改回去（去掉tc的netem配置），传输就会恢复。
       TCP很可靠。

代码如下：

void accept()
{
   ....
   Connection* client = new Connection();
}

gcc编译时报了 warning，说client变量没有用到，于是我把这一行删了，结果程序错误。后来才发现Connection构造函数是做了事情的，这样直接删不对。正确的改法是直接改为：
new Connection();

看来修复编译器的warning也得留神。