近两日出现断流现象(小的MTU？) #218

peakvision · 2016-10-10T18:20:01Z

11期间在ss-libev（服务器端监听443端口）基础上加了kcptun，放假期间一切正常，vps到拨号电信的电脑之间速度大概2mbyte/s到4mbyte/s。近两日出现一个问题，只要一段时间不使用（几分钟到十几分钟不等）就会断流，客户端有stream open/closed，服务器端没有，偶尔出现remote address或broken pipe。手机电信、联通移动网络正常，路由器重新拨号后电脑恢复。请问出现这种现象可能是什么原因？可否通过调整参数避免？

另外服务器端和客户端正常情况下stream open/close是否每次配对出现？

版本为161009，两端参数：
.\client_windows_amd64.exe --localaddr 127.0.0.1:8388 --remoteaddr VPS:554 --key PASSKEY --crypt aes --mode normal --conn 1 --autoexpire 0 --mtu 1350 --sndwnd 128 --rcvwnd 1024 --datashard 10 --parityshard 3 --dscp 0

/kcptun/server_linux_amd64 --listen 0.0.0.0:554 --target 127.0.0.1:443 --key PASSKEY --crypt aes --mode normal --mtu 1350 --sndwnd 1024 --rcvwnd 1024 --datashard 10 --parityshard 3 --dscp 0

cmdlot · 2016-10-11T02:01:49Z

我也遇到过有台服务器crush的情况，估计是进程没了，我也没去看进程，重启就行了

PterX · 2016-10-11T06:34:39Z

@peakvision 我最近也遇到这个情况，我的情况是被运营商Qos丢UDP包了。

现象为出现断流的时候用traceroute vps_ip，在地区运营商之后都是* 号。

katosun2 · 2016-10-11T09:22:47Z

我也遇到这个情况，加了kcptun就断流，自带的ss没问题

peakvision · 2016-10-11T12:24:48Z

@cmdlot 服务器端进程没问题，其他客户端还正常的。
@PterX traceroute ip和端口，可达。很可能于ISP有关系，但没有搞清楚是什么准则。试过4~6mbyte/s速率持续看youtube、下载接近1小时都没有问题，但要断的时候几百kbyte/s支持不了几分钟。
@katosun2 有时断（断之前速度正常），有时不断，不知道有没有办法在参数上避免。

peakvision · 2016-10-14T11:59:22Z

服务器端和客户端换成160922版后暂时未发现断流。

PterX · 2016-10-19T14:44:11Z

#137
根据作者的建议参数调优，目前已经没有被阻断了。建议大家看一下。

peakvision · 2016-10-19T15:29:50Z

更新一下，昨天发现160922版在同样参数下用了差不多2周也出现断流。
@PterX 请问你的环境和参数是？

PterX · 2016-10-19T18:33:57Z

@peakvision 参照那个第三个方案，微调一下。

katosun2 · 2016-10-20T02:35:16Z

将--mtu --sndwnd --rcvwnd 三个参数下调就没有出现断流了，用的是最新版1009

当前用的参数：-mtu 384 -sndwnd 192 -rcvwnd 900

peakvision · 2016-10-21T13:30:56Z

@katosun2 这组参数速度会不会比较慢？

katosun2 · 2016-10-21T23:07:09Z

@peakvision 这组参数只用在客户端上，服务端还是默认参数。实际使用中并没有觉得慢，主要还是浏览网页为主，所以基本能满足，这边的 ISP 对 UDP 封得特别厉害，发包一大就封。

使用上面参数测试，接近一周没断流：
环境：长城电信千兆 / 搬瓦工
下载：1-3m/s（感觉有2m/s+左右，查看网页并不会感觉到卡），油管2800-9000（3小时直播测试没断）
上传：没测

完整的客户端参数：-conn 2 -crypt aes-192 -nocomp -mode manual -mtu 192 -sndwnd 96 -rcvwnd 450 -nodelay 0 -resend 0 -nc 1 -interval 20 -autoexpire 1800

peakvision · 2016-10-22T01:14:41Z

@katosun2 非常感谢。我看到你的mtu设置得很小，可能会对客户端上传有影响。
请问你是单独调整kcptun参数还是先参考诸如iperf的udp测试再考虑参数范围的呢？

