这次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.1/24网段，三台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人的时候还没问题。