我访问一个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 2015-03-04 00:15:20 +08:00
其实对拥塞控制影响不大接近于窗口X2,丢包后还是会收敛,主要是浪费了带宽。
|
2
ryd994 2015-03-04 00:27:59 +08:00 via Android
@jedihy 影响很大
别人丢一个包就收敛,你要丢两个,还必须是同一对的两个。这样出现拥塞的时候,别人注意到大量丢包了,于是开始压速度,你发现不了,以为丢包不严重,还一个劲的发。快到是快了,无非劣币驱逐良币,等到大家都用的时候就大家一起没得用。拥塞控制就是为了最大化利用带宽。 |
3
LazyZhu 2015-03-04 00:46:47 +08:00
"TEE" or "TZSP"
https://code.google.com/p/port-mirroring/ |
5
muzimin 2015-03-04 14:04:47 +08:00
建议补包还是添加一个小延迟。当遇到网络拥塞后,瓶颈处会出现集体拥塞控制,紧接着出现一个不拥塞空挡,这个时候补发包,成功率会很高。对于跨洋访问只需要延迟个几十个毫秒,原包和clone包就会强烈互补效应。
对于高延迟、高丢包、网络连接不稳定环境下进行服务器操作,推荐使用Mosh。对于命令敲入,采用异步UDP方式,本地先无阻塞显示输出,真正实际输出回传覆盖的方式。除此还有多个针对ssh短板特征, https://mosh.mit.edu/ 视频介绍 |
7
yantze 2015-03-04 21:26:57 +08:00 via iPhone
@muzimin mosh在digitalocean上的centos7试过,用putty连上mosh后,响应慢,并且mosh-server在网络不好的时候,不响应mosh-client的请求。在当前环境下不好用,其它环境未知。
|
8
mackyzhan 2015-03-04 23:16:43 +08:00 via Android
mark,有空试试效果,感觉对付卑鄙的墙效果应该不错。
|
9
linkupmylife 2016-02-03 11:22:04 +08:00
试过了,出现 DUP ACK , Window 下降,反而更慢了。
|