katosun2 · 2016-10-22T05:24:56Z

@peakvision 没有用工具测试调整，每次直接将参数半分。因为不知道 ISP 对 udp 量大的定义多少，用工具来细调太耗时间，毕竟断一次要30分-1小时，实在没这个耐心。

xtaci · 2016-10-24T03:01:17Z

确实很有趣的现象，我在电信网络把mtu调小为512后，整体速度明显变好。

neteroster · 2016-10-24T10:25:48Z

@xtaci

调了以后反而更慢

--mtu 1400 约 1.5MB/s
--mtu 512 约 700k/s

参数

sever

nohup ./server_linux_amd64 -l ":998" -t "127.0.0.1:999" -crypt "aes-128" -mode fast2 -mtu 512 -sndwnd 2048 -rcvwnd 256 &

client

nohup ./client_linux_amd64 -l ":1084" -r "x.x.x.x:998" -crypt "aes-128" -mode fast2 -mtu 512 -sndwnd 256 -rcvwnd 2048 -dscp 46 --conn 4 &

ISP: 中国电信 & 100Mbps

kmahyyg · 2016-10-24T15:10:33Z

根据你的网络调整参数
，我的服务器端

--rcvwnd 128 --sndwnd 128 --datashard 12 --parityshard 3 --mtu 1492

客户端wnd的两个参数均为96，其余一致

屌机ovz cn2线路广州出口vps
搬瓦工均如上配置，采用salsa20加密

本地isp: 云南昆明长宽20M 电信100M专线电信移动4G 都在用很稳定

个人觉得kcp协议特征应该是算比较明显的，建议作者考虑调整重发包或者添加类似ssr的混淆。

另，最近米国被大规模d的同时，近一个月南方大区的Chinanet骨干网节点均存在故障，昨晚尤为严重，或许跟这个有关。
昨晚走cn2直接断在了Chinanet，到广州cn2骨干的节点ping到了400+……

北方正常

kmahyyg · 2016-10-24T15:13:33Z

目前有传言ss原版协议已被gfw做出流量模型，一楼可以考虑更换为ssr观察这个现象是否存在。反正我从ss-libev换到ssr后快多了，估计是gfw的锅，应该跟mtu关系不大……

peakvision · 2016-10-24T22:08:08Z

@xtaci 据我理解，rcvwnd和sndwnd应该是控制kcp一次发送多少数据，而mtu控制具体要分多少个包发送。小mtu获得更高速度，是否意味这当前链路对每个udp包体积敏感，而小包可有效减低丢包？如果打印snmp，当前链路的retrans数比起mtu是否有明显降低？（很遗憾这段时间没有空详细测试。）

@kmahyyg 混淆流量后感觉会受到isp和vps供应商diffserv的buff/debuff，但是我不会玩破瓦酱同学的谜语，所以一直没有测试ssr；另外android也是一个原因。
此外对于我所在地区的南方电信而言，加州的HE线路基本上是最快的。我在晚上同一个时间直连linode fremont的测试文件（ http://speedtest.fremont.linode.com/100MB-fremont.bin ），速度差异也很大，从几十甚至几kbyte/s到几mbyte/s（有时甚至到达带宽上限）不等，所以我也没有太想去试试混淆成http/https流量。

kmahyyg · 2016-10-25T05:07:25Z

@peakvision 我觉得mtu不宜过低，而且本来udp就是二等公民。我这是ssr有正向buff，破娃匠的那些谜语有人解好发在zeronet/gfwtalk.bit上，可以直接伸手。我也是安卓……CM13，目前使用gitskarios客户端回复这条issue。

南方反正这两天163data和chinanet都很坑，官方目前有所回应，参见https://www.v2ex.com/t/315165

xtaci · 2016-10-25T05:21:39Z

嗯，确实这两天有点不稳定，原来骨干网出问题了。

baggiogogo · 2016-10-25T06:11:36Z

网络不出问题的话，kcptun相当稳定，现在参数一次性调好后就不动了，真到了明显感觉不对，基本都是线路去背这个锅。比调参数更加立竿见影的，还是切换不同出口的vps。
目前使用的撒手不管组合，联通光纤，洛杉矶C3，除了强迫症性质的服务端定时重启，剩下基本可以说稳定到忽视它的存在。

