疏忽了 終於解決了長久以來的 WireGuard 伺服器速度問題
viberconnection · 2022-06-03 22:50:57 +08:00 · 1818 次点击这是一个创建于 696 天前的主题，其中的信息可能已经有所发展或是发生改变。
問題背景：
生產環境中有兩臺 WG server ，在外部網路情形下上傳下載速率很慢，將 MTU 調整爲 1280 提升了一些速率，但隧道內 TTFB 時間仍然高得無法接受。「是 ICMP 往返延遲的兩倍」 「形容一下感受就是鏈接 WG 後 Chrome 打開任意一個網頁還要轉兩圈加載這樣子」。
期間排查過 WG 和其他依賴軟體，但是仍然無法解決。直到有一天翻 Kernel 參數說明，才發現 linux 有對過小的 TCP 數據包做一些修改然後再發出去這樣的事情，順着這個思路往下調整參數，問題最終得以解決。
我個人也有在對岸家中搭建過 WG 伺服器，將同樣的參數應用於我的私人伺服器，效果同樣顯著。所以個人認爲這應該是一個普遍存在的問題「即較小 MTU 的 WireGuard 隧道存在 TCP 連接 TTFB 較高的情形」，所以故此與大家分享自己的發現。
解決辦法：
在 sysctl.conf 這個配置檔之內新增加一行 net.ipv4.tcp_min_snd_mss = 1 解決。
生產環境中有兩臺 WG server ，在外部網路情形下上傳下載速率很慢，將 MTU 調整爲 1280 提升了一些速率，但隧道內 TTFB 時間仍然高得無法接受。「是 ICMP 往返延遲的兩倍」 「形容一下感受就是鏈接 WG 後 Chrome 打開任意一個網頁還要轉兩圈加載這樣子」。
期間排查過 WG 和其他依賴軟體，但是仍然無法解決。直到有一天翻 Kernel 參數說明，才發現 linux 有對過小的 TCP 數據包做一些修改然後再發出去這樣的事情，順着這個思路往下調整參數，問題最終得以解決。
我個人也有在對岸家中搭建過 WG 伺服器，將同樣的參數應用於我的私人伺服器，效果同樣顯著。所以個人認爲這應該是一個普遍存在的問題「即較小 MTU 的 WireGuard 隧道存在 TCP 連接 TTFB 較高的情形」，所以故此與大家分享自己的發現。
解決辦法：
在 sysctl.conf 這個配置檔之內新增加一行 net.ipv4.tcp_min_snd_mss = 1 解決。
第 1 条附言 · 2022-06-03 23:33:04 +08:00
抱歉，我忘記自己的伺服器是特殊定製內核了，所以才可以改到 1 。沒有定製的把這個參數置於能接受的最低即可。
：）
：）
 |
1
viberconnection OP 抱歉，我忘記是特殊定製內核了。
|
 |
2
liuxyon 2022-06-07 15:23:06 +08:00 via Android
楼主请教一下修改网络等级提高 wg 的速度
|
|
3
liuxyon 2022-06-07 17:10:44 +08:00 via Android
修改不了,默认是 48. 而且根据资料说最小只能是 48, 有效负载是 8.
|
Select Language