分享解决openvirtual**网速慢的办法 另外提醒一下大家论坛有些人素质真低

我的***

前几天发帖子求助关于virtual**网速慢的解决办法，可是没有问回，经过几天的研究找到问题所在，分享给大家关于这帖子第一件事说说解决办法，第二件事说一下论坛莫些人的素质问题。没兴趣的直接看第一部分！！
一，解决办法
我也是学习别人的附原地址：https://www.cnbeining.com/2015/0 ... historical-version/

我经常看见小白在网上问，为什么用Openvirtual**连接两个网站的速度比链接速度慢的多，例如，2Mb/s的链接只有400Kb/s的速度，或者百兆只有20Mb/s的速度。有些人推荐将MTU调大到48000，有些人说应该调整mssfix，但是都不管用。有些人说Openvirtual**就这样，老娘就这个速度。扯淡！
一点老黄历
2004年7月。当时发达国家一般家庭网速为256-1024kb/s，在发展中国家网速为56kb/s。Linux2.6.7刚刚发布，带有默认启动TCP窗口大小调节的2.6.8版本一个月前刚发布。Openvirtual**已经活跃地开发了3年，即将发布2.0版本。
一名开发者想加入socket缓冲区的代码，估计是想统一各个系统的缓冲区大小。在Windows下，如果人工设置缓冲区大小，网络适配器的MTU会出错，最终是这个结果：
#ifndef WIN32
    o->rcvbuf = 65536;
    o->sndbuf = 65536;
#endif
技术层面
如果你用过Openvirtual**，你肯定知道Openvirtual**支持TCP和UDP。如果你手工设置TCP连接缓冲区大小到64 KB这么小，TCP 窗口大小调整算法不能将窗口大小调节到64K以上。什么意思？假如你的连接水管大但是延迟高，例如从美国到毛子，ping差不多100ms，用默认的Openvirtual**设置，你的速度肯定不能高于5.12Mb/s。要50Mb/s的速度，缓冲区至少要640 KB。UDP因为没有窗口大小所以快点，但是也快不到哪去。
怎么破？
你已经猜到了，现在的Openvirtual**还在用64 KB的默认缓冲区大小。怎么修？最好的办法是禁止Openvirtual**设置自定义缓冲区大小。在服务器和客户端的配置文件加入：
sndbuf 0
rcvbuf 0
这样缓冲区大小就由操作系统控制了。对于Linux，这个固定值对于TCP是net.ipv4.tcp_rmem 和net.ipv4.tcp_wmem， UDP是net.core.rmem_default 和 net.core.wmem_default 两个值除2.
如果客户端配置文件不能修改，那么你需要从服务器推送更大的缓存大小：
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216”
UDP和TCP不同，没有窗口大小这一说，虽然不是整个系统都需要。但是缓冲区过小也有可能降低速度。如果你把缓冲区调成0后还是慢，你应该要么在系统层面增加缓冲区大小（net.core.rmem_default 和 net.core.wmem_default），或者在服务器推送更大的缓冲区配置：

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216”
但是我用Windows！
如果服务器和客户端都是Windows，应该没有这个bug。
说了这么多，最终解决办法就是在服务器端加入如下配置：
sndbuf 0
rcvbuf 0
这是我修改后的测速结果，以前只有几十k。。。


附：原文
From time to time, I see people asking for help on forums, who have connected 2 remote sites via Openvirtual** and have an awful speed compared to link speed, like 400 Kbit/s with 2 Mbit/s link or 20 Mbit/s with 100 Mbit/s link. Some recommend them to increase MTU on tunnel interface up to 48000, some say they should tune mssfix parameter, but none really helps. Sometimes people say that Openvirtual** is so slow because it’s userspace and this is its’ usual speed. That’s Nonsense!
A little bit of history
It’s July, 2004. Usual home internet speed in developed countries is 256-1024 Kbit/s, in less developed countries is 56 Kbit/s. Linux 2.6.7 has been released not a long ago and 2.6.8 where TCP Windows Size Scaling would be enabled by default is released only in a month. Openvirtual** is in active development for 3 years already, 2.0 version is almost released.
One of the developers decides to add some code for socket buffer, I think to unify buffer sizes between OSes. In Windows, something goes wrong with adapters’ MTU if custom buffers sizes are set, so finally it transformed to the following code:
Python
#ifndef WIN32
    o->rcvbuf = 65536;
    o->sndbuf = 65536;