xtaci · 2016-10-25T09:40:09Z

@kmahyyg 可以试试FEC按照 dataShard:5 parityShard:5来配备

peakvision · 2016-10-25T11:31:36Z

v2ex帖子应该是波分传输故障，只会影响几个城市、片区，不会导致全国范围问题，跟出口也不应该受到影响。

@xtaci data=5, parity=5 (5/10) 可以理解成是50%丢包下的参数吗？

xtaci · 2016-10-25T12:17:52Z

可以，就是这个意思，这样可以充分降低延迟

xtaci · 2016-10-25T13:49:54Z

@peakvision #137 最下面有我对5:3 5:4 5:5的数据还原率对比。

kmahyyg · 2016-10-25T15:37:49Z

@baggiogogo C3是真实存在还是CN2的另一个说法？个人一直没弄懂

@xtaci 对于5:5网络下如何兼顾有效载荷与流量问题？毕竟手机流量伤不起啊……
#137 我看到了数据还原率有明显上升，目前我这的有效载荷比为1:1.3左右，配合ssr混淆……

baggiogogo · 2016-10-25T16:42:09Z

@kmahyyg
C3应该是个机房，线路应该没多大差别，换汤不换药。这个vps国内过去三线都是直连，不同场合适应性比较好，但不知是否其他在这个机房的机器也是三线直连。

xtaci · 2016-10-26T02:33:01Z

@kmahyyg @baggiogogo 没想到理论上的证明最大化，经验是FEC的有效还原率会降低重传。简单的思维游戏：

假如40%的丢包率（比较贴近实际情况）
如果不考虑FEC，那么s->c的PUSH丢包40%，c->s的ACK丢包40%，等于单次为 60% *60% = 36%的有效数据。
如果用FEC 5:5, 那么s->c的PUSH能在40%丢包率下全部还原，等于单次为 50%的有效数据。
情况2还需要考虑重传的过程中继续的64%丢包。总重复率是
0.64 ^2 + 0.64^4 + 0.64 ^8 ... 0.64^m , m -> ∞

kmahyyg · 2016-10-26T05:00:57Z

根据你的readme内的公式和实际测速，用上面我贴出来的配置，我做了下计算，刚好实际达到配置参数理论最大值，减小mtu在当前骨干网异常，高延迟高丢包情况下的确在理论和实际上可以提高传输速度，不过一旦骨干网修复，低mtu只会拖慢速度……

xtaci · 2016-10-26T05:09:40Z

是的

amulo05 · 2016-10-26T09:01:51Z

看了各位的讨论，果然调mtu有用
我这里kcptun在家一切正常，在公司时好时坏，在不修改其他参数的情况下，只降低了客户端的mtu from 1400 to 512 ，就一切正常了~
此外，感觉响应速度也变快了

peakvision · 2016-10-26T11:43:13Z

@amulo05 请问你客户端sndwnd和rcvwnd设置在多少？

如果协议没有协商mtu/mss机制，服务器端也修改对应mtu比较好。

amulo05 · 2016-10-27T05:54:33Z

@peakvision 我家里是电信百兆宽带设置的是256/2048 ，晚上8点 y2b速度一般8K1W2左右，有时候也能稳定到1W5+
但是公司给每人分配的带宽比较低，平时下载速度也就400K500K，所以我设置的比较低 128/128，y2b速度在1500~2000 左右
服务端的mtu我回头试试，谢谢提醒

peakvision · 2016-10-29T10:25:20Z

说了那么久mtu，有没有人讨论一下tc呢？

cjjdaq · 2016-11-22T12:22:21Z

最近断流特别严重，闲置一段时间后或者用着用着突然服务端就broken pipe了，然后就无法翻墙了，改小mtu也是如此，被折腾的快疯了

peakvision · 2016-11-22T13:12:57Z

哪家的vps和什么isp？

On Nov 22, 2016 20:22, "cjjdaq" notifications@github.com wrote:

最近断流特别严重，闲置一段时间后或者用着用着突然服务端就broken pipe了，然后就无法翻墙了，改小mtu也是如此，被折腾的快疯了

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

