tcp-nanqinlang / general Goto Github PK

[ 0.117726] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 0.118478] Warning: unable to open an initial console.
[ 0.118514] This architecture does not have kernel memory protection.
[ 3.214198] random: fast init done
Segmentation fault

Rinetd版本

centos 7 debian也测试了 都不能用

ERR_CONNECTION_REFUSED

用的ubuntu16.4.上面搭了一堆的东西，所以想先问问是否支持，谢谢

大佬的脚本现在不支持VMWARE了吗？之前我用了还是可以的。

lkl 实现bbr中，haproxy并未转发真实ip，nginx获取的remote_addr 为局域网ip10.0.0.2

--2017-10-28 14:56:23-- http://elrepo.org/linux/kernel/el7/x86_64/RPMS/kernel-ml-4.13.8-1.el7.elrepo.x86_64.rpm
Resolving elrepo.org (elrepo.org)... 69.195.83.87
Connecting to elrepo.org (elrepo.org)|69.195.83.87|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-10-28 14:56:23 ERROR 404: Not Found.

Sorry,我看了脚本后可能是自己的设置存在问题...

--2018-03-10 19:30:31-- https://github.com/nanqinlang-tcp/tcp_nanqinlang/releases/download/rinetd/rinetd_bbr.module
正在解析主机 github.com (github.com)... 192.30.253.113, 192.30.253.112
正在连接 github.com (github.com)|192.30.253.113|:443... 已连接。
已发出 HTTP 请求，正在等待回应... 404 Not Found
2018-03-10 19:30:32 错误 404：Not Found。

chmod: 无法访问"rinetd_bbr.module": 没有那个文件或目录
[Info] 输入你想加速的端口
(多个端口号用空格隔开。暂不支持端口段。默认使用 443):1000 2000
nohup: 把输出追加到"nohup.out"
nohup: 无法运行命令"./rinetd_bbr.module": 没有那个文件或目录
nohup: 把输出追加到"nohup.out"
nohup: 无法运行命令"./rinetd_bbr.module": 没有那个文件或目录
nohup: 把输出追加到"nohup.out"
nohup: 无法运行命令"./rinetd_bbr.module": 没有那个文件或目录
[Error] tcp_nanqinlang not running, please check !

OpenVZ BBR 安装完后ping是双返回吗？每次都多一个UDP！ 返回

我相信 vmware 跟 kvm 一樣。

在 bwg 主机商 kvm debian_9（32bit） get_url() 中 bit=uname -m 取出的是 i686
接下来的 if 判断没有包括。
get_url(){ ...... bit=uname -m...... elif [[ "${bit}" = "i386" ]]; then ...... }

why daily

http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/CHANGES

that's why i choose a daily kernel to use.

enable tcp_nanqinlang

to enable tcp_nanqinlang for that kernel, you should run the following directive:

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2018-01-05/linux-image-4.15.0-999-lowlatency_4.15.0-999.201801050201_amd64.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2018-01-05/linux-headers-4.15.0-999_4.15.0-999.201801050201_all.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2018-01-05/linux-headers-4.15.0-999-lowlatency_4.15.0-999.201801050201_amd64.deb

dpkg -i linux-image-4.15.0-999-lowlatency_4.15.0-999.201801050201_amd64.deb
dpkg -i linux-headers-4.15.0-999_4.15.0-999.201801050201_all.deb
apt-get install -y libelf1
dpkg -i linux-headers-4.15.0-999-lowlatency_4.15.0-999.201801050201_amd64.deb
update-grub

then, reboot your device, then run these:

wget https://github.com/nanqinlang-tcp/tcp_nanqinlang/releases/download/daily-20180105/tcp_nanqinlang.c

# debian7/8
wget -O Makefile https://raw.githubusercontent.com/nanqinlang-tcp/tcp_nanqinlang/master/Makefile/Makefile-Debian7or8
# debian9
wget -O Makefile https://raw.githubusercontent.com/nanqinlang-tcp/tcp_nanqinlang/master/Makefile/Makefile-Debian9

make && make install

echo -e "\nnet.core.default_qdisc=fq" >> /etc/sysctl.conf
echo -e "net.ipv4.tcp_congestion_control=nanqinlang\c" >> /etc/sysctl.conf
sysctl -p

关于魔改BBR不要使用最新内核就好了，最新内核会编译失败

我上一台服务器已部署成功，但是新的服务器在用一键脚本时出现错误。

make -C /lib/modules/`uname -r`/build M=`pwd` modules CC=/usr/bin/gcc-4.9
make[1]: *** /lib/modules/3.16.0-4-amd64/build: No such file or directory.  Stop.
Makefile:4: recipe for target 'all' failed
make: *** [all] Error 2

