重载服务器上对udp2raw的性能优化

[jameslee90]

有一台Ubuntu 18.04的独立服务器（非VPS），跑了udp2raw + udpspeeder + openvpn，通过openvpn做全局流量转发。客户端来自各地，目前高峰期在线客户端差不多80个左右，流量200多Mbps。基本上都是在线直播的视频流量，其中tcp类型的直播流量和udp类型的直播流量大概一半一半。

当流量在120Mbps以下的时候，从客户端ping服务器平均延时也就200多ms；流量超过200Mbps以后，从客户端ping服务器的公网IP最多300ms左右，但如果ping服务器的OpenVPN接口地址则结果就是1000多ms，这时客户端看视频就会感觉很卡。请问是什么原因会造成ping服务器外网IP和ping服务器VPN接口地址的结果差异如此之大呢？

两端的udp2raw都使用默认参数，faketcp混淆，udpspeeder的发包比例20：10，openvpn采用明文通讯不加密。linux server内核与fs和tcp相关的参数已经做了优化，不知道还有什么更加有效的优化措施吗？因为服务器带宽才用了20%，内存使用率还不到10%，CPU在高峰期使用率也才不到15%，所以我觉得还有很大提升空间才是。在服务器启用多个udp2raw实例是否有作用呢？

[wangyu-]

发一下软件的版本和具体参数

追查这种问题的一般思路是，先单独用openvpn试一下，看有没有类似现象。如果没有，那就分别试一下udp2raw+openvpn 和udpspeeder+openvpn，看问题出在谁身上。

CPU在高峰期使用率也才不到15%

关注一下每个核的CPU占用率 udp2raw udpspeeder openvpn都是单核程序，他们各自都只能利用一个核

在服务器启用多个udp2raw实例是否有作用呢

不确定 但是值得一试

[jameslee90]

服务器端： UDP2RAW git version:2c67c319b7 build date:Feb 24 2018 18:08:08 udp2raw_amd64_hw_aes -s -l 0.0.0.0:81 -r 127.0.0.1:1193 -a -k blahblah --raw-mode faketcp --lower-level enp1s0f0#11:22:33:44:55:66 --sock-buf 10240

UDPSPEEDER git version: d56e34bc22 build date: May 21 2018 22:29:17 speederv2_amd64 -s -l 127.0.0.1:1193 -r 127.0.0.1:1194 -f20:10 --sock-buf 10240

服务器CPU共有24个核，在TOP里面看（按1之后）个别核有满载的情况，同时也仍然有一些核100% IDLE。在高峰期的 load average 三个数值大约在 3 至 5 之间。

如果要根据你的建议排查问题目前比较麻烦的是客户端都不在本地，要修改连接方式比较困难，并且由于服务器在国外（客户端都在国内），OPENVPN直联过来会被XX，这个排查可能不大好做。

如果这三个服务程序都是单核的话，那么我同时多运行几个实例，系统是否会自动将不同实例分配至不同的core呢？

[wangyu-]

如果要根据你的建议排查问题目前比较麻烦的是客户端都不在本地，要修改连接方式比较困难，并且由于服务器在国外（客户端都在国内），OPENVPN直联过来会被XX，这个排查可能不大好做。

既然都发现满载了 就不用排查了 你看下是哪个程序把单个核心占满了就可以了 top可以直接看到

我估计是udpspeeder占满的

如果这三个服务程序都是单核的话，那么我同时多运行几个实例，系统是否会自动将不同实例分配至不同的core呢?

这必须可以呀

最简单的方是你再运行一套udp2raw udpspeeder openvpn. 如果你iptables用得熟甚至可以 单个udp2raw+多个udpspeeder+单个openvpn这样运行

[jameslee90]

单个udp2raw+多个udpspeeder+单个openvpn这样运行 是否指用iptables做基于轮询策略的load balance？那我近期找时间做个调整测试一下，稍后反馈结果。 感谢你的帮助！

[wangyu-]

是否指用iptables做基于轮询策略的load balance

就是用iptables做随机端口转发，不确定跟你说的轮询是不是同一个意思

[love4taylor]

话说做不了端口复用?

[wangyu-]

话说做不了端口复用?