cjjdaq · 2016-11-22T13:32:06Z

@peakvision vultr 中国电信，已经断流的特别严重了基本上已经无法正常使用了，限制个十分八分钟的，稳断，换端口两端重启都没有用，只能等一段时间。

peakvision · 2016-11-22T14:20:40Z

客户端rcvwnd多少？

On Nov 22, 2016 21:40, "cjjdaq" notifications@github.com wrote:

@peakvision https://github.com/peakvision vultr 中国电信，已经断流的特别严重了

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#218 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/APm3Y93dmArDmiwiF0JFoRyMcsj9VtK4ks5rAu7agaJpZM4KS2O9
.

cjjdaq · 2016-11-23T02:39:53Z

1024

peakvision · 2016-11-23T02:49:41Z

mtu多少？设到500左右看看有无改善。l另外设置一下设置dscp。对于ss-android设置--autoexpire，作者建议10或者以下。

On Nov 23, 2016 10:39, "cjjdaq" notifications@github.com wrote:

1024

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#218 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/APm3Y6w4-BHZ3cV2WcYDLiTp1oSATISjks5rA6d9gaJpZM4KS2O9
.

cjjdaq · 2016-11-23T17:03:29Z

设置500也没用，最有效的办法是换服务器ip，然后能稳定用一下段时间，然后开始不间断的断

luoganzhi · 2017-06-05T13:30:38Z

现在开始就断了，调多小都没用

xtaci changed the title ~~近两日出现断流现象~~ 近两日出现断流现象(小的MTU？) Oct 24, 2016

xtaci added ISP MTU labels Oct 24, 2016

This was referenced Oct 24, 2016

手动参数设定探讨 #137

Closed

Kcp用着用着偶尔就会断开{伪解决方案} #228

Closed

xtaci closed this as completed Jan 13, 2017

近两日出现断流现象(小的MTU？) #218

近两日出现断流现象(小的MTU？) #218

Comments

peakvision commented Oct 10, 2016

cmdlot commented Oct 11, 2016

PterX commented Oct 11, 2016

katosun2 commented Oct 11, 2016

peakvision commented Oct 11, 2016

peakvision commented Oct 14, 2016

PterX commented Oct 19, 2016

peakvision commented Oct 19, 2016

PterX commented Oct 19, 2016

katosun2 commented Oct 20, 2016

peakvision commented Oct 21, 2016

katosun2 commented Oct 21, 2016

peakvision commented Oct 22, 2016

katosun2 commented Oct 22, 2016

xtaci commented Oct 24, 2016

neteroster commented Oct 24, 2016 • edited Loading

kmahyyg commented Oct 24, 2016

kmahyyg commented Oct 24, 2016

peakvision commented Oct 24, 2016 • edited Loading

kmahyyg commented Oct 25, 2016

xtaci commented Oct 25, 2016

baggiogogo commented Oct 25, 2016

xtaci commented Oct 25, 2016

peakvision commented Oct 25, 2016

xtaci commented Oct 25, 2016

xtaci commented Oct 25, 2016

kmahyyg commented Oct 25, 2016

baggiogogo commented Oct 25, 2016

xtaci commented Oct 26, 2016

kmahyyg commented Oct 26, 2016

xtaci commented Oct 26, 2016

amulo05 commented Oct 26, 2016 • edited Loading

peakvision commented Oct 26, 2016 • edited Loading

amulo05 commented Oct 27, 2016 • edited Loading

peakvision commented Oct 29, 2016

cjjdaq commented Nov 22, 2016

peakvision commented Nov 22, 2016

cjjdaq commented Nov 22, 2016 • edited Loading

peakvision commented Nov 22, 2016

cjjdaq commented Nov 23, 2016

peakvision commented Nov 23, 2016

cjjdaq commented Nov 23, 2016

luoganzhi commented Jun 5, 2017

neteroster commented Oct 24, 2016 •

edited

Loading

peakvision commented Oct 24, 2016 •

edited

Loading

amulo05 commented Oct 26, 2016 •

edited

Loading

peakvision commented Oct 26, 2016 •

edited

Loading

amulo05 commented Oct 27, 2016 •

edited

Loading

cjjdaq commented Nov 22, 2016 •

edited

Loading