于是我执行了

apt-get install linux-headers-3.16.0-4-amd64

再来报错就变成了

make[4]: *** [/home/tcp_nanqinlang/make/tcp_nanqinlang.o] Error 127
/usr/src/linux-headers-3.16.0-4-common/Makefile:1354: recipe for target '_module_/home/tcp_nanqinlang/make' failed
make[3]: *** [_module_/home/tcp_nanqinlang/make] Error 2
Makefile:181: recipe for target 'sub-make' failed
make[2]: *** [sub-make] Error 2
Makefile:8: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-3.16.0-4-amd64'
Makefile:4: recipe for target 'all' failed
make: *** [all] Error 2
[Error] load mod failed, please check!

请问接下来怎么办呢。。

转载自原帖： https://www.91yunbbs.com/discussion/229/lkl-uml-native-%E7%9A%84%E6%AF%94%E8%BC%83-%E6%9C%89%E7%94%A8%E5%97%8E-%E6%95%B8%E6%93%9A%E6%9B%B4%E6%96%B0
感谢原作者 neko 大佬

allientNeko 话题数：161会员, 大佬
四月 2017 最后编辑于 四月 2017 在 灌水 #0

昨天打錯了指令
使得數據作廢了....
這是新的數據

LKL UML native 的比較

醜婦終須見家翁
LKL UML 就是沒速度...

LKL UML 的出現
我本身也只是想要加快一下 TCP congestion control 的發展
因為現行的 kernel module 都有點煩
如果有 LKL UML 就可以加快一點了吧

在 UML 被人們從過去的歷史巨坑中掘起來之後
LKL 又被 @linhua 從 github 的實驗室拉出來

LKL 全名是 Linux Kernel Library
UML 是 User-mode Linux

LKL 由 intel 付錢研究 意在把 kernel 當成 library 用
而 UML 就從十幾年前就一直存在

我聽到最多的就是
"在 userspace 開整個 kernel
連 bandwidth 都跑不滿也敢拿出來"
"還不如自己寫個 TCP stack"

當然實際的口氣會更糟一點點
不過也表明了 LKL UML 有多不濟了
沒錯
就是連 bandwidth 也跑不滿....

="=
現實一點吧
自己寫一個 TCP stack 很難維護的....
或者說的人可以半天寫出來
然後可以有時間在github上維護

我戰五渣
就放過我吧

那....
要用LKL UML 嗎?
(以下測試
如果覺得太悶的話
就去看結論吧)

測試開始
client: vultr Frankfurt 4vCPU
這台client 都安裝了 ubuntu 16.04 LTS, lubuntu-core 和 firefox
然後用這一台連去全世界的 SSR server
server: vultr 的 1vCPU 1GB
port speed: 10Gbps
這樣比較接近大眾的設定

為什麼要用這種笨設定測試?
還不是因為有人說:
"看你LKL吹上天
實際開firefox用上來就是渣"
那我就開一台 desktop 來跑跑看

以下統一用 SSR 做測試
每組設定跑 10 次
取平均值的大約數字

LKL + python + TSO
使用的command

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 do-not-hack-me -m aes-256-cfb -O auth_sha1_v4 -o http_simple

LKL + python
使用的command
(和 LKL + python + TSO 一樣 不過少了 LKL_HIJACK_OFFLOAD="0x9983")

**LKL + HAproxy + TSO **

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" \
haproxy -f ./haproxy.cfg

LKL + HAproxy
(和 LKL + HAproxy + TSO 一樣 不過少了 LKL_HIJACK_OFFLOAD="0x9983")

native SSR
就是直接跑SSR了

without proxy
什麼都不用 直接連上之前測試時用的 speedtest 節點

test environment 1:
location: New York
speedtest ping 100ms

LKL + python + TSO

download: 90Mbps
upload: 70Mbps
CPU usage: 30%

LKL + python

download: 70Mbps
upload: 85Mbps
CPU usage: 30%

LKL + HAproxy + TSO

download: 90Mbps
upload: 90Mbps
CPU usage(including python): 25%

LKL + HAproxy

download: 45Mbps
upload: 35Mbps
CPU usage(including python): 20%

native SSR

download: 600Mbps
upload: 30Mbps
CPU usage: 90%

without proxy

太快了 firefox 選擇死亡

test environment 2:
location: Tokyo
speedtest ping 270ms

LKL + python + TSO

download: 60Mbps
upload: 30Mbps
CPU usage: 30%

LKL + python

download: 40Mbps
upload: 15Mbps
CPU usage: 30%

LKL + HAproxy + TSO

download: 35Mbps
upload: 15Mbps
CPU usage(including python): 16%

