关于办公室网<-上<-学<-科的一些优化

起因

可能是由于什么会议要召开了吧,最近上网不稳定的不要不要的,之前用的好好地一个ip突然就跪了,然后就进入了换换换的流程,实在受不了了,好像开个会有多大不了似的。。。

解决方案

后来想了想,还是用豪华版的方案吧,利用供应商的海外专线来进行线路优化,具体思路就是如下:

原本是office——>overseas server原本是这样的连接关系,之所以出现网络断开是因为某黑科技的存在导致了office—| —>overseas server中间的网络断开,毕竟是公网,出海线路在别人手里掌握着,那我不走你的就是了,于是想到了运营商的专线服务,我们现在把连接关系变成这样

office—>local server—>oversears server中间增加一台服务器作为中转,好处有两个主是:

  1. localserver 和office之间的连接时城际网络,比较快
  2. localserver和overseas server是专线比正常的出海线路要稳定快速,并且经过求证是不走黑科技的 :)

于是在overseas上面搭建了server,在local server上面安装了haproxy进行tcp的转发,来讲流量进行处理,嘿嘿,完美。

但是!!!在dns解析这一块儿遇到了问题!在测试dns查询的过程中一直没有成功,突然意识到dns查询使用的协议是udp!猜测应该是使用的udp协议,于是进行确认,首先是在server机器上面抓到了udp的包,再就是知道服务的启动参数需要指定-u来支持udp replay,于是去掉了-u参数重新启动发现相应的udp端口没有了!只有tcp端口孤零零的。。。于是确认tunnel支持的dns查询在使用过程中从始至终使用的udp协议,而不是使用udp接受请求然后通过tcp进行转发。。尴尬的是haproxy是只支持tcp转发的,只好接着找办法了,心想再不济,就用ssh进行转发被,虽然难看一点但是起码能用!

简单看了第二个文档就是nginx官方文档,关于如何配置tcp、udp负载均衡的,点进去看发现原来不仅是nginx plus支持nginx自从Release 9之后,也已经支持了,那就赶紧搞啦,具体步骤如下:

configure时需要增加—with-stream选项用以打开支持stream转发的功能模块,配置的语法和正常配置proxy_pass类似,

1
2
3
4
5
6
7
8
9
10
11
> stream {
> server{
> listen 6667;
> proxy_pass ip:port;
> }
> server{
> listen 6667 udp;#默认是tcp协议需要写出来udp
> proxy_pass ip:port;
> }
> }
>

>

之后就成功了

结语

自由需要代价,其实这只是冰山一角,当初为了优化折腾了一整套的办公室网络,这个有时间再详谈吧:)

再就是,由于涉及敏感词语,因此文章可能写的有点晦涩,万分抱歉

后续

周一来了之后发现网<-上<-学<-科竟然又不行了!!!折腾人吗这不是,不是说好了专线不过的吗!!什么鬼,于是又开始了各种排查的道路。。囧,查查这个查查那个,就跟排查线路故障一模一样啊,结果,嘿,怎么也找不到,发现走一条有问题的ipsec vpn都会比使用公网快且稳定,后来也不知道咋地就想起来去看nginx日志赫然发现!!!WTF,哎。。。没想到问题出现在这里,也是醉,赶紧调整了worker的数量

2017/09/04 18:28:41 [alert] 21845#0: 1024 worker_connections are not enough

2017/09/04 18:28:41 [alert] 21845#0: 1024 worker_connections are not enough

2017/09/04 18:28:41 [alert] 21845#0: 1024 worker_connections are not enough

2017/09/04 18:28:41 [alert] 21845#0: 1024 worker_connections are not enough

2017/09/04 18:28:41 [alert] 21845#0: 1024 worker_connections are not enough

2017/09/04 18:28:41 [alert] 21845#0: 1024 worker_connections are not enough

2017/09/04 18:28:41 [alert] 21845#0: 1024 worker_connections are not enough

2017/09/04 18:28:41 [alert] 21845#0: 1024 worker_connections are not enough

总结

不禁想起来啊,最初调试的时候也遇到过类似的情况,不过当时出问题的是redir模块,日志报错是和fd相关的内容,后来也是经过一番排查使用netstat发现会建立大量连接(毕竟办公室人多),导致了fd耗尽,怎么确认的?是在/proc这个完美的目录下面/proc/pid/limits里面发现进程最大只能申请1024个fd,这哪够啊。。。并且在ss的启动脚本里面发现了ulimit -n 1024!!开发人员真是贴心,哈哈,调大之后恢复正常。

涉及到网络层面的东西真的是也挺复杂的,这也怪不得《Unix网络编程》的块头比《Unix环境高级编程》厚那么多。。。