白天测不出什么来，但是你这结果也是有问题。 tcpping 以前最早的用途是用来测试 qos 优先级在网络大流量占用时 tcp 延迟变化，按平时观察的结果搬瓦工 500ms 的情况都很少发生，不大会出现 1600 这样的平均值的。测试时最好保证没访问 vps 上的流量保证不会受 tcp reset 影响，然后最好本地 ping 一下网关确定本地网络是否正常。


TCP connect statistics for 144:1723:
Sent = 500, Received = 500, Lost = 0 (0% loss),
Minimum = 232.15ms, Maximum = 3281.96ms, Average = 324.05ms

Latency Count
232.15 484
392.67 0
553.18 0
713.70 0
874.22 0
1034.73 0
1195.25 7
1355.76 4
1516.28 1
1676.80 3
1837.31 0
1997.83 0
2158.34 0
2318.86 0
2479.38 0
2639.89 0
2800.41 0
2960.93 0
3121.44 0
3281.96 1

TCP connect statistics for 45:1723:
Sent = 500, Received = 473, Lost = 27 (5% loss),
Minimum = 182.98ms, Maximum = 3286.99ms, Average = 299.38ms

Latency Count
182.98 491
346.35 0
509.72 0
673.09 0
836.46 0
999.83 0
1163.20 0
1326.57 1
1489.93 0
1653.30 0
1816.67 0
1980.04 0
2143.41 0
2306.78 0
2470.15 0
2633.52 0
2796.88 0
2960.25 0
3123.62 7
3286.99 1

http://www.coolapk.com/apk/net.hidroid.hitask

最后版本 1.3.0 ，一直用到现在。特别是只有 512m 的电视盒，用它就可以根据内存占用自动终止后台进程，拥有它别无所求。

需要排查的是为什么不在网关布暑 dnsmasq ，所有 dns 查询指向网关跟直接指向外部 dns 还是有速度差别的。以前干扰 8.8.8.8 时直接导致延迟很高甚至掉包，当然导致网页打开时常白页，强制所有 udp 53 dnat 通过网关查询，避免用第三方 dns,没错用第三方 dns 甚至没有查询结果，好多年了因为第三方 dns 遇到网络故障多了，习惯用电信 dns 已经不知道第三方 dns 的意义何在。

搬瓦工的 ip 也有好坏的， 89%相当高了，已经有差不多一个月凤凰城的 144 处于根本不可用状态很怪的下载测试文件流量就掉到 50kb/s 以下，而这个 ip 原先是轻易 400kb/s ，不知道是否本地电信封锁了，昨天差不多 23 点，凤凰城 45 开头的 ip 还可以出乎意料的流畅在手机看 720p 。

嘿嘿，以前还想帮电信洗白，结果连它家的下载测试文件都直接 tcp reset 。。。

平时不用 s.s ，从平时使用 stunnel 观察的情况来看，电信压根不需要什么高科技，同样的配置，只是 80 1723 端口的差别， 1723 只要有点流量那就是满屏的 tcp reset 啊，这种廉价的烂方法却可以让连接快速劣化，话说最恐怖的一次一秒内收到高达 22 次 tcp reset ， HOHO 。现在跑在 80 安逸了，而且要什么无特征，特征就是 TLS 。

什么 dpi XXX 高科技，就只剩下 tcp reset ，恶劣的中国电信网管。

softether 有图形配置界面，用起来比别的 vpn 方便点，但是最近老是受制虚拟的 tap 接口，像上次在 openwrt 路由上跑 softether 虽然用虚拟 3 层路由将 vps 跟家里的路由连接在一起，但是路由下面的 br0 接口想要访问 vps 上的代理又需要用 socat 进行连接，没办法 tap 接口不如真实的物理接口限制感觉越来越多了。

Build a LAN-to-LAN VPN (Using L3 IP Routing)
https://www.softether.org/4-docs/1-manual/A._Examples_of_Building_VPN_Networks/10.6_Build_a_LAN-to-LAN_VPN_(Using_L3_IP_Routing)

http://ww4.sinaimg.cn/large/0060lm7Tgw1eyy61t2l9mj30li0g3gpi.jpg

1,首先肯定得有线测试了，想上 100M 的无线成本还是蛮高的。
2,去除路由里的 qos 设定，有些 qos 会导致只有 60mbps 左右。

