关于端口转发速率的疑问

[nowjust]

请教下各位大牛，我有一台国内的 nat vps，我试过直接从 vps 上通过 scp 或 wget 的方式下载欧洲的服务器里的资源，速率可以达到 7-8M/s 。我在本地通过 scp 方式下载 nat vps 的资源，速率可达到 10M 。 可是通过 nat vps 上设置的端口转发方式，从本地下载欧洲的服务器里的资源最多只有 3M/s，我先怀疑是不是转发工具性能的问题，但我先后试了 socat 、haproxy 、realm 、firewalld 等多种转发工具，发现速度还是超不过 3m/s，这是怎么回事呢？端口转发会有这么大的损耗吗？大牛们有遇到过吗？谢谢！

[ericbize]

bbr 试一下

[nowjust]

nat vps 和欧洲服务器都装了

[heiher]

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

[laminux29]

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

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

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



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

vps-你家

欧洲服务器-vps-你家

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



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

[vszs]

运营商 qos 的可能比较大

[flynaj]

试试 gost

[nowjust]

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

[nowjust]

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

[nowjust]

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

[nowjust]

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

[heiher]

@nowjust nginx stream proxy 应该也可以

[nowjust]

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

[nowjust]

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

[flynaj]

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

[mepwang]

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

[vduang]

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

[kangsheng9527]

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

[luguiyao]

也可以尝试 nginx 反代

[alect]

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

[nowjust]

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

[vduang]

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

[epson3333]

开锐速脱胎换骨

[nowjust]

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