Kcptun: 有效载荷比讨论

[xtaci]

根据观察，下行的chrome/kcptun流量的有效载荷比大约是1：2，即50%的有效载荷，不考虑上行。

是否能根据某种方法，比如依照香农定理，丢包作为噪音，计算出最大带宽。

另外一个问题是，延迟，带宽占用，有效载荷比，是不是一个不可解决的问题，或者理论极限是什么？

还需要考虑在ADSL这种非对称流量情况。

@yaleh @jannson

[jannson]

首先我的直觉来说,延迟,带宽占用,有效载荷比 是矛盾的,是个不可解决的问题.
比如说,为了延迟小, 一有数据就要及时发包, 同时数据包尽量小, 这样发包就会更频繁. 有效载荷比就会因此降低.
同时为了尽可能的利用带宽,就要尽量的用 100% 的带宽发送能力,尽快的送达每个新产生的数据包. 这样有很多包可能就无效的被发送多次.在带宽没有被占满的情况下,这样也是能提高数据的传输速率的.

看到这个 issue 我还去学习了下香农定理, 以前学的都交回给老师了.
一般来说最大带宽不都是已知的么? 比如买了一条线路,就已经知道这条线路的最大能力,最大带宽肯定无法超过这个值.

但是若硬要求出这个值, 我感觉应该是有一些办法去求得出来的. 毕竟可以从很多侧面去测试与计算.

最后说这个话题有点高深, 哈哈.我就是过来学习的.

[xtaci]

现在的头部占用是，今天的版本
4B OTP| 4B MD5 | 8B FEC | 24B KCP | = 40 B
承载yamux，头部周期性添加 12 byte

主要的上行占用就是KCP的ACK包
如果按照之前的及时ACK，ACK包会非常的多，很多路由器对UDP的限制是包的个数，而不是带宽，这个是要考虑的。

所以问题真的很复杂，后面会谨慎发布这方面的改动，测试真实有效且有普适性才发Release.

[xtaci]

另外，我用iperf对tun做过测试，确实比直接的TestSpeed慢很多，可能会考虑更换mux库

[jannson]

恩,理解了. 及时 ack 会导致包增多. 如果过多的话, 可能又会有其它负面效果.
不知道还有没有其它 mux 的选择,有的话可以做个比较,也是不错的.

[xtaci]

mux没有太多选择，估计更换为http2/grpc更慢，需要先调查

[trivita]

这个 yamux 实现感觉还是有点问题的，yamux 是照着 spdy 来的吧

[xtaci]

和spdy没关系，是通用的链接复用层，yamux的调度均匀性有一定的问题，但主要是简单

[trivita]

我不是说和 spdy 模型本身的问题，我是说他的实现有问题，轻量级有些东西还是不能 compromise 啊
而且作者好像说是仿造 spdy 简化的

[xtaci]

yamux 本身来说是非常轻量级的，某些地方是非常粗糙的，比如窗口变更:

func (s *Stream) sendWindowUpdate() error {
    s.controlHdrLock.Lock()
    defer s.controlHdrLock.Unlock()

    // Determine the delta update
    max := s.session.config.MaxStreamWindowSize
    delta := max - atomic.LoadUint32(&s.recvWindow)

    // Determine the flags if any
    flags := s.sendFlags()

    // Check if we can omit the update
    if delta < (max/2) && flags == 0 {
        return nil
    }

    // Update our window
    atomic.AddUint32(&s.recvWindow, delta)

    // Send the header
    s.controlHdr.encode(typeWindowUpdate, flags, s.id, delta)
    if err := s.session.waitForSendErr(s.controlHdr, nil, s.controlErr); err != nil {
        return err
    }
    return nil
}

对比了下其它的mux，更糟糕，http2头部太大。
muxado看起来代码质量不太好。
没得选。

[trivita]

quic 的思路怎么样，我看有个 goquic 实现的 binding，不是原生的

[xtaci]

@trivita kcp是和quic同一层次的，只不过kcp不带mux, quic默认就带了Multiplexing,FEC

[xtaci]

@jannson @trivita 默认的fast模式的有效载荷比受nodelay的第一个参数影响最大，提供了更细致的fast2/fast3选项，至于这个参数要不要完全放出给用户，还在考虑

[jannson]

恩，看到了。开放也问题不大，反正有默认值。
未来稳定，需要提供给更小白些用户的时候，再考虑加一层封装，原来的 KCPTUN 可以保持他的专业性。

[xtaci]

添加了一个简单的SNMP，可以用于进一步调整参数

[trivita]

嗯，snmp 思路很赞，非小白可以自己找最合适的参数，然后你可以搞一个调查问卷帖子，看各种线路都适合什么参数，再优化预设选项

[xtaci]

嗯，已经发现了协议上可以改进的地方，相信速度又可以上一个台阶。

[xtaci]

1. Reduce memory usage by avoiding make on fec group
2. Release freebsd binary version
3. Expose SetNoDelay() function for future manual control
4. Add SNMP to dump information, kill -SIGUSR1 pid to print
5. Pipeline ReadFromUDP() for faster receiving of UDP Packets
6. Fix parse_ack() for _too many fast resend_
7. Adjust yamux max window size for better streaming of UHD video
8. Add hidden parameters for manual control of SetNoDelay(), eg:
   -mode manual -nodelay 1 -resend 3 -nc 1 -interval 20

0603的版本，把手动控制的SetNoDelay()放出来了，隐藏的参数
@jannson @trivita

我用的配置如下:

./client_linux_amd64 -l "127.0.0.1:1080" -key "p4ed3ejabreqA" -rcvwnd 2048 -sndwnd 128 -r "XXXXXX:55005" -mtu 1400 -dscp 0  -mode manual -nodelay 1 -resend 2 -nc 1 -interval 20

./server_linux_amd64 -t "127.0.0.1:1080" -key "p4ed3ejabreqA" -dscp 0 -mtu 1400 -sndwnd 2048  -mode manual -l ":55005" -nodelay 1 -resend 0 -nc 1 -interval 20

[xtaci]

Video ID:aFddiHCWtM0
Dimensions:854 x 480 * 2
Resolution:2560 x 1440@30
Volume:100%
Stream Host:r10---sn-oguesned
Stream Type:https
CPN:hhuOqRlUtxBN1KDq
Mime Type:video/webm; codecs="vp9"
DASH:yes (271/251)
Connection Speed:14171 Kbps
Buffer Health:61.0 s

[lins05]

不错，现在从德国数据中心套 scp 下载文件的速度能到 1.5~2MB/s 👍 ，前几周的版本只能到 1MB。当然，系统显示实时速度是 12MB/s, 把联通 100M 宽带都占满了。。

[xtaci]

@lins05 有效载荷有很大的可调整性，试下这组参数：

客户端参数 -sndwnd 256 -rcvwnd 2048 -mode fast2
服务器参数 -sndwnd 2048 -rcvwnd 2048 -mode manual -nodelay 1 -resend 0 -nc 1 -interval 20

最佳参数调节要通过SNMP汇报的结果来调整，重点是FastResend,Resend,Lost之间的比例，我个人用这组参数，下行4K UHD 是很流畅的。

[trivita]

i'm getting 60% utilization of my bandwidth with your settings, hooray

[xpiaoyu]

主要的上行占用就是KCP的ACK包
如果按照之前的及时ACK，ACK包会非常的多，很多路由器对UDP的限制是包的个数，而不是带宽，这个是要考虑的。

来源请求。