sharpbai

> 周期内数据量/周期 = 周期内平均速度。你这个说法有问题，我只发一个包，1400字节，用了 1us，那么带宽是140Gbps，带宽必须有一个相对较长的采样时间来作为分母。 「带宽必须有一个相对较长的采样时间来作为分母」是对的，所以这里采用的是20ms作为一个周期。 这里存在网卡本身物理速度，如1Gbps, 10Gbps等，实际发送速度不会突破这个值。 因为「网卡物理带宽」一般都高于「购买的预设带宽」，这里才会有「超发」的问题。 实际抓包看，单次发送数据超过20ms「购买的预设带宽」可以承载的数据量的3~4倍以上，可能引起惩罚问题。 如果网络服务商不惩罚，友好的采取接收一定缓冲区突发传输+长期平均固定带宽传输，那延迟增长与丢包总得选一样或者都有一些。

> 他的采样策略是什么，实时带宽如何计算的，这个能给出资料么。 没有明确的资料。 我搜索了下关于流控策略设备的资料，如[这个H3C的说明书](http://www.h3c.com/cn/d_202002/1273314_30005_0.htm)写的，可以基于一些规则进行速度限制，并在超过限制后可以配置惩罚措施。感觉上这些云主机厂商用的东西应该没有原理上的差别。 然后就具体到了「如何判断超过了带宽」这件事情。根据[这个文章](https://blog.csdn.net/tushanpeipei/article/details/112201996)的说明，应当是根据令牌桶的原理。 即设立一个大小合适的桶（足以容纳允许的突发数据传输量），然后定时向桶里加入按带宽算出来的令牌，消耗时就减去令牌，没有令牌之后就不能再转发了。 具体到 - 令牌桶多大 - 定时粒度是多少 这个确实不清楚，但按理说，应当公网上匹配大量出现在网络上的设备，如Linux主机，Windows机器，iOS/macOS等。一般情况下这些设备的定时粒度不做特别处理也就达到10ms级别。 我自己实践的效果，在服务端和客户端都用tc配置TBF，限制队列长度为20ms(即kcptun的interval，平滑发送数据到kcp下次发送为止，不引入额外延迟。因为Linux默认HZ是100，所以这里平滑发送，实际上也就是把20ms发送一次的数据分成间隔10ms发两次)，突发传输长度为20ms按预设带宽200mbps流过的数据量(保证缓冲的数据在理论上不引起排队造成的延迟增大)，在200mbps的机器上实测有效解决断流问题。 ``` tc qdisc add dev eth0 root tbf rate 190mbit burst 488kb latency 20ms mpu 64 ```...

I have changed SOCK_STREAM to SOCK_DGRAM to ensure packet boundary. The socket buffer have been changed in order to avoid packet loss for udp socketpairs. The SOCK_CLOEXEC flag have also...

I forgot to change back SOCK_CLOEXEC value for macOS. It is correct now.

Hmm, - Dornors decide which models to add or not seems make the donation process complicated. - the flexiblity of model selection on donated nodes leads to n^2 level increased...