broken pipe的原因可能有哪些，这样大家都可以尽量避免

[iaston]

tail -f /var/log/kcptun/server.log

2019/04/12 23:14:08 remote address: 223.xx.xx.xx:16127 2019/04/12 23:14:15 broken pipe 2019/04/12 23:14:15 broken pipe 2019/04/12 23:14:24 broken pipe 2019/04/12 23:14:24 broken pipe 2019/04/12 23:14:25 broken pipe 2019/04/12 23:14:38 broken pipe 2019/04/12 23:14:58 remote address: 223.xx.xx.xx:16293 2019/04/12 23:15:05 remote address: 223.xx.xx.xx:16316 2019/04/12 23:15:13 remote address: 223.xx.xx.xx:16329 2019/04/12 23:15:22 remote address: 223.xx.xx.xx:16355 2019/04/12 23:15:25 remote address: 223.xx.xx.xx:16360 2019/04/12 23:15:27 remote address: 223.xx.xx.xx:16367 2019/04/12 23:15:28 broken pipe 2019/04/12 23:15:35 remote address: 223.xx.xx.xx:16381 2019/04/12 23:15:35 broken pipe 2019/04/12 23:15:38 remote address: 223.xx.xx.xx:15363 2019/04/12 23:15:38 broken pipe 2019/04/12 23:15:43 broken pipe 2019/04/12 23:15:52 broken pipe 2019/04/12 23:15:57 broken pipe 2019/04/12 23:16:05 broken pipe 2019/04/12 23:16:35 remote address: 223.xx.xx.xx:15551 2019/04/12 23:16:54 remote address: 223.xx.xx.xx:15653 2019/04/12 23:17:09 remote address: 223.xx.xx.xx:15751 2019/04/12 23:17:17 remote address: 223.xx.xx.xx:15812 2019/04/12 23:17:24 broken pipe 2019/04/12 23:17:25 broken pipe 2019/04/12 23:17:30 broken pipe 2019/04/12 23:17:37 remote address: 223.xx.xx.xx:16096 2019/04/12 23:17:39 broken pipe 2019/04/12 23:17:42 remote address: 223.xx.xx.xx:16009 2019/04/12 23:17:47 broken pipe 2019/04/12 23:18:07 broken pipe

出现broken pipe后，感觉就象是被服务器reset了连接一样，页面中的某些元素就打不开了（例如图片就加载失败）。 客户端（win10 移动宽带200M）： "client_windows_amd64.exe" -l 127.0.0.1:9527 -r 192.xx.xx.xx:21 -key "xxxxx" -crypt salsa20 -nocomp -datashard 5 -parityshard 5 -mtu 1350 -sndwnd 512 -rcvwnd 1024 -mode fast3

服务器端（centos7，墙外，1Gbps)： { "listen": ":21", "target": "127.0.0.1:23", "key": " xxxxx", "crypt": "salsa20", "mode": "fast3", "mtu": 1350, "sndwnd": 1024, "rcvwnd": 512, "datashard": 5, "parityshard": 5, "nocomp": true, "quiet": true, "pprof": false }

在油管看视频一卡一卡的，实测速度还不如直接用SS。显然，很可能是因为我的参数设置问题，"broken pipe“应该只是个悲伤的结果。

所以，请教一下，有哪些可能会导致”broken pipe“（当然，QOS也是可能的原因，但这个我们不可控，所以我已经是在凌晨或深夜做的测试，测试前至少4小时内没开Kcpdun等大流量UDP应用。）

[xtaci]

光猫是否开启了防火墙，限制了UDP?

[iaston]

没有开防火墙，我在几个宽带上都是这样（办公室、我家、朋友家），包括用移动手机、电信手机的4G网络。我想是不是因为参数设置上的问题，导致在比较恶劣的网络环境下，大量的被丢包导致的连接中断？如果是这样，有什么办法可以缓解这种情况吗？或者，有没有其它的可能性也会导致”broken pipe“，也请提示一下，我再检查排除一下。

[xtaci]

参数不会引起broken pipe的问题，只要保证必须一致的参数一致即可（FEC) 可能是区域性ISP对udp的控制问题，你可以试试udp2raw这个看看有没有改善。

[iaston]

参数不会引起broken pipe的问题，只要保证必须一致的参数一致即可（FEC)

明白了，这句话是关键，谢谢👍

[xtaci]