你是说so_reuseport？ 应该也是可行的(3.9以上内核)，不过我在代码里并没启用reuseport参数(防止误操作bind到一个端口多次，以后可以考虑做成可选参数)，目前需要自己加上后编译。

另外友情提示reuseport这个东西有坑，最好多读一些相关文章再尝试

[Handsome1080P]

我的4核心CPU I5-6300HQ,啟動了4個不同監聽端口的UDPSPEEDER、一個UDP2RAW、單OPENVPN，簡單的IPTABLES隨機端口轉發作為均衡負載。UDPSPEEDER在數據量大的時候是真的吃單核CPU。目前多人連接速度不錯，1000M能跑個800M-900M左右

[Handsome1080P]

我的4核心CPU I5-6300HQ,啟動了4個不同監聽端口的UDPSPEEDER、一個UDP2RAW、單OPENVPN，簡單的IPTABLES隨機端口轉發作為均衡負載。UDPSPEEDER在數據量大的時候是真的吃單核CPU。目前多人連接速度不錯，1000M能跑個800M-900M左右

CPU單核主頻很重要，我的U不是服務器U，但是能睿頻到3.1GHZ,還是性能不錯的

[ghost]

有 iptable 规则可以参考吗？好像每个连接还是只会走一个端口。多个客户端才可能从随机多端口中得益。一对一是不是没办法用到多端口？这里有人讨论，没有答案：https://serverfault.com/questions/716346/randomize-destination-port-for-every-packet-with-iptables 能不能在 udp speeder 中加入把数据包随机分发到服务器的多个端口，而服务端则把多个端口的数据包合并包后再连接（这样连接的 UDP 源端口就只有一个） OpenVPN 服务。

[Handsome1080P]

有 iptable 规则可以参考吗？好像每个连接还是只会走一个端口。多个客户端才可能从随机多端口中得益。一对一是不是没办法用到多端口？这里有人讨论，没有答案：https://serverfault.com/questions/716346/randomize-destination-port-for-every-packet-with-iptables 能不能在 udp speeder 中加入把数据包随机分发到服务器的多个端口，而服务端则把多个端口的数据包合并包后再连接（这样连接的 UDP 源端口就只有一个） OpenVPN 服务。

多開幾個UDPSPEEDER，下層端口共同監聽到同一個VPN SERVER，上層端口監聽例如111，112，113，114，115。IPTABLES 設定入口為55，轉發到111,112,113,114,115這幾個UDPSPEEDER端口。訪問55端口會隨機分配5條UDPSPEEDER隨機一條上。你這個鏈接不是有示範嗎？只開一個VPN server不就得了。

[ghost]

是的，我的链接有示范。但我的疑问是，如果我只有一个 VPN Client 对应一个 VPN Server，连接 55 端口时会随机分配到 111-115 中的一条线路（比如112）。但后面的所有数据都会一直用 112 线路（我的链接所描述的情况）。后面所有数据不会被分配到其他线路。按我的理解，所有往返的流量都会走112线路，如果 GFW 发威，对 112 端口做 QoS 限流，最终也会导致速度会限制。

[Handsome1080P]

是的，我的链接有示范。但我的疑问是，如果我只有一个 VPN Client 对应一个 VPN Server，连接 55 端口时会随机分配到 111-115 中的一条线路（比如112）。但后面的所有数据都会一直用 112 线路（我的链接所描述的情况）。后面所有数据不会被分配到其他线路。按我的理解，所有往返的流量都会走112线路，如果 GFW 发威，对 112 端口做 QoS 限流，最终也会导致速度会限制。

UDP2RAW+udpspeeder如果在同一服務器上，那麽後面的IPTABLES隨機端口和多開UDPSPEEDER只能起到負載平衡作用

[Handsome1080P]

udp2raw因爲涉及到iptables操作，所以在udp2raw之前的iptables隨機端口是否能夠實現，這個還沒有研究過。可以嘗試UDP2RAW的手動iptables功能，修改/增加DROP的IP和端口，服務器客戶端都得改，然後再做隨機端口轉發。（不過我感覺-a或者-keeprule的方式更穩一點，因爲我原來手動加的規則經常導致丟包）