Shell's Home

Dec 5, 2011 - 1 minute read - Comments

python conf 2011无线组网总结和分享

这次python conf 2011结束了,具体成败sting去总结。我主要负责网络部分,把网络部分的总结一下吧。总体来说,网络不算成功也不算失败。在现有条件下,资源没有都发挥出来。但是万幸的是,关键部分还没有掉链子。下面是具体总结。

1.没在场地里面拉好线并且实地测定过所有地点信号的不算部署完毕。

这次的会场平时不允许进入,只能在工作日去,所以只能在会议前一天跑现场。而且进入时没有长网线,墙壁上也没有网线接口。因此是会议前一天先根据具体环境完成了设定,支支下午去买了线,第二天早上部署的。这留下一个严重隐患,我把设备间当成了贵宾室,凭经验估计信号覆盖范围的时候出了错,信号没有覆盖到贵宾室,而且没有考虑门口。第一天的嘉宾和志愿者们,是否感觉信号像渣一样(尤其是杨毅涛)。其实这主要就是因为根本没有考虑到信号覆盖的问题所致的。

要解决这个问题,必须先知道会场结构,包括贵宾室,设备间,签到处等等重要但是部署时又不容易想起来的地方。然后估算需要多少个多强的AP才能覆盖。例如本次的贵宾室,最佳方案是拉40米网线到贵宾室,然后再架一个AP。会场往往没有线,需要自带网线。因此最好是有人知道会场大致结构(手绘亦可,但是标注一下承重墙),然后计算AP位置和网线长度,再去购买。或者直接买一箱网线,配上水晶头打线剪自己做。会议前至少一天去部署,用android测试每个点的信号强度,最好都达到-70db以上。完成后把电线和网线都用胶带封在地上,以防绊倒。

2.足够的AP和信号。

在估算AP和信号的时候,这次经验是,多一个天线,信号强10db。支支的三天线AP信号明显强于我的双天线AP。AP的信号是和距离的立方成反比的,一个AP保证20-30米的无阻挡会场是没问题的。但是每穿一道墙,信号就会下降大约20db。低于-70db就开始出现大量掉包了,-80db的时候tcp重传严重,导致基本无法使用。

一个AP可以接入的客户端是有限的,按照我看下来,大约在50上下(TP-LINK)。这个和事先估计一致。本来我想用6个AP,但是很难凑够这么多,而且带宽不足,就没借这么多。预定就是需要一些人没有设备或者接不上去的,否则就是所有人都不能顺利上网了。结果有一个AP在连接10个设备后就会崩溃,所以等于无法容纳用户。大部分用户都拥挤在同一个AP上,导致踢掉非常严重。会场峰值时刻,300人,有120个设备试图获得IP或者已经获得成功,但是AP在线只有20/50(AP1/AP2),即40%左右的设备被踢掉或者自动断开了Wifi(部分手机为了省电会发生这样的事情)。如果三个AP完好,120人在线刚刚好支撑的起来(20/50/50),但是这样的话连线设备可能还要多一些。

下次部署的时候,除了要考虑信号覆盖问题,还要考虑预留一些AP作为备用。因为会场AP都是民用过去支持,这些设备以前也没有做过大容量测试。我只能说TP-LINK的两台机器很给力,说到50就到50,多了就不能支撑,但是不死机。有台机器就频频死机,这样就需要备机更换。

另外,我们这次最高三个AP,因此分别设定为1/6/11频道就行了。如果AP还要多,请注意让同样频段的设备分到会场的远端。

3.世界真的很麻烦,有的时候有位置却没有电源。

这次电源还算给力,从墙上引出了不少拖线板,基本满足组委需求。至于普通听众就抱歉了,自带拖线板坐到边上的,互相交错给便携设备还能充个电。中间听众只有依靠地接。偏偏地接基本都拉给了组委的摄像机,周围一圈的人可以沾沾摄像机拖线板的光,其他人就只能相信电池续航了。

