LKL 資訊更新 -- TCP segmentation offload , Shadowsocks, HAProxy, Python, IPv6
不...
你們應該謝謝的是
https://www.91yunbbs.com/discussion/comment/1158/#Comment_1158
https://www.91yunbbs.com/discussion/comment/1471/#Comment_1471
@linhua
一直都只有他在研究
過了一段時間後
問題出了很多
還是一個一個解吧....
--
首先是
1. LKL 可以直接跑 SSR python 嗎?
2. LKL 可以直接跑 ss-server 嗎?
A: 可以 ss-server 一直都是可以的,
而 SSR python 的話就要用上 這個版本的 so
https://drive.google.com/file/d/0B0D0hDHteoksejNVWFQ2RU81MTA/view
@linhua 找到之前LKL缺了兩個 hooks,加上recompile之後就可以了
那.... @linhua 提到的 神秘代號是什麼? 有效嗎?
那是 TCP segmentation offload
@linhua 提到的environment variable是
LD_PRELOAD="/root/liblkl-hijack.so" LKL_HIJACK_NET_QDISC="root|fq" LKL_HIJACK_SYSCTL=“net.ipv4.tcp_congestion_control=bbr;net.ipv4.tcp_wmem=4096 16384 30000000" LKL_HIJACK_NET_IFTYPE="tap" LKL_HIJACK_NET_IFPARAMS="tap0" LKL_HIJACK_NET_IP="10.0.0.2" LKL_HIJACK_NET_NETMASK_LEN="24" LKL_HIJACK_NET_GATEWAY="10.0.0.1" LKL_HIJACK_OFFLOAD="0x8883" haproxy -f ./haproxy.cfg
和原版比起來多了
LKL_HIJACK_SYSCTL="net.ipv4.tcp_congestion_control=bbr;net.ipv4.tcp_wmem=4096 16384 30000000"
LKL_HIJACK_OFFLOAD="0x8883"
解釋一下
首先
LKL_HIJACK_OFFLOAD="0x8883"
net.ipv4.tcp_wmem="4096 16384 30000000"
不是神秘代號
1.
LKL_HIJACK_OFFLOAD 在 LKL 上 README.md也有
https://github.com/lkl/linux
本身也有介紹可以用 0x8002
開啓 mergeable RX buffer 和 guest csum
TCP segmentation offload 可以減少CPU usage
很應該要用的
之前沒有說是因為 debug log 一直吐出
"PKT is likely truncated!" 的 message
再加上當時因為沒有測試清楚
以為也不會怎樣
所以就放棄了
TSO 是什麼東東?
https://zh.wikipedia.org/wiki/大段卸载
上 wiki 吧
解釋神秘代碼 0x8883:
0x8883
兩進制是
1000 1000 1000 0011
從右數起第一個位置 是1
第2, 8, 12, 16個位置 都是1
在 linux 的 source file 中可以看到
http://lxr.free-electrons.com/source/include/uapi/linux/virtio_net.h#L34
34 /* The feature bitmap for virtio net /
35 #define VIRTIO_NET_F_CSUM 0 / Host handles pkts w/ partial csum /
36 #define VIRTIO_NET_F_GUEST_CSUM 1 / Guest handles pkts w/ partial csum /
37 #define VIRTIO_NET_F_CTRL_GUEST_OFFLOADS 2 / Dynamic offload configuration. /
38 #define VIRTIO_NET_F_MTU 3 / Initial MTU advice /
39 #define VIRTIO_NET_F_MAC 5 / Host has given MAC address. /
40 #define VIRTIO_NET_F_GUEST_TSO4 7 / Guest can handle TSOv4 in. /
41 #define VIRTIO_NET_F_GUEST_TSO6 8 / Guest can handle TSOv6 in. /
42 #define VIRTIO_NET_F_GUEST_ECN 9 / Guest can handle TSO[6] w/ ECN in. /
43 #define VIRTIO_NET_F_GUEST_UFO 10 / Guest can handle UFO in. /
44 #define VIRTIO_NET_F_HOST_TSO4 11 / Host can handle TSOv4 in. /
45 #define VIRTIO_NET_F_HOST_TSO6 12 / Host can handle TSOv6 in. /
46 #define VIRTIO_NET_F_HOST_ECN 13 / Host can handle TSO[6] w/ ECN in. /
47 #define VIRTIO_NET_F_HOST_UFO 14 / Host can handle UFO in. /
48 #define VIRTIO_NET_F_MRG_RXBUF 15 / Host can merge receive buffers. */
對應一下
有開的是
VIRTIO_NET_F_CSUM (第0個位置)
VIRTIO_NET_F_GUEST_CSUM (第1個)
VIRTIO_NET_F_GUEST_TSO4 (第7)
VIRTIO_NET_F_HOST_TSO4 (第11)
VIRTIO_NET_F_MRG_RXBUF (第15)
這幾個 就是 TCP segmentation offload
當然
如果有用 IPv6 的可以把 VIRTIO_NET_F_GUEST_TSO6 和 VIRTIO_NET_F_HOST_TSO6 打開來用
變成
1001 1001 1000 0011
轉成十六進制
0x9983
LKL_HIJACK_OFFLOAD="0x9983"
沒有的話 用 0x8883 就好了
2.
而 net.ipv4.tcp_wmem 是調 TCP send buffer 大小
這個上有詳細解釋
https://wwwx.cs.unc.edu/~sparkst/howto/network_tuning.php
3.
IPv6
一直被人吐槽沒有 IPv6
不是沒有
LKL_HIJACK_NET_IPV6
LKL_HIJACK_NET_NETMASK6_LEN
LKL_HIJACK_NET_GATEWAY6
這幾個就是 IPV6 對應的變數
而設定的方法和 UML 一樣
--
https://drive.google.com/file/d/0B0D0hDHteoksejNVWFQ2RU81MTA/view
使用 @linhua 老大補完的 LKL
LD_PRELOAD="/root/liblkl-hijack.so" \
LKL_HIJACK_NET_QDISC="root|fq" \
LKL_HIJACK_SYSCTL="net.ipv4.tcp_congestion_control=bbr;net.ipv4.tcp_wmem=4096 16384 30000000" \
LKL_HIJACK_NET_IFTYPE="tap" \
LKL_HIJACK_NET_IFPARAMS="tap0" \
LKL_HIJACK_NET_IP="10.0.0.2" \
LKL_HIJACK_NET_NETMASK_LEN="24" \
LKL_HIJACK_NET_GATEWAY="10.0.0.1" \
LKL_HIJACK_OFFLOAD="0x9983" \
python server.py -p 443 -k 自己喜歡的密碼 -m aes-256-cfb -O auth_sha1_v4 -o http_simple
就可以直接跑 LKL + python @linhua
UML, LKL, LKL+TSO的效能比較:
https://www.91yunbbs.com/discussion/229/lkl-uml-native-的比較-有用嗎?new=1
评论
感谢大佬啦
谢谢大佬们的分享!
最近遇到了一个问题,LKL状态下,ss-server启动用443端口(LKL和haproxy中也做了转发),用最新的AEAD(aes-256-gcm)协议,对ss进行debug发现:
ERROR: failed to handshake with 10.0.0.2: authentication error
ERROR: failed to handshake with 10.0.0.2: authentication error
ERROR: block all requests from 10.0.0.2
ERROR: block all requests from 10.0.0.2
用aes-256-cfb就没问题;用其它端口的AES-GCM也没问题。
请问,这种情况是不是因为haproxy不支持最新协议导致的?
但看文档中有ssl-default-bind-ciphers RSA+AESGCM这一项
haproxy.cfg里面只添加了bind *:443,并没指定协议和加密方式 。
目前应该没有解决办法吧?
@linhua @allientNeko
这个我前面遇到过,是你修改认证方式,或者客户端配置错误,客户端一直向服务端发送错误请求,服务端收到的全部是是haproxy10.0.0.2的地址,$$认证错误多次后会屏蔽这个IP,现在完全可以不用haproxy,使用新版的lkl http://soft.91yun.org/uml/lkl/liblkl-hijack.so
然后参照我前面的配置,IPv6的话对照修改。
https://www.91yunbbs.com/discussion/87/黑科技-不用換-kernel-不用uml-也可以bbr-linux-kernel-library-還有可能-bbr-lotserver/p7#Comment_1939
@bubbles 多谢你的指点。
昨天进行的一键安装版本,当前在用的应该就是最新版的LKL。
客户端配置应该没错,因为换了不同端口,就会正常传输数据。
跳过haproxy用443端口AES-GCM模式,
提示同上述类似:
ERROR: failed to handshake with 202.120..: authentication error
ERROR: failed to handshake with 202.120..: authentication error
ERROR: block all requests from 202.120..
ERROR: block all requests from 202.120..
可能是LKL内核支持的问题。
SS 的話就不要用 haproxy 中轉了
直接上SS吧
@ohmyani 这个提示是认证授权错误,检查你客户端和服务端的配置。
昨天进行测试没有通过,早上再一次直接启动lkl ss测试正常了,错误没重现。
另外之前haproxy错误如下,最初5分钟内验证通过,过一会就认证错误了。
昨天测试lkl-ss-GCM模式(无haproxy中转)报错,今天早上再次尝试通过。
错误可能是运行环境问题导致。