为解决前几天提到的办公室网关应用上行 QoS 的问题，我现在的做法是在一个 Docker Container 中跑多个 kcptun 进程，并在 tcp 这端加 pen 做负载均衡；tcp 和 kcp 两端均做了 tc sfq 以及总带宽限速。现在总算是能把办公室的场景支撑起来了，就算有几个人在上传也能撑住。代价是消耗大量内存：总共15个 kcptun client 进程，用了约 1GB 内存。

具体的解决方案在前两天的 issue 中提过。还是非常希望能在未来看见 kcptun 内部能解决这一问题。

from kcptun.

我直接来中文吧：
我的观点是，程序越简单越好。担心越来月复杂失去了原有轻量级的特点。同时：
交互过多会不会引发特征问题？
PMTU 发现也引发很多问题。比如链路的 ping 是失效的？
如果用 UDP 来发现链路的 MTU 大小，会不会需要 ROOT 权限？

如果为了让程序简单话，能否这样：

1. 让主程序运行一段时间，然后协商，自动生成给用户推荐的配置。之后长期运行，用户可以选择用推荐的参数配置进行配置。
2. 甚至可以用一个额外的工具，去检测丢包，发现MTU大小，测试链路速度，延迟，然后自动协商并生成一个静态的用户配置，减少主程序的复杂度。而工具可以复杂一些，反正运行次数不多。
3. 协商是内在的逻辑，而用户更想知道，协商后的参数实际速度到底有何变化？

这样的优点：

1. 主程序逻辑简单直接。配置是静态配置好的。这样未来它也可以一直的路由器上运行得非常良好。
2. 交互与协商少，特征也少。

缺点：

1. 产生静态配置，如果链路发生变化，不会自适应。
   （然而我觉得是不需要自适应的，比如动态调整 FEC，NO_DELAY 感觉都不靠谱阿）

from kcptun.

嗯，轻量级是很重要的，做什么并没有确定，初衷是参数设定的自动化，通过两边交换的SNMP信息，定期，比如2分钟，切换一次算法，在下一个2分钟，观察SNMP的改变。

算法是否更有效的评判标准，比较难，有可能按住一头，另一头就翘起来，比如延迟和吞吐。 而且很有可能导致两个算法之间的不停切换（抖动）

from kcptun.

还是保持kcp的纯粹性好些，毕竟企业应用这种专业环境有专业人士在，问题不大。

from kcptun.

FRAME FORMAT

|  NONCE     |    CRC32   | = 20BYTES   
  16BYTES        4BYTES

| DATA | FEC | PING | SNMP | RESERVED | DATA LENGTH | FEC SEQID |       = 8BYTES
  1bit  1bit   1bit   1bit    12bit        16bit        32bit

TOTAL FRAME HEADER LENGTH: 20 + 8 = 28BYTES

| PAYLOAD .........|

初步拟了个帧格式，各位有什么看法。

from kcptun.

最近我还有个想法，就是我希望kcptun能支持udp的转发。kcptun可以不修改，但是希望协议上支持报文类型。这样udp转发的时候公用一个端口

from kcptun.

这个不用改kcp协议就能做到，直接在kcptun上做类型区分，封装,handleClient-> handleTCP+handleUDP
client端的port同时listen udp+tcp, server端的port+1 用于udp转发， 两条kcp 连接分别处理tcp和udp, 4层转发。

from kcptun.

最近在试图加 SFQ ，发现 kcp-tun 依赖 yamux 在一个 kcp 连接中封装多个 tcp 会话 payload 。在 kcp-go 中已经看不到 tcp 会话信息。如果需要识别和排序 tx 数据，需要在 yamux 中进行。目前走到这么远，还要继续看。

from kcptun.

貌似主要的工作应该在 yamux 的 Session.sendCh。把它换成一个 SFQ 即可。

from kcptun.

对，可以参考http/2的流控，均衡

from kcptun.

@jannson 初步想了下，不是太想加入udp转发的feature，通常来说，udp over tcp本身就是一个错误，因为上层udp和下层tcp流控的互相影响，会导致传输算法低效，比如上层udp重传和tcp重传叠加。 我觉得诸如dns poision这些问题都很好解决，在非标准端口上自己搭一个即可。

from kcptun.

今天觉得，没必要改动kcp-go,在yamux上开个单独的stream做snmp交换和控制即可，即流0

from kcptun.

想了想，觉得有道理。独立出来一个端口好了。主要是解决 PS4/Xbox 联机问题。 UDP 转发要有 NAT2 才方便联机。

重新开一个 stream 感觉更好。报文格式不用动。本身协议上还保持原来的简单性。

from kcptun.

想用kcptun来进行游戏加速，看@xtaci大佬的意思是不打算支持了。能不能出个新版本专门支持udp转发的。要在同一端口。因为ss就就一个端口。这将会是网游加速界的一次革命啊。@jannson大佬留言的最初目的我估计和我差不多，利用kcptun加速SS的UDP转发，降低ps4等主机的游戏延迟。肯定是xtaci大佬不玩游戏的，没意识到这个改动会带来多大的波澜。jannson为什么后来觉得独立出端口要好？玩家们不一定觉得好啊。 但是如果真的要新开个端口来独立udp转发，有没有什么参数设定来监听ss中传来的udp内容？具体怎么实现？

from kcptun.