另外你可以考虑下端口，不同端口的断流情况有较大差异

[imcotton]

@xtaci getting lots of broken pipe after version v20190104, need to keeping rollback to this one, configs / envs stay the same for years unchanged, any possible guessing?

[xtaci]

我没有发现有这个差异啊，是不是其他原因导致的，例如DNS问题， 我0104到现在优化了非常多，会更好才对

[xtaci]

另外如果设定了autoexpire，是一定会在这个间隔时间出现broken pipe的

[imcotton]

autoexpire and scavengettl left as default, checkout logs below:

2019/04/17 10:30:21 version: 20190416
2019/04/17 10:30:21 initiating key derivation
2019/04/17 10:30:21 listening on: [::]:61000
2019/04/17 10:30:21 encryption: xor
2019/04/17 10:30:21 nodelay parameters: 1 10 2 1
2019/04/17 10:30:21 remote address: x.x.x.x:31000
2019/04/17 10:30:21 sndwnd: 768 rcvwnd: 2048
2019/04/17 10:30:21 compression: true
2019/04/17 10:30:21 mtu: 1350
2019/04/17 10:30:21 datashard: 10 parityshard: 3
2019/04/17 10:30:21 acknodelay: false
2019/04/17 10:30:21 dscp: 0
2019/04/17 10:30:21 sockbuf: 4194304
2019/04/17 10:30:21 smuxbuf: 4194304
2019/04/17 10:30:21 keepalive: 10
2019/04/17 10:30:21 conn: 1
2019/04/17 10:30:21 autoexpire: 0
2019/04/17 10:30:21 scavengettl: 600
2019/04/17 10:30:21 snmplog:
2019/04/17 10:30:21 snmpperiod: 60
2019/04/17 10:30:21 quiet: true

2019/04/17 10:35:57 connection: 0.0.0.0:33800 -> x.x.x.x:31000
2019/04/17 10:35:57 session normally closed
2019/04/17 10:46:35 session marked as expired
2019/04/17 10:46:35 connection: 0.0.0.0:57331 -> x.x.x.x:31000
2019/04/17 10:46:35 session normally closed
2019/04/17 11:02:54 session marked as expired
2019/04/17 11:02:54 connection: 0.0.0.0:51395 -> x.x.x.x:31000
2019/04/17 11:02:54 session normally closed
2019/04/17 11:02:57 session marked as expired
2019/04/17 11:02:57 connection: 0.0.0.0:50471 -> x.x.x.x:31000
2019/04/17 11:02:57 session normally closed
2019/04/17 11:02:59 session marked as expired
2019/04/17 11:02:59 connection: 0.0.0.0:39306 -> x.x.x.x:31000
2019/04/17 11:02:59 session normally closed
2019/04/17 11:03:02 session marked as expired
2019/04/17 11:03:02 connection: 0.0.0.0:60102 -> x.x.x.x:31000
2019/04/17 11:03:03 session normally closed
2019/04/17 11:03:04 session marked as expired
2019/04/17 11:03:04 connection: 0.0.0.0:45381 -> x.x.x.x:31000
2019/04/17 11:03:05 session normally closed
2019/04/17 11:03:06 session marked as expired
2019/04/17 11:03:06 connection: 0.0.0.0:36850 -> x.x.x.x:31000
2019/04/17 11:03:07 session normally closed
2019/04/17 11:03:13 session marked as expired
2019/04/17 11:03:13 connection: 0.0.0.0:57319 -> x.x.x.x:31000
2019/04/17 11:03:13 session normally closed
2019/04/17 11:03:15 session marked as expired
2019/04/17 11:03:15 connection: 0.0.0.0:36473 -> x.x.x.x:31000
2019/04/17 11:03:16 session normally close

[xtaci]

没问题啊，scavenger会主动销毁链接

[imcotton]

But that leaves tons of broken pipes on server side, never seen this kind of behavior on version v20190104 tho.

[xtaci]

@imcotton 可以试下最新的版本，最近四月的版本有一个bug

4.8 -> 4.17期间的版本有bug

[imcotton]

Have tested the latest version, and it's working perfectly now, thanks for the fixing!

[kjian]

0428 还是有 Broken Pipe 问题

[k79e]

你是正常使用然后断流么? 我只记得以前lan测的时候 连接老是打开然后中断 就是下载一个文件然后停止下载然后继续 多试几次就会 kcp直接用不了了........