LKL + HAproxy

download: 20Mbps
upload: 20Mbps
CPU usage(including python): 11%

native SSR

download: 320Mbps
upload: 25Mbps

without proxy

download: 35Mbps
upload: 5Mbps

(不... 是真的... without proxy 比 native proxy 慢
證明了線路還是很重要)

test environment 3:
location: Amsterdam
speedtest ping 25ms

LKL + python + TSO
download: 200Mbps
upload: 200Mbps
CPU usage: 80%

LKL + python

download: 150Mbps
upload: 150Mbps
CPU usage: 80%

LKL + HAproxy + TSO

download: 230Mbps
upload: 230Mbps
CPU usage(including python): 80%

LKL + HAproxy

download: 100Mbps
upload: 100Mbps
CPU usage(including python): 80%

native SSR

download: 420Mbps
upload: 300Mbps

without proxy

太快了 firefox 選擇死亡

test environment 4:
location: Frankfurt
speedtest ping 10ms

LKL + python + TSO

download: 250Mbps
upload: 250Mbps
CPU usage: 85%

LKL + python

download: 200Mbps
upload: 200Mbps
CPU usage: 85%

LKL + HAproxy + TSO

download: 350Mbps
upload: 350Mbps
CPU usage(including python): 85%

LKL + HAproxy

download: 150Mbps
upload: 150Mbps
CPU usage(including python): 85%

native SSR

download: 500Mbps
upload: 300Mbps

special
LKL + python + TSO (protocol: origin, plain)

download: 400Mbps
upload: 300Mbps

without proxy

太快了 firefox 選擇死亡

--

UML 全世界一個樣

UML + SSR

100Mbps
35Mbps
CPU usage: 85%

UML + HAproxy

150Mbps
45Mbps
CPU usage(including python): 90%

看上去很好
不過 UML 在多CPU下就不行了

結論:
可以看得出來
server只有 1vCPU
100多ms delay 下
LKL 最多跑 90Mbps (多幾個CPU數字上會好不少)

270ms delay下
LKL 只有最高50Mbps

比較有趣的是
當 delay 只有 40~50ms 以下
LKL + HAproxy 就會比 LKL + python 快了
而 TSO 也對 HAproxy 更有效果

理由是因為 HAproxy 不需要太大量的 computing
當 bottleneck 不在線路
那 LKL + HAproxy 就會比 LKL + python 好

而TSO減低CPU處理TCP的使用量時
HAproxy 可用的CPU加大一點也很有效果
而 python 因為要加密解密
CPU 釋放了
也沒有差多少

LKL 和 UML 都很依賴CPU
CPU用越多的 放在上面跑就越不利
CPU 只有 2000MHz 1800MHz 的
效率也會打折扣

那麼.....
既然效率這麼差
那要用 LKL UML 嗎?

一. 在這邊的大多數人都知道了
慢 是因為掉包掉包掉包
明明向電訊公司申請的是200Mbps 也可以掉成10Mbps的
而 BBR 就解決了這個問題

二. 100Mbps
應該是大部分人的家用網路速度
UML 和 LKL 對於跑上60Mbps 是有餘力的
100Mbps沒有BBR 和 60Mbps 有BBR
這個就要取捨了
(你相信可以跑滿 100Mbps嗎....?)
暫時我也沒有看到有人電信家寬有10G口可以隨便跑滿的...

三. 你看到的數字都是最高極限
打個比方 downlink 有80Mbps
如果有兩台一起跑測試就每台只有 40Mbps

四. 如果是做機場和機長的
就不要用 LKL UML 了
成本上來說不值得
1Gbps 換成 100Mbps
還要 CPU usage 高
不如好好買一台 BWG 的KVM吧

最後最後
BWG 的KVM 也就3刀一個月
好用皮實
OVZ 什麼的
也開始退入歷史了吧.......

--

後記:

誰再懟我
"聽你吹上天"
"bandwidth 也跑不滿的垃圾"
我就發脾氣了
因為我一直沒有覺得我自己有多厲害
也沒有到處吹
真的沒有....
就只有在 91yun 和 v2ray 上說了一下
LKL和UML給一家4口科學上網用是沒問題
LKL UML和Native比速度的話
就不要想了
還是想要懟的話
就找真的有到處吹的人吧.....

最近遇上兩個想收錢幫人安裝 LKL的
一個在Google+ 一個在Telegram
費用是 45 人民幣
我說: 高延遲的 LKL沒可能跑上 100Mbps
結果被人教育了一番
我有特殊的密集恐懼症
最怕腦袋長滿洞的人

想要吹LKL UML 是沒問題啦
不過我在91yun上看到絕對會代替月亮懲罰你的