我们的AP3,第二天搬到了贵宾室那个方向。反正上面只能接不到10个人,给贵宾室小规模用用还可以。结果线只有30米,拉不到贵宾室。合适的位置又没有电源。只好委屈在后门口接了一下,把贵宾室的信号提高了不到10db。

据说有的会场更恶心,只有一两个电源接口。这种会场就必须带够插线板和移动设备来保证电力。

3.留出会议运营所需资源。

这次还算成功的一点,是为大会组委和志愿者/嘉宾保留了一路AP。大会的签到系统,嘉宾演讲都需要Wifi支持,为了让听众上网导致演讲失败就本末倒置了。为嘉宾保留的是AP1,上面还有一些比较活跃,或者着急使用网络的普通听众,一般大约20人左右,相对比较空。可是这个AP又不敢开放给听众使用,一使用就怕嘉宾没法演讲了。

wifi管理者比较怕的问题,主要就是有人使用wifi下载比较大的内容。因此开始的时候,会议需要网络的时候,我都用平板监控网络使用状况。如果有人正在使用大流量,就准备踢人。幸好,大家都很安分(或者是AP上不来)。后来也就放松警惕了,结果老外演讲的时候延迟很厉害,我差点就跑去拔掉AP2的电源了。这会断开所有人的网络,但是演讲者的使用就通畅了。

按照雨苍说的,组委wifi组一个重要任务往往就是封锁各个debian/ubuntu镜像的下载。我们这次没有出现这么恶劣的问题,谢天谢地。

4.会场的网络使用有非常强的峰值效应

这次会议只有2M带宽,因此我一直担心不够。后来开始看看还不错。但是休息的时候一直接到wifi很慢的投诉,空下来一直测不出。我第二天休息的时候去测试了一下,我的天,带宽全满,延时超高。说明演讲者水准很不错,大家专心听会,不怎么用网络。一休息,得,网络不够了。

这个没法解决,要解决只有增加带宽,或者在不休息的时候再使用一些比较耗费流量的业务。一个缓解的办法是使用qos系统,但是这次dir-825没有前往会场,所以没机会调试qos系统。

相对来说,路由器的NAT让我很放心。TP-LINK普通路由器的NAT在支撑80-90人的极限在线的时候仍然很稳健,速度不快是带宽问题,路由器没有崩溃就是万幸。

5.根据具体情况配置。

WEP比较节约资源,所以我们开始配置的是WEP信号。但是测试下来,苹果系统对WEP的支持非常差,基本接不上去。所以就不要节约了,使用WPA/WPA2。

运营商的接入情况比较多变,而且很难控制。这次运营商给我们的是一个内网IP,192.168.1.2。他们已经有了一个路由器在前面。我使用了双重NAT方案,而且避开192.168.1.x网段,来避免修改它们的路由器(我们无权控制)。

这次我们使用的是192.168.0.124网段,三台AP的连接模式是一主多桥。一个主router负责DHCP和NAT,其余的全部当单纯的AP使用。从1到3分别分配0.1-3的IP,2/3的DHCP关闭,1的DHCP从20开始分配起,直到254,共计最高容纳234人在线。20以前的IP让组委的人作为静态IP预留。如果还要多,建议使用192.168.2.0/23网段,最高可以容纳500人不到,足够大部分的会展使用。如果再不够——你们考虑10网段吧。

最后的经验总结。

1.会前勘察真的很重要,尤其是会场平面结构,承重墙位置,会场部署,电源插座位置,一定要提前至少三天确认。提前一天的时候要配好所有AP,备件和网线到会场部署,然后测试信号。

2.会场带宽一定要大,万一实在不够大,想办法ban掉debian/ubuntu的镜像,然后做qos或者squid。

3.自带足够材料,如果没有胶带/接线板/剪刀,那很多事情就要抓瞎。

4.据说TP-LINK之类的路由器在人数多到一定程度的时候会自爆,推荐使用高级设备或者电脑来做NAT/DHCP。不过我至少肯定100人的时候还没问题。