关于端口转发速率的疑问

bbr 试一下

nat vps 和欧洲服务器都装了

试试用户态转发，不是直接包转发。

1.监视一下整个 vps 的对于每条链接的传输速度，来排查一下是不是端口转发造成损耗。

举个例子，vps 到你家里的链路传输速度为 5MB/s，但实际数据速度只有 1MB/s，那就相当于损耗了 4MB/s 的数据。

这种数据损耗的原因有很多，比如这种端口转发协议比不上直接 scp，或者端口转发协议被 gfw 或运营商识别了，等等。



2.分别测试：
欧洲服务器-vps

vps-你家

欧洲服务器-vps-你家

三种模式的延迟。我觉得问题应该卡在这里了。出现这种问题的可能原因，要不是端口转发程序的内部 bug 或业务逻辑导致产生延迟，要不是协议对这种端口转发模式支持不好造成了延迟。



3.无论是以上哪种问题，建议都别做端口转发了，做存储转发。

运营商 qos 的可能比较大

试试 gost

@flynaj 谢谢，试过了，效果更差

@vszs 两段的单独连接都没有问题，应该与 QOS 关系不大

@laminux29 感谢分析，我来试一试延迟情况。另外，我在 nat 上用 iftop 做了个监测，从监测情况看，欧服到 nat 段的速率总要比 nat 到本地的速率慢个 1-200k，感觉像是欧服到 vps 段的速度限制了整个转发速率。

@heiher 有什么现成的工具可以使用吗？

@nowjust nginx stream proxy 应该也可以

@heiher 试了 nginx，稍微好一点点，和 haproxy 差不多

@laminux29 不知存储转发有没有现成的工具呢，还是需要自己造轮子？谢谢！

@nowjust #7 用 kcp 协议 直接来！

好像通用 Linux 转发效率本身就不高，绕过操作系统协议栈的用户态转发速度快很多，比如基于 DPDK 的包转发工具

端口转发没这么大损耗。做转发的时候实际占用带宽是你下载速度的 2 倍，所以你的 vps 下行速度已经达到 6m 了，可能已经接近带宽限制了。另外 dns 解析到的 ip 也可能影响下载速度，换成直接用 ip 去 wget 试试

只要能重现问题就能找出问题甚至解决问题。。。

也可以尝试 nginx 反代

这种情况下，虽然你只有 3M，但中转服务器的速率是 3+3，上下行一起跑的

@vduang @alect nat 机是上下行分别限速的，所以还没有达到带宽限制。这两天经过反复折腾，发现应该是 scp 协议的锅，至于是被 QoS 还是协议缺陷就不知道了，后来更换了其它协议，速度就能上升到 7-8M 了，下次有人遇到类似情况也可以考虑更换协议试试。感谢各位大牛

@nowjust 换成啥协议了，是基于 udp 的协议吗？

开锐速脱胎换骨

@vduang 不是，换成基于 HTTP 的协议了