演示配置，关于配置，请在此thread讨论

[xtaci]

CLIENT SIDE

$ cat /home/user/local-ss.json

{
        "smuxver": 2,
        "localaddr": ":2000", //  修改此处, 此处接受连入，比如ss-local通过此端口连入ss-server
        "remoteaddr": "IP.IP.IP.IP:33666-34690", // 修改此处，指向kcp服务器
        "key": "PASSWORDPASSWORDPASSWORDPASSWORD",  // 修改此处
        "crypt": "twofish",
        "mode": "fast3",
        "mtu": 1400,
        "sndwnd": 256,
        "rcvwnd": 2048,
        "datashard": 10,
        "parityshard": 3,
        "dscp": 0,
        "nocomp": true,
        "acknodelay": false,
        "nodelay": 1,
        "interval": 20,
        "resend": 2,
        "nc": 1,
        "sockbuf": 16777217,
        "smuxbuf": 16777217,
        "streambuf":4194304,
        "keepalive": 5,
        "autoexpire":600,
        "quiet":false,
        "tcp":false
}

$ cat /etc/systemd/system/kcp-ss.service

Description=kcp-ss

Wants=network.target
After=syslog.target network-online.target

[Service]
Type=simple
Environment=GOGC=20
ExecStart=/home/user/client_linux_amd64 -c /home/user/local-ss.json // 修改此处指向正确的json文件位置
Restart=on-failure
RestartSec=10
KillMode=process
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

SERVER-SIDE

$ cat server_ss.json

{
        "smuxver": 2,
        "listen": ":33666-34690", 
        "target": "127.0.0.1:2000", // 修改此处，指向：例如ss-server
        "key": "PASSWORDPASSWORDPASSWORDPASSWORD", // 修改此处
        "crypt": "twofish",
        "mode": "fast3",
        "mtu": 1400,
        "sndwnd": 2048,
        "rcvwnd": 2048,
        "datashard": 10,
        "parityshard": 0,
        "dscp": 0,
        "nocomp": true,
        "acknodelay": false,
        "nodelay": 1,
        "interval": 20,
        "resend": 2,
        "nc": 1,
        "sockbuf": 16777217,
        "smuxbuf": 16777217,
        "streambuf":4194304,
        "keepalive": 10,
        "pprof":false,
        "quiet":false,
        "tcp":false
}

./server_linux_amd64 -c server_ss.json

[szhangcn]

请问最新版这个pprof参数是只加在server端吗？加不加的效果有多大差别？

[maojianyou]

这个配置支持tcp，跟udp同时代理不，还有这个没有套用udp2raw,能否把udp2raw也写入到/etc/systemd/system/kcp-ss.service 里面

[monkeylab]

SERVER-SIDE {"parityshard": 0}
请问这是关闭服务端发送数据FEC的意思嘛？SIGUSR1的SNMP信息也显示客户端没有接收FEC包了，FECParityShards:0，
请问为什么这样设置？通常来说服务端发送数据到客户端比反过来更容易丢包吧？

[xtaci]

SERVER-SIDE {"parityshard": 0} 请问这是关闭服务端发送数据FEC的意思嘛？SIGUSR1的SNMP信息也显示客户端没有接收FEC包了，FECParityShards:0， 请问为什么这样设置？通常来说服务端发送数据到客户端比反过来更容易丢包吧？

不一定，比如中国的网络上下行就是不对称的。

[monkeylab]

FEC的疑问：
-mode fast -datashard 5 -parityshard 5 在15%左右丢包率的线路上FECRecovered/FECParityShards只有1%，即使在35%丢包率的线路上也没啥变化，客户端rcvwnd减半或者ds:ps改成10:3、70:30都会让FECRecovered更少，直接掉到0.03%。
请问这种情况是还没凑齐10个包就触发重传造成的么？测试用的是视频流。
RetransSegs/OutSegs两条线路都是比丢包率高2%~5%，丢包率越高快速重传的占比越大，这种重传就解决问题的情形是不是就没必要开FEC了？
client 2024/02/28 11:50:03 KCP SNMP:&{BytesSent:3123502 BytesReceived:4948978821 MaxConn:1 ActiveOpens:1 PassiveOpens:0 CurrEstab:1 InErrs:0 InCsumErrors:0 KCPInErrors:0 InPkts:10399228 OutPkts:241337 InSegs:5260796 OutSegs:4350024 InBytes:12168673893 OutBytes:253130843 RetransSegs:364 FastRetransSegs:0 EarlyRetransSegs:0 LostSegs:364 RepeatSegs:355544 FECRecovered:66582 FECErrs:5 FECParityShards:5225927 FECShortShards:2329}
server 2024/02/28 11:50:04 KCP SNMP:&{BytesSent:4948978893 BytesReceived:3123502 MaxConn:2 ActiveOpens:0 PassiveOpens:2 CurrEstab:1 InErrs:0 InCsumErrors:0 KCPInErrors:4 InPkts:241341 OutPkts:12499432 InSegs:4396665 OutSegs:6274260 InBytes:248304386 OutBytes:14823889445 RetransSegs:1431828 FastRetransSegs:783924 EarlyRetransSegs:14146 LostSegs:633758 RepeatSegs:366 FECRecovered:1344 FECErrs:1 FECParityShards:118325 FECShortShards:0}

[xtaci]

FEC的疑问： -mode fast -datashard 5 -parityshard 5 在15%左右丢包率的线路上FECRecovered/FECParityShards只有1%，即使在35%丢包率的线路上也没啥变化，客户端rcvwnd减半或者ds:ps改成10:3、70:30都会让FECRecovered更少，直接掉到0.03%。 请问这种情况是还没凑齐10个包就触发重传造成的么？测试用的是视频流。 RetransSegs/OutSegs两条线路都是比丢包率高2%~5%，丢包率越高快速重传的占比越大，这种重传就解决问题的情形是不是就没必要开FEC了？

如果用户到服务器的延迟很低，我认为是没有必要开FEC的，重传一次的惩罚并不高，所以实际的优化策略可能还会包含一些RTT测量，再制定策略。

[monkeylab]

FEC的疑问： -mode fast -datashard 5 -parityshard 5 在15%左右丢包率的线路上FECRecovered/FECParityShards只有1%，即使在35%丢包率的线路上也没啥变化，客户端rcvwnd减半或者ds:ps改成10:3、70:30都会让FECRecovered更少，直接掉到0.03%。 请问这种情况是还没凑齐10个包就触发重传造成的么？测试用的是视频流。 RetransSegs/OutSegs两条线路都是比丢包率高2%~5%，丢包率越高快速重传的占比越大，这种重传就解决问题的情形是不是就没必要开FEC了？

如果用户到服务器的延迟很低，我认为是没有必要开FEC的，重传一次的惩罚并不高，所以实际的优化策略可能还会包含一些RTT测量，再制定策略。

测试的两条线路延迟分别是200ms和100ms，应该算不上很低吧？想弄明白为何开了如此高(5:5)的FEC，FECRecovered/FECParityShards却只有1%，难道就只是单纯因为这个延迟够低了？

[xtaci]

对，这个延迟很低了，而且线路质量很好。

[xtaci]

这只是一个工具，不是万能的，具体的策略还需要根据测量来动态调整。

[monkeylab]

这只是一个工具，不是万能的，具体的策略还需要根据测量来动态调整。

现在正在调整的路上，十分感谢您的解答。

[szhangcn]

请问在延迟150ms左右，几乎不丢包的线路上， "datashard" 和 "parityshard" 是否直接设为0比价合适？