#endif
A little bit of technical info
If you used Openvirtual**, you should know that it can work over TCP and UDP. If you set custom TCP socket buffer value as low as 64 KB, TCP Window Size Scaling algorithm can’t adjust Window Size to more than 64 KB. What does that mean? That means that if you’re connecting to other virtual** site over long fat link, i.e. USA to Russia with ping about 100 ms, you can’t get speed more than 5.12 Mbit/s with default Openvirtual** buffer settings. You need at least 640 KB buffer to get 50 Mbit/s over that link.
UDP would work faster because it doesn’t have window size but also won’t work very fast.
What should I do?
As you already may guess, the latest Openvirtual** release still uses 64 KB socket buffer size. How should we fix this issue? The best way is to disallow Openvirtual** to set custom buffer sizes. You should add the following code in both server and client config files:
Python
sndbuf 0
rcvbuf 0



After this, socket buffers would be handled by OS. As for Linux and TCP, this is values from net.ipv4.tcp_rmem and net.ipv4.tcp_wmem and for UDP is a fixed value from net.core.rmem_default and net.core.wmem_default, divided by two.
If you can’t change client config, you should push bigger buffer sizes from server:
Python

sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"

UDP is different from TCP. It doesn’t have Window Scale but it doesn’t need it OS-wide, but low buffer sizes may slow down it, too. If you think Openvirtual** is still slow after changing buffer values to 0, you should either increase OS-wide buffer sizes (net.core.rmem_default and net.core.wmem_default) or increase buffer in server config:
Python
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"


But I use Windows!
If you use Windows on both server and client, you should not suffer from this bug.


我是管理员longlo，对方举报你人生攻击，所以以下内容删除，别给管理添麻烦，有问题你们QQ上解决，谢谢。

我的***

！！！！！！

我的***

！！！！！！

讲***

高手，不懂，顶一个~！

a477***

问下路由搭建的怎么破？

我的***

a4778006 发表于 2016-12-26 11:17
问下路由搭建的怎么破？

不建议用路由器，用路由器的话第一可能路由器数据处理能力不够，第二考虑你家的上行带宽问题，一般运营商会限制上行带宽的，比如你家是100M的，可能上行带宽只有10M，这样网速最快也只能是1m每秒左右。

hack***

芝麻分750  求指教啊 可 付费 ，微信 15506430153

whd***

不建议用路由器?这是路由器的网站。

我的***

hackerpp 发表于 2016-12-26 11:54
芝麻分750  求指教啊 可 付费 ，微信 15506430153

付费不至于，你加我吧，18801954135

我的***

whddwdf 发表于 2016-12-26 12:04
不建议用路由器?这是路由器的网站。

事物不断在发展嘛，可能以前是路由器的网站，但现在包容的越来越多

我的***

jjw530 发表于 2016-12-26 14:21
支持楼主的做法

小***

我这边广东电信，表示广东电信OPENvirtual**已经全封了，现在用路由搭了SSR，不得不说，SSR比OPENvirtual**要好得多，连接起来更畅顺，也不会出现自动断开的现象，而且也要比OPENvirtual**省电

鱼是***

呵呵  骗子真多

15386***

牛人啊，果然是大神

我的***

小豪豪 发表于 2016-12-26 20:07
我这边广东电信，表示广东电信OPENvirtual**已经全封了，现在用路由搭了SSR，不得不说，SSR比OPENvirtual**要好得多，连 ...

对的 如果自己用建议搭建ssr稳定性和速度都要大于openvirtual**，现在openvirtual** 用的多是因为openvirtual** 有账号和密码机制，方便那些卖流量的管理和收费！！！我日本的服务器ssr半个月没掉过！