FULI

thanks for the PR, but the purpose for this repo is not for "Performance" but "Clearness" for understanding.

port should be mapped from docker to the outside or a standalone IP in k8s, keep all services share a same inside port for etcd discovery

端口已经参数化了 https://github.com/xtaci/chat/blob/master/main.go#L31

> 目前在长肥管道下如果想达到高带宽利用率，存在以下矛盾 > > 在「发送与接收端的RTT」大于「协议处理周期」(即interval参数)时，不存在同一个发送窗口的尺寸，在发送策略为窗口中有数据就应发尽发的策略下，既满足一次性突发传输的速率不超过预设带宽，又能保持持续传输达到预设带宽。 > > 举例：发送端与接收端固有物理带宽均为200mbps，平均RTT为90ms，kcptun的发送周期为20ms, kcptun的mtu设置为1400 > > 为了达成持续发送时窗口容纳BDP的数据，配置发送窗口为1536。但这会造成在突发传输时，20ms内的峰值带宽达到持续传输的(RTT/发送周期)倍数，即4.5倍，实际峰值带宽会达到约900mbps。 周期内数据量/周期 = 周期内平均速度。你这个说法有问题，我只发一个包，1400字节，用了 1us，那么带宽是140Gbps，带宽必须有一个相对较长的采样时间来作为分母。 > > 一方面，发送数据超过实际带宽对于数据传输延迟造成不利影响，另一方面，这种行为是不被服务商允许的，实际效果是在突发传输后，AWS与ALI/TX的机器间会出现对应端口传输的数据RTT变为1000ms的惩罚措施，该惩罚持续时长为60s。 > > 目前通过tc在发送端机器与接收端机器把发送速度限制到200mbps，同时做20ms的发送平滑措施，没有出现过一次惩罚问题，也没有因此而产生过断流问题。 > > 但这个措施只是保底解决被惩罚的问题，在突发期被tc丢弃的数据会依赖重传，这部分数据会增大其传输延迟。不如直接从源头上控制发送速率，达成更低的传输延迟。这样也更符合KCP的设计目标——为流速优化 > > 所以建议增加最大发送带宽限制功能，针对底层的单个KCP连接，根据配置的最大发送速率决定一次发送的最大数据量，而不是窗口有空间就全部发出去。 > >...

> > 周期内数据量/周期 = 周期内平均速度。你这个说法有问题，我只发一个包，1400字节，用了 1us，那么带宽是140Gbps，带 > 实际抓包看，单次发送数据超过20ms「购买的预设带宽」可以承载的数据量的3~4倍以上，可能引起惩罚问题。 > 如果网络服务商不惩罚，友好的采取接收一定缓冲区突发传输+长期平均固定带宽传输，那延迟增长与丢包总得选一样或者都有一些。 他的采样策略是什么，实时带宽如何计算的，这个能给出资料么。

有限的内存，并行，充分的带宽利用，三者不可兼得。这是一个困境。-- **"smux dilemma"**

可以参考这里的最后一段：https://zhuanlan.zhihu.com/p/53849089

多条链接，需要开启拥塞控制算法来避免同一底层物理链路的相互竞争。 （你可以试试在kcptun里面 -nc 0，-conn 4来开启。） 然而开启拥塞控制算法的结果就是，在高丢包链路下，不可能做到稳定传输，因为窗口不够刚性。

我在想是否可以在smux做一个流量整形，这样也许会从发送的角度来控制发送者的公平性

https://github.com/xtaci/smux/commit/78fdaa98a6b10cc3c6974cb187f7bbdc826eb772