我访问一个ssh命令行打字延时500ms丢包20%，实在受不了弄了一个iptables规则来重复发包：
iptables -t mangle -A OUTPUT -p tcp --dport 22 -j TEE --gateway 192.168.1.1
后来一看net_speeder功能完全一样。
对有所有流量无差别重复发包会毁掉别人的拥塞控制，对自己的带宽也是低效利用。Google精心设计QUIC协议，使用FEC前向纠错码，也只是对很少几个关键包提前重发（Proactive speculative retransmission）。
冗余传输的确是一种纠错方式，只是看怎么用它。对极少量互动性的流量（ssh打字）控制流量（TCP的SYN）利用冗余传输是合理的，对数据流量使用就是不公平的。iptables可以精细控制这个选择。
 |
1
jedihy Mar 4, 2015
其实对拥塞控制影响不大接近于窗口X2，丢包后还是会收敛，主要是浪费了带宽。
|
 |
2
ryd994 Mar 4, 2015 via Android
@jedihy 影响很大
别人丢一个包就收敛，你要丢两个，还必须是同一对的两个。这样出现拥塞的时候，别人注意到大量丢包了，于是开始压速度，你发现不了，以为丢包不严重，还一个劲的发。快到是快了，无非劣币驱逐良币，等到大家都用的时候就大家一起没得用。拥塞控制就是为了最大化利用带宽。 |
 |
3
LazyZhu Mar 4, 2015
"TEE" or "TZSP"
https://code.google.com/p/port-mirroring/ |
 |
5
muzimin Mar 4, 2015
建议补包还是添加一个小延迟。当遇到网络拥塞后，瓶颈处会出现集体拥塞控制，紧接着出现一个不拥塞空挡，这个时候补发包，成功率会很高。对于跨洋访问只需要延迟个几十个毫秒，原包和clone包就会强烈互补效应。
对于高延迟、高丢包、网络连接不稳定环境下进行服务器操作，推荐使用Mosh。对于命令敲入，采用异步UDP方式，本地先无阻塞显示输出，真正实际输出回传覆盖的方式。除此还有多个针对ssh短板特征， https://mosh.mit.edu/ 视频介绍 |
 |
7
yantze Mar 4, 2015 via iPhone
@muzimin mosh在digitalocean上的centos7试过，用putty连上mosh后，响应慢，并且mosh-server在网络不好的时候，不响应mosh-client的请求。在当前环境下不好用，其它环境未知。
|
 |
8
mackyzhan Mar 4, 2015 via Android
mark，有空试试效果，感觉对付卑鄙的墙效果应该不错。
|
 |
9
linkupmylife Feb 3, 2016
试过了，出现 DUP ACK ， Window 下降，反而更慢了。
|
Select Language