我访问一个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可以精细控制这个选择。

其实对拥塞控制影响不大接近于窗口X2，丢包后还是会收敛，主要是浪费了带宽。

影响很大
别人丢一个包就收敛，你要丢两个，还必须是同一对的两个。这样出现拥塞的时候，别人注意到大量丢包了，于是开始压速度，你发现不了，以为丢包不严重，还一个劲的发。快到是快了，无非劣币驱逐良币，等到大家都用的时候就大家一起没得用。拥塞控制就是为了最大化利用带宽。

"TEE" or "TZSP"
https://code.google.com/p/port-mirroring/

tzsp是再打包的，不能用于这个用途，否则你还要又有个端点给你解包

建议补包还是添加一个小延迟。当遇到网络拥塞后，瓶颈处会出现集体拥塞控制，紧接着出现一个不拥塞空挡，这个时候补发包，成功率会很高。对于跨洋访问只需要延迟个几十个毫秒，原包和clone包就会强烈互补效应。
对于高延迟、高丢包、网络连接不稳定环境下进行服务器操作，推荐使用Mosh。对于命令敲入，采用异步UDP方式，本地先无阻塞显示输出，真正实际输出回传覆盖的方式。除此还有多个针对ssh短板特征，
https://mosh.mit.edu/
视频介绍