现在的代理浏览网页没问题，经常拿youtube测试不知道是否丢包造成什么问题？明明进度条显示缓冲还有蛮长一段可以播放的，可是它就是一卡一卡的。

amazon.com好多年前就存在mtu问题的，一般linux类路由器做过tcpmss调整还是没问题的一直可以访问，tplink就不一定了。

还是用qos省事。linux类路由所有的连接信息都放在cat /proc/net/nf_conntrack里。用shell根据一定条件触发tc change改变流量设置就可以了。

人多流量低看起来很有道理，事实呢？技术上是主动tcp reset过程对连接的弱化达到tcp连接被破坏的情况。所以目前来说解决这个问题的最简单方案就是服务器布署多IP，通过多IP进行轮询连接。看看这日志，人为的技术阻挡。垃圾网络啊。


50秒 4个 51秒 24个（破纪录了，上次的最高纪录是12个） 52秒 8个 53 6个
4秒高达 38 个

2015.08.09 20:40:50 LOG3[1425]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:50 LOG5[1425]: Connection reset: 1971 byte(s) sent to SSL, 11362 byte(s) sent to socket
2015.08.09 20:40:50 LOG3[1431]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:50 LOG5[1431]: Connection reset: 3875 byte(s) sent to SSL, 20117 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1435]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1435]: Connection reset: 1971 byte(s) sent to SSL, 7550 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1429]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1429]: Connection reset: 1971 byte(s) sent to SSL, 8006 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1421]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1421]: Connection reset: 1019 byte(s) sent to SSL, 2880 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1443]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1443]: Connection reset: 1019 byte(s) sent to SSL, 2381 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1441]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1441]: Connection reset: 3875 byte(s) sent to SSL, 16385 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1445]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1445]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1427]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1427]: Connection reset: 1019 byte(s) sent to SSL, 3155 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1439]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1439]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1423]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1423]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1434]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1434]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1424]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1424]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1436]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1436]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:52 LOG3[1438]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:52 LOG5[1438]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:52 LOG3[1430]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:52 LOG5[1430]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:52 LOG3[1442]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:52 LOG5[1442]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:52 LOG3[1432]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:52 LOG5[1432]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:53 LOG3[1440]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:53 LOG5[1440]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:53 LOG3[1422]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:53 LOG5[1422]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:53 LOG5[1446]: Connection closed: 2961 byte(s) sent to SSL, 19861 byte(s) sent to socket
2015.08.09 20:40:53 LOG5[1428]: Connection closed: 543 byte(s) sent to SSL, 189 byte(s) sent to socket

弃用是最简单的方法，用迅雷都是用完就卸载。。。

没办法，现在的软件真的是越来越流氓了，即便潜意识安装过程中非常小心，也有过几次默认在哪个安装界面就钩上的情况，现在的软件做得简直就是小时候玩的游戏 大家来找错，一不小心就给你装上一堆软件，连带卸载的按钮都，搞得这么花，拼视力。

这就是著名的tcp reset。

用它家的第一次飞越加装net_speeder

第二次飞越则是将家里的线路支持ipv6，然后1个ipv6 1个ipv4进行轮询操作，现在下午16：53就靠它来编绎openwrt了，这个时间还能有个60kb-300kb的波动。

有人说墙再高也是可以翻出去的，但是以目前的感觉真的哪一天直接就拔线了，墙再低也越不出去。

要用firefox chrome的时候才发现被什么东西处处挡着，影响速度，影响效率，想来就生气。

不反抗就慢慢被强奸吧，痛并快乐着。

年轻不去看看外面的世界，以后就更不会去折腾了。朋友之类没什么好担心的，处久了就有了。

证书解密是有时效性的，花了大量cpu时间去解密一个一分钟前过时的信息。

一个常用软件对用户证书认证过程。至少在这个软件下面访问页面100%绿色状态。
With certificate authentication, when the connection source computer attempts to connect to the Virtual Hub it presents a user name together with an X.509 electronic certificate. The SoftEther VPN Server checks whether is correct and the connection source computer is only allowed to connect if it passes.
The connection source computer must possess certificate data and a private key (RSA private key) that corresponds to the public key in the certificate to present. Certificate data is sent from the connection source computer to the VPN Server by private key data is not transmitted. Next the VPN Server sends random number data (called challenge values) to the client. When the client receives the data, it signs it by the private key it possesses and returns the data. VPN Server verifies the signature data sent by the client using the public key in the electronic certificate initially received and makes sure that the client computer has the certificate and corresponding private key (if it can't be confirmed, user authentication fails on the spot). It subsequently checks if the certificate subsequently presented by the client matches the attributed defined for each user as user authentication data. You can select either individual certificate authentication or signed certificate authentication as the test method at this time.

softether对机器要求不高的，现在openwrt路由，树莓派之类的都好安装。

A B 公司如果不是直属关系，这种网络结构会造成安全漏洞的。如果未经网管同意还是别这样搞，省得出问题。毕竟将两个lan桥在一起，安全风险非常大。

相对安全的方式就是采用socks5代理，但是socks5代理在下载一些链接时不知道为什么没反应，就需要挂上vpn了，而且如果B公司没有网管参与的话，就必须通过反向连接的方式才能穿透nat，而这同样要求A公司具备公网ip。A公司如果也没公网ip，就需要借助vps C，A<>c<>B。

最好还是征得网管同意，不然被监控到就麻烦了。

用softether吧，文档齐全，功能无敌。
搜一下 Build a LAN-to-LAN VPN (Using L3 IP Routing)
可以实现两个不同网段通过虚拟l3 路由方式桥接在一起，然后使用静态路由。目前家里的openwrt路由就是通过tun0接口跟vps桥接在一起的，中间通过双证书加密连接。
这样的话可以直接在192.168.2.x访问192.168.3.x提供的代理服务，基本是无缝方式，然后再加个privoxy上去就可以进行黑白名单选择性代理。

为什么不问问电信搞什么动态限速。每天见国外流量下降的第一反应就是kill pppd,然后网速又飞快了，接着没速度，接着kill pppd。人家就是把用户当傻瓜。

这个天天有人问。网上比较好的就是flora pac这是个根据国内外路由表进行选择，一刀切所有的国外ip都用代理。
android下一直找不到类似兼容实现，在路由器或者windows安装privoxy，网上有个proxy.action的例子，实现根据域名黑白名单进行选择性代理。然后可以安装smartproxy proxydroid想代理就代理。这些都不关心dns问题，所有代理的解析都将通过远程socks5代理服务器进行解析。
pdnsd也可以通过设置一国内一国外dns服务器通过reject所有的国内服务器ip进行轮询解决cdn问题，不喜欢全局翻，网络容易掉。

这个没办法避免，也不知道如何避免，电信也是大量应用了缓存服务器，下载.net framework就统统的302，网上是有屏蔽的方法，但是操作以后网络更不可访问。所以习惯就好，不要把正常文件变成病毒就谢天谢地了。