This commit implements a new TCP congestion control algorithm: BBR (Bottleneck Bandwidth and RTT)
有兴趣的可以试试。
1
shinko 2016-10-18 02:52:10 +08:00
This is not an official Google product.
|
4
laincat 2016-10-18 08:45:56 +08:00
这个好像很厉害。。。
|
5
cxlxkin 2016-10-18 08:47:28 +08:00
google 也来单边加速插一脚?感谢楼主让我获得这个消息
|
6
GPU 2016-10-18 08:53:09 +08:00
Google 员工闲得蛋疼弄出来的?
|
7
kfll 2016-10-18 10:18:05 +08:00
|
9
est 2016-10-18 11:59:34 +08:00
我告诉你们一个比 zetatcp, finalspeed, kuntcp, spdy 快 n 倍的东西: UDP 。
|
12
ldbC5uTBj11yaeh5 2016-10-18 12:28:28 +08:00
|
14
redsonic 2016-10-18 15:18:58 +08:00
不管什么样的叉子都无法解决蛋糕太少的问题, 只会使一部分人先吃到蛋糕而已。
|
15
zander OP |
16
zander OP https://github.com/iMeiji/shadowsocks_install/wiki/开启 TCP-BBR 拥塞控制算法 /
|
20
srrshweee 2016-12-15 21:24:11 +08:00
额。。。我在 ramnode 和 indovirtue 的 vps 上面都测试了,不如速锐。甚至不如默认的算法
|
22
liwei 2016-12-19 14:43:00 +08:00 1
@est 我试了一下直接改 IP 头 protocol number 的方法,在我这里是不行的,貌似会被运营商的转发设备丢弃,因此只好使用在 UDP 头前面加上一个 fake TCP 头的方法(并且 TCP 头部里面的一些 flags 需要合适,例如带 SYN 标志的都可以转发,而单独的 RST 标志的数据包会被丢弃),想请教一下您是如何实现的?
|
24
est 2016-12-19 16:24:09 +08:00
@liwei
你确认你『单独的 rst 』 是合法的 tcp 么?我感觉可能是你的 tcp 可能没拼对。怎么生成的?建议试试把一个正常的 rst 改个 seq num 和端口再发一下试试能不能收到。如果是 nat 则不能改端口。要打洞。 |
25
liwei 2016-12-19 16:31:27 +08:00 via Android
@est 不增加 fake tcp 头部的时候修改 protocol number 是通过 tc-pedit 实现的,增加 fake tcp 头的时候是用 sendip 发送的数据包,单独的 rst 会丢包,但是如果先发送一个 syn ,在极短的一段时间内后续发送的 rst 能够接收到。
我对运营商网络里面的设备不熟悉,所以暂时也搞不清楚原因,感谢你的指点。 |
29
linhua 2017-01-18 00:34:08 +08:00 1
@est @liwei
好巧,实现了一个类似的,不过还有 bug https://github.com/linhua55/some_kcptun_tools/tree/master/relayRawSocket |