好意思说，连搬瓦工都不如，人家怎么也是 99.9%稳定在线，维护提前通知，完整的客服系统。你倒好这是 6 天前的帖子了，这要做业务的网站还以为像 p2p 卷钱跑了，早就倒闭了客户找上门了。

从 android v2 用到 v5 的软件，在进程控制这块无法接受后来那些什么绿色之类的，太复杂了。省电通常前台看不到不该加载的进程就差不多了，再恶劣就直接禁用。

http://ww4.sinaimg.cn/large/0060lm7Tgw1eyx9zzxqorj30800e83zl.jpg
http://ww1.sinaimg.cn/large/0060lm7Tgw1eyxa0670y1j30800e8t9u.jpg
http://ww3.sinaimg.cn/large/0060lm7Tgw1eyx9zetg5ej30800e8jsc.jpg

swip 定时飞行模式，晚上睡觉就不浪费电了。
https://play.google.com/store/apps/details?id=at.fhhgb.mc.swip

这么多年，一直到 android 5.0 还在用 root 后 安装海卓手机加速，如果没意外的话，很大一部分发热来自后台的进程，特别是安卓这种争先恐后要在后台跑的。

天啊，这个问题验证得头都要大了，这篇文档提供了默认的 defaults 全局路由和 routed 白名单(route)。按照它建了个 norouted 黑名单 (no-route)，情况是 windows anyconnect 支持 route 或者 no-route 语法， android 下的 openconnect anyconnect 只支持 route ，通过 android ip route 命令可以查询到路由配置项。没有 iphone 设备未知。仅 200 条的配置项想照顾各种情况还是比较困难的。

做个笔记， Debian 上面装 ocserv （ AnyConnect 服务器端）
http://www.dreamsafari.info/2015/02/ocserv_on_debian/

关于 no-route 解决 ip138.com
服务器完整的配置文件
no-route = 122.13.195.57/255.255.255.255
no-route = 183.238.101.232/255.255.255.255
no-route = 198.105.0.0/255.255.0.0
no-route = 219.128.0.0/255.255.0.0
no-route = 203.130.55.0/255.255.255.0
no-route = 219.128.78.0/255.255.255.0

dnsmasq.conf
address=/ip138.com/outwall

ipset -L #显然通过 nslookup 查询有很大的出入。
122.13.195.57
219.128.78.43
183.238.101.232
219.128.78.41
219.128.78.39
219.128.78.38

汗，刚刚验证了一下真正的地址是 http://1111.ip138.com/ic.asp

而且这个地址要在 vps 上验证才有效，这就造成结果可能有严重的差别，所以有时候出于安全原因还是建议使用全局路由。

# nslookup 1111.ip138.com
Server: 192.168.40.253
Address: 192.168.40.253#53

Non-authoritative answer:
Name: 1111.ip138.com
Address: 183.238.101.232

http://ww2.sinaimg.cn/large/0060lm7Tgw1eywsstwkrxj30h10eymzw.jpg

一般做法是

>nslookup www.ip138.com
服务器: UnKnown
Address: fc00:101:102::1

非权威应答:
名称: yd.ecoma.ourwebpic.com
Addresses: 218.92.221.155
218.92.221.153
218.92.221.152
218.92.221.157
Aliases: www.ip138.com
www.ip138.com.lxdns.com

然后修改 ocserv.conf ，通过浏览 www.ip138.com 看显示的 ip 添加之后的变化
no-route = 218.92.221.0/255.255.255.0

啊。这篇文档主要介绍的是如何用 iptables 屏蔽特定域名的 AAAA 查询，防止查询到 ipv6 地址，导致因为服务器不支持 ip6tables nat 只能用 ipv4 而导致的失败。想实现的效果是就近使用日本 vps ，又可以通过在 vps 实现 vpn 地址欺骗 youtbe 网站来访问有美国 ip 限制的资源。

iptables -I OUTPUT -o eth0 -p udp --dport 53 -m string --hex-string "|07|youtube|03|com|00001c|" --algo bm -j DROP

