Open GoogleCodeExporter opened 9 years ago
这是ppp over ssh
的一个缺陷。ssh使用了tcp协议,这就意味着所有要通过vpn接��
�(ppp over
ssh接口,下同)转发的用户数据都是被可靠、有序的传输的��
�不管这些数据是tcp、udp、还是icmp。vpn可靠、有序传输数据带
来的负面影响就是,如果ssh client 到ssh
server之间(以下简称client、server)带宽不稳定或带宽几乎被��
�满产生丢包时,路由器上的tcp协议栈会按照规则重传这些数�
��,后序到来的包要等待这些包传输完毕,或重传次数达到上
限被丢弃后才得以传输,这就会带来延时大的问题。如果重��
�过程中,用户端的tcp协议等待也超时了,也会重传发送数据�
��路由器要再次传递一次相同的数据,一定程度上会造成带宽
浪费,但是是非常有限的。在vpn流量比较大的时候,你可能��
�发现在路由器上ping
8.8.8.8延时会非常大,但是丢包却不严重,因为icmp被ssh隧道可
靠、有序的传输了,所以你所描述的问题不是因为dnsmasq,而�
��ppp over ssh 的问题。
可以尝试在路由器上做以下优化,但估计效果有限:
{{{
echo 1 >/proc/sys/net/ipv4/tcp_retries1
echo 1 >/proc/sys/net/ipv4/tcp_retries2
echo 1 >/proc/sys/net/ipv4/tcp_low_latency
echo 524288 >/proc/sys/net/core/wmem_default
echo 1048576 >/proc/sys/net/core/wmem_max
}}}
Original comment by autovpn2014
on 21 Nov 2014 at 2:33
感谢这么快的回答。我回去尝试。
另外,最近还发现一个问题,服务器端的PPP连接(interface)��
�些时候会僵死,导致会出现多个童一样的ppp,比如:ppp0,ppp1,
ppp2...ppp10都是同一个客户端的,这时候vpn就不通了。必须杀��
�服务器端所有pppd进程才有效果。
Original comment by jiekec...@gmail.com
on 21 Nov 2014 at 3:31
这个问题可能和系统有一定关系,一般情况服务器端的ppp是ss
hd
进程的子进程,当客户端连接断开了,sshd相应进程也会消失�
��此sshd进程的子ppp进程也应该被杀死才对,如果ppp变僵尸进��
�了,可能是ppp在执行一些不可中断的IO操作时被杀掉的,但��
�ppp
的IO无非是正常的网络读写,一般会很快完成,如果出异常可
能会导致ppp成为僵尸进程。这只是我的一个猜测,在我使用��
�程中没遇到过这种情况,服务器是xen vps 系统是 debian 7
Original comment by autovpn2014
on 21 Nov 2014 at 3:45
我们用的vps是CentOS 6.5
64bit,目前只有一台机器出现这样的情况。顺便问一句,pvpn��
�autovpn有什么关系?
Original comment by jiekec...@gmail.com
on 21 Nov 2014 at 3:58
autovpn-for-openwrt 是我自己给项目起的名,vpn部分(ppp over
ssh)最初是移植了名叫pvpn的一个shell脚本实现的。最新的版��
�里,已经放弃pvpn脚本,取而代之的是把 vpn
部分直接加入到openwrt内部,简化了配置过程。但核心的ppp
over ssh 来实现vpn连接的思路是没变的。
Original comment by autovpn2014
on 21 Nov 2014 at 4:07
/////
这是ppp over ssh
的一个缺陷。ssh使用了tcp协议,这就意味着所有要通过vpn接��
�(ppp over
ssh接口,下同)转发的用户数据都是被可靠、有序的传输的��
�不管这些数据是tcp、udp、还是icmp。vpn可靠、有序传输数据带
来的负面影响就是,如果ssh client 到ssh
server之间(以下简称client、server)带宽不稳定或带宽几乎被��
�满产生丢包时,路由器上的tcp协议栈会按照规则重传这些数�
��,后序到来的包要等待这些包传输完毕,或重传次数达到上
限被丢弃后才得以传输,这就会带来延时大的问题。如果重��
�过程中,用户端的tcp协议等待也超时了,也会重传发送数据�
��路由器要再次传递一次相同的数据,一定程度上会造成带宽
浪费,但是是非常有限的。在vpn流量比较大的时候,你可能��
�发现在路由器上ping
8.8.8.8延时会非常大,但是丢包却不严重,因为icmp被ssh隧道可
靠、有序的传输了,所以你所描述的问题不是因为dnsmasq,而�
��ppp over ssh 的问题。
/////
仔细研究了上面这段话,我感觉与我说的最初的问题还有区��
�:
我的问题是,发觉dnsmsaq有性能瓶颈。因为在出现dns反馈慢的�
��候,vpn隧道内的连接速度还是很正常且稳定的(隧道内的pin
g包一个不丢,且一直保持在100ms以内),而是正常的国内访��
�会慢,尤其是dns请求慢(一旦dns请求完成,显示网页时非常�
��速的)。由此,我才推断是dnsmasq的性能问题。
或许是我们的设备处理性能太低。情况是这样的:最初,我��
�只是启用了openwrt的单核处理,cpu
load一直处于比较高的状态(Load average: >1, >1, >1),CPU: 0%
idle,dns请求慢的问题非常明显,有时候回应需要3-5秒。接着�
��我们把openwrt重新编译了双核处理,果然性能有所提升(Load
average比较低),CPU: 50%
idle。但是,还会出现dns请求慢(1-3秒),客户体验严重受到�
��响。
由此,我基本判断openwrt在启用ppp over
ssh时,vpn隧道内的处理很不错,效果很好。但是,当设备负��
�比较大时,openwrt本身启用的一些服务会受到影响(比如:dns
masq响应慢)。
另外,再咨询一下:当启用了两条vpn时,后面启动的vpn会作��
�主线路,前面启动的vpn作为备份线路。当主线路断开时,主�
��路路由自动失效,自动切换到备份线路。是否有什么解决方
案可以像multiWan做负载均衡,在两条vpn之间轮训请求?
Original comment by jiekec...@gmail.com
on 21 Nov 2014 at 4:27
/////
这是ppp over ssh
的一个缺陷。ssh使用了tcp协议,这就意味着所有要通过vpn接��
�(ppp over
ssh接口,下同)转发的用户数据都是被可靠、有序的传输的��
�不管这些数据是tcp、udp、还是icmp。vpn可靠、有序传输数据带
来的负面影响就是,如果ssh client 到ssh
server之间(以下简称client、server)带宽不稳定或带宽几乎被��
�满产生丢包时,路由器上的tcp协议栈会按照规则重传这些数�
��,后序到来的包要等待这些包传输完毕,或重传次数达到上
限被丢弃后才得以传输,这就会带来延时大的问题。如果重��
�过程中,用户端的tcp协议等待也超时了,也会重传发送数据�
��路由器要再次传递一次相同的数据,一定程度上会造成带宽
浪费,但是是非常有限的。在vpn流量比较大的时候,你可能��
�发现在路由器上ping
8.8.8.8延时会非常大,但是丢包却不严重,因为icmp被ssh隧道可
靠、有序的传输了,所以你所描述的问题不是因为dnsmasq,而�
��ppp over ssh 的问题。
/////
仔细研究了上面这段话,我感觉与我说的最初的问题还有区��
�:
我的问题是,发觉dnsmsaq有性能瓶颈。因为在出现dns反馈慢的�
��候,vpn隧道内的连接速度还是很正常且稳定的(隧道内的pin
g包一个不丢,且一直保持在100ms以内),而是正常的国内访��
�会慢,尤其是dns请求慢(一旦dns请求完成,显示网页时非常�
��速的)。由此,我才推断是dnsmasq的性能问题。
或许是我们的设备处理性能太低。情况是这样的:最初,我��
�只是启用了openwrt的单核处理,cpu
load一直处于比较高的状态(Load average: >1, >1, >1),CPU: 0%
idle,dns请求慢的问题非常明显,有时候回应需要3-5秒。接着�
��我们把openwrt重新编译了双核处理,果然性能有所提升(Load
average比较低),CPU: 50%
idle。但是,还会出现dns请求慢(1-3秒),客户体验严重受到�
��响。
由此,我基本判断openwrt在启用ppp over
ssh时,vpn隧道内的处理很不错,效果很好。但是,当设备负��
�比较大时,openwrt本身启用的一些服务会受到影响(比如:dns
masq响应慢)。
另外,再咨询一下:当启用了两条vpn时,后面启动的vpn会作��
�主线路,前面启动的vpn作为备份线路。当主线路断开时,主�
��路路由自动失效,自动切换到备份线路。是否有什么解决方
案可以像multiWan做负载均衡,在两条vpn之间轮训请求?
Original comment by jiekec...@gmail.com
on 21 Nov 2014 at 4:35
为什么刚刚发布的comment不见了?
Original comment by jiekec...@gmail.com
on 21 Nov 2014 at 4:37
我刚刚测试了下上面的优化参数,效果的确不明显,然后暴��
�的把tcp 重传设置成了0
echo 0 >/proc/sys/net/ipv4/tcp_retries1
echo 0 >/proc/sys/net/ipv4/tcp_retries2
这样设置的后果就是tcp没有了重传机制,会对路由器自身进��
�发出的tcp数据包有影响。然后手机上看youtube,在路由器上pin
g 8.8.8.8
就会出现严重丢包,但我猜测,这对dns解析慢的改善还是有��
�,因为dns查询的包如果真在互联网上丢了,应用程序再次发�
��查询也是有一定延时的。总之问题的根源在于,路由器到ssh
server之间的带宽有限且不稳定。
Original comment by autovpn2014
on 21 Nov 2014 at 4:37
因为一些原因这个项目删除重建了,刚刚发布时的 comment
也都没有了
Original comment by autovpn2014
on 21 Nov 2014 at 4:39
仔细研究了上面这段话,我感觉与我说的最初的问题还有区��
�:
我的问题是,发觉dnsmsaq有性能瓶颈。因为在出现dns反馈慢的�
��候,vpn隧道内的连接速度还是很正常且稳定的(隧道内的pin
g包一个不丢,且一直保持在100ms以内),而是正常的国内访��
�会慢,尤其是dns请求慢(一旦dns请求完成,显示网页时非常�
��速的)。由此,我才推断是dnsmasq的性能问题。
或许是我们的设备处理性能太低。情况是这样的:最初,我��
�只是启用了openwrt的单核处理,cpu
load一直处于比较高的状态(Load average: >1, >1, >1),CPU: 0%
idle,dns请求慢的问题非常明显,有时候回应需要3-5秒。接着�
��我们把openwrt重新编译了双核处理,果然性能有所提升(Load
average比较低),CPU: 50%
idle。但是,还会出现dns请求慢(1-3秒),客户体验严重受到�
��响。
由此,我基本判断openwrt在启用ppp over
ssh时,vpn隧道内的处理很不错,效果很好。但是,当设备负��
�比较大时,openwrt本身启用的一些服务会受到影响(比如:dns
masq响应慢)。
另外,再咨询一下:当启用了两条vpn时,后面启动的vpn会作��
�主线路,前面启动的vpn作为备份线路。当主线路断开时,主�
��路路由自动失效,自动切换到备份线路。是否有什么解决方
案可以像multiWan做负载均衡,在两条vpn之间轮训请求?
Original comment by jiekec...@gmail.com
on 21 Nov 2014 at 4:40
comment
#6,#7不见了,是你们删除了吗?另外,可以申请跟你们一起�
��究这个项目吗?
Original comment by jiekec...@gmail.com
on 21 Nov 2014 at 4:42
我没删除。
两台线路主备我有想过,修改routeadd.sh等一些脚本就行。
影响dnsmasq
响应慢的原因有可能路由器条目多较多,routeadd.sh执行较慢,
新版本autovpn-for-openwrt的routeadd.sh去掉了对ip命令的依赖,换用
了route命令去检查ip是否已经存在路由表,效率相对使用ip
命令时有所降低,你可以安装好ip包(opkg install
ip),然后把/usr/bin/routeadd.sh文件换成以下内容试试:
{{{
#!/bin/sh
IPS=`echo $1|tr "," "\n"`
DEV=`ifconfig |grep -e "pos-"|cut -d" " -f 1|head -n 1`
ROUTES=/tmp/routes.txt
if [ -n "$IPS" ] ;then
for ip in $IPS ;do
ip route get $ip|grep -q $DEV
if [ $? -ne 0 ];then
echo "add $ip to route table"
ip route add $ip dev $DEV
echo "$ip" >>$ROUTES
fi
done
fi
}}}
DEV= 后面也可以直接替换成你的vpn接口名。
另外你是在x86平台下使用,执行脚本应该更快才对,在我的wr
703n路由器上路由条目在500左右,dns查询也很快,难道你禁用d
nsmasq的缓存了?
Original comment by autovpn2014
on 21 Nov 2014 at 5:32
我的单个vpn启动,正常情况有3000-5000条路由,感觉好多啊。
1、我没有用你的新方案(ip
命令方式)尝试,现在上班时间,不能断网;
2、dnsmasq缓存?是什么?没看到这个配置选项。
Original comment by jiekec...@gmail.com
on 21 Nov 2014 at 5:39
那你的路由条目确实够多的,这样看来多半是因为routeadd.sh脚
本的性能下降导致的。
脚本替换不会影响网络,但操作要快。上面的脚本内容不包��
�{{{ }}} 符号,注意一下。
在我路由器上测试换用ip命令后快了一点。新版的这个变动是
为了降低部署的复杂度,如果真是这个问题导致dns查询慢后��
�就考虑再改回去。
dnsmasq
有缓存查询结果的功能,默认缓存150个域名的结果,尝试把��
�个值改大一点试试,另外在把cache
时间改长一点,对上网的影响应该会降低很多。具体操作是��
�下面内容加到/etc/autovpn/vpn.conf里,然后重启dnsmasq
max-cache-ttl=3600
cache-size=2000
Original comment by autovpn2014
on 21 Nov 2014 at 6:04
你所谓的部署复杂度就是增加了ip模块而已,这个不是大问题
吧。
我在dnsmasq中,把dns-forward-max=1000设置了。
你的两个配置也加进去了。再看看效果。
Original comment by jiekec...@gmail.com
on 21 Nov 2014 at 6:14
dnsmasq优化配置,以这条为准吧:
cache-size=2000
neg-ttl=3600
max-ttl=3600
max-cache-ttl=3600
auth-ttl=3600
Original comment by autovpn2014
on 21 Nov 2014 at 6:20
影响性能的主要还是routeadd.sh,替换它改善最明显
Original comment by autovpn2014
on 21 Nov 2014 at 6:21
系统CPU资源占用比较靠前的主要进程有:
ssh,这个加解密和保持tcp连接,利用率高正常
dnsmasq:作为dns转发器和查询器,利用率高也正常
修改成ip后,这个占用少了,几乎看不见排在前面了
routeadd.sh
Original comment by jiekec...@gmail.com
on 21 Nov 2014 at 6:30
那就再观察一下吧。
有些路由器的flash比较小,遇到过一次就差几十K装不进去的��
�况,而且我自己给朋友部署的时候经常漏掉ip包,所以干脆��
�把ip包去掉了,有时间我更新回去。
Original comment by autovpn2014
on 21 Nov 2014 at 6:35
小路由器可以自己做个小的固件,去掉不需要的包,去掉ipv6�
��就保留基本系统,4M
flash的路由器基本都能装上ip和你的dnsmasq。
Original comment by jiekec...@gmail.com
on 21 Nov 2014 at 6:42
不错的建议。
几千条的路由条目对路由器来说不是太大问题,因为是放在��
�存查询也是以二进制的方式进行。
dnsmasq
的patch代码现在的实现很比较拙劣,性能不是最优的,后续也
会改进。
Original comment by autovpn2014
on 21 Nov 2014 at 6:52
目前,还是会发现客户端连接服务器的ssh意外断开了,服务��
�端ssh子进程并未被杀掉,ppp进程也一样存在。客户端会继续�
��起ssh连接,建立新的ppp,导致会有两条一样接口地址的ppp连
接。目前能做的就是把所有的pppd进程杀掉,难免会有误杀,�
��致所有的ssh和ppp重新建立。这时,会出现很多的伪ssh僵尸进
程。请问有什么办法可以消除这个现象?
Original comment by jiekec...@gmail.com
on 15 Dec 2014 at 3:11
在出国线路不太好的时候我的ssh也会频繁断开,但是不会出��
�你说的这种情况,建议你升级一下ssh试试,为了避免操作不�
��导致无法ssh连接服务器,建议新编译的ssh单独监听在不同的
端口上测试。
Original comment by autovpn2014
on 16 Dec 2014 at 1:20
Original issue reported on code.google.com by
jiekec...@gmail.com
on 20 Nov 2014 at 3:14