另外 這邊可以找到實際YouTube 上的效果
https://www.91yunbbs.com/discussion/comment/1385/#Comment_1385
https://www.91yunbbs.com/discussion/comment/1029/#Comment_1029

CentOS 7选择选项1，安装重启后使用uname -r，还是4.9.50-x86_64-linode86， 当然后面的步骤就没法进行了

linux 新手，有多新，嘛记住的命令也就 apt-get wget sudo 这三个了。
环境：Debian 9 的 KVM VPS上。最新的内核版本 大概是4.13.14。

问题1：
今天更新了一下 3.2.1 发现安装的时候没有暴力模式了哇
似乎安装上去后 没有之前的 暴力版本快。
似乎下载东西需要预热一会儿速度才会慢慢提升。
而且似乎没有以前快 以前可以达到2兆，现在最高1兆左右。
求确认，以及有没有可能加回暴力版本来。

问题2：
另外更新版本的时候 不需要卸载老的版本吧？
（我为了省事没卸载 😂 直接安装了 3.2.1）这样不会有问题吧？

hiformance ovz 回显两个。

[root@localhost home]# virt-what
openvz
lxc

可以改成包含判断

check_ovz(){
	yum update && yum install -y virt-what
	[[ ! "`virt-what`" =~ "openvz" ]] && echo -e "${Error} only support OpenVZ !" && exit 1
}

上一个版本好像是可以支持xen的，最新版本好像不支持了，但是其实还是有一些人用xen的，希望大佬可以支持下，谢谢大佬

如题，我是在OVZ主机CentOS7（64位）系统中安装LKL的，在安装过程中提示：epel/x86_64/primary_db FAILED，但随后的提示中却又提示该文件6.2MB似乎成功下载。按提示安装完成，并且查看状态显示运行成功，但发现它会自行消亡处于非运行状态。
关键的一点，迅影LKL后，frp服务端无法正常运行，连dashboard都无法访问（我的提速端口设置为80-65000），关闭BBR后成功访问

lkl-centos-1.1.0.sh

如题，发现一个符合浪姐不背锅需求的 License，请参考。

License 项目地址：https://github.com/me-shaon/GLWTPL

请问使用这个是几倍发包？

the method would be the same as: #13

but the distinction is, in there, the kernel is v4.15-rc8.

requirement:

• Debian
• 64 bit
• KVM

installation:

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15-rc8/linux-image-4.15.0-041500rc8-lowlatency_4.15.0-041500rc8.201801142030_amd64.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15-rc8/linux-headers-4.15.0-041500rc8_4.15.0-041500rc8.201801142030_all.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15-rc8/linux-headers-4.15.0-041500rc8-lowlatency_4.15.0-041500rc8.201801142030_amd64.deb

dpkg -i linux-image-4.15.0-041500rc8-lowlatency_4.15.0-041500rc8.201801142030_amd64.deb
dpkg -i linux-headers-4.15.0-041500rc8_4.15.0-041500rc8.201801142030_all.deb
dpkg -i linux-headers-4.15.0-041500rc8-lowlatency_4.15.0-041500rc8.201801142030_amd64.deb

update-grub

then, reboot your device, then run these:

wget https://github.com/nanqinlang-tcp/tcp_nanqinlang/releases/download/daily-20180105/tcp_nanqinlang.c

# debian7/8
wget -O Makefile https://raw.githubusercontent.com/nanqinlang-tcp/tcp_nanqinlang/master/Makefile/Makefile-Debian7or8
# debian9
wget -O Makefile https://raw.githubusercontent.com/nanqinlang-tcp/tcp_nanqinlang/master/Makefile/Makefile-Debian9

make && make install

echo -e "\nnet.core.default_qdisc=fq" >> /etc/sysctl.conf
echo -e "net.ipv4.tcp_congestion_control=nanqinlang\c" >> /etc/sysctl.conf
sysctl -p

可以编译通过但是执行insmod会一直卡住，但是用gcc编译后可以正确加载。

till now, Debian has still not release a fix patch for issue Spectre.

there is the according:
https://security-tracker.debian.org/tracker/CVE-2017-5715
https://security-tracker.debian.org/tracker/CVE-2017-5753

but for one issue - CVE-2017-5754, there is a fix version released,
the according is in there:
https://security-tracker.debian.org/tracker/CVE-2017-5754

to fix this issue, you should upgrade your Debian9 to 4.9.65-3+deb9u2 by running this:

apt-get update
apt-get dist-upgrade
reboot

the according of above solution is there: https://www.cyberciti.biz/faq/patch-spectre-vulnerability-cve-2017-5753-cve-2017-5715-linux/