关于 ocserv 你可以参考下面的文档，不过路由表分流功能没研究过，一直习惯全局翻。 openconnect 不会玩在 windows 下面好像没效果。。。可以试试 anyconnect 客户端 http://dl.xxshe.com/cisco_anyconnect/，但是即便指定了 no route ，下面的规则在 windows 下面可以正常访问 lan ，在 android 下面使用 openconnect 确不可以访问 lan 。
no-route = 192.168.0.0/255.255.0.0
no-route = 10.0.0.0/255.0.0.0
no-route = 169.254.0.0/255.255.0.0
no-route = 172.16.0.0/255.240.0.0

做个笔记， Debian 上面装 ocserv （ AnyConnect 服务器端）
http://www.dreamsafari.info/2015/02/ocserv_on_debian/

Linux 策略路由与多 VPN 并存最佳实践
https://oogami.name/1496/

这种情况一年用过 6 家 vps 都只碰到一次，原因不明。自从在论坛贴了 ip 还在 qq 空间服务器地址图片加上 vpn ，第二天就发现会出现短暂的 ping 断开情况，然后是 vps 被自动挂起说是有高达 3 万并发影响其它用户，不知道是否影响了别人做生意被 ddos 了，第三天仍然持续断 ping ，当多次拔号换 ip 连接时终于被彻底 gfw 了，而且通过 www.17ce.com 测试的话其它地区都正常仅是本地 isp 有问题，服务器更换 ip 解决，大概半个月后又拿到这 ip 正常了。

所以怀疑一开始所有的限制就在本地电信网关上。至于为什么被照顾至今原因不明。

有点困难，因为上外网的电脑才 5 台，而且还不知道交换机有多少带宽，所以不大是外网流量造成的，内网的话， Windows 文件共享，甚至有人从服务器访问文件有有可能 100%占光交换机带宽，所以测试也很简单放个大文件，下载测试延迟看看。另外一种情况是网络中存在组播流量，有些很烂的交换机带宽只有标示的 30%都不到。因为时间比较短暂所以应该是文件共享造成的。
平时宽带型路由器都是网关 qos 设备，这种环境无法排除内网电脑间比如 Windows 文件共享，所以没网管型交换机带流量限制的话或者将 50 台电脑分开隔离阻止电脑间传输文件看起来不好解决。
如果能确定只是服务器传输造成可以考虑将网件架在服务器和交换机时间实现限流，然后用静态路由访问，显然又是大规模更改配置。所以还是问问大家看有哪些带流量控制的可网管交换机。

不是我说的。。。上次说 2015 年 9 月份是 9 月份，后来又变 2016 年 2 月份了。。。传言带来的都是满怀希望，至少过了 9 月份又有新的盼望了。。。

电信正在扩容，美国方向预计 16 年 2 月扩容完毕
http://www.v2ex.com/t/238615#reply25

都没讲到要点上， 300ms 的延迟是完全可以接受的。首先更换千兆口交换机，然后当然是限速了。

根据以前的测试结果在有线网络流量分组达到 100%饱合的可以达到接近 600ms 的延迟。
无线就不说了， 3000ms ，更恐怖的 10000ms 以上的都见过了。

在多人环境最佳的 qos 策略就是实施下行按 ip 限速，防止少量用户占用高达 90%以上的带宽影响多数人的体验，上行根据端口按优先级分类防火 p2p 拥塞，可是市面上的很多流控设备还不如纯 linux 设备用脚本控制灵活。

这种内外网混杂的网络，没高级点的交换机实现 qos 设置感觉这个延迟无法解决，因为说到底延迟还是因为网络饱合情况产生的。

hfsc 下面是如何计算延迟的
8*1500 byte(包大小) / 512000 bit/s(剩余.带宽) = 23.4375ms ，延迟跟包大小有关系，跟带宽也有关系，跟剩余带宽也有关系。

哈哈，其实我一直怀疑是不是本地的 ISP 还有一份黑名单，上次搬瓦工的有个 45 开头的就看似被墙了，半个月后迁回凤凰城又是同一个 ip 正常了。 vulrt jp 目前在我这还行虽然不如 z.com 至少还是有速度的，不像搬瓦工最近晚上基本没速度。

搬瓦工的 Los Angeles 基本没好速度过，能像看 youku 。。。他家是电信吗。反复用 speedtest-cli 测试过的，在国外搬瓦工都是以 MB 为单位传输的，到了国内电信好的维持在 300KB/s ，差得 100KB/s 都没。