有效载荷比讨论 about kcptun HOT 22 CLOSED

@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 是很流畅的。

from kcptun.

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

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

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

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

from kcptun.

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

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

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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看起来代码质量不太好。
没得选。

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

from kcptun.

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

来源请求。

from kcptun.