抢红包、咻一咻业务量每年数十倍增长，迅速渗透三四线城市及大龄用户
根据微信公布的数据显示，今年除夕到年初五期间，微信红包总收发次数达321亿次。从参与人次来看，相较于羊年春节6天收发32.7亿次，增长了近10倍。最高峰发生在零点过后，每秒钟收发40.9万个红包。支付宝公布的数据显示：除夕夜，支付宝“咻一咻”互动平台的总参与次数达到了惊人的3245亿次，是去年春晚互动次数的29.5倍！在春晚进行当中的21点09分，用户的参与热情达到了顶峰，“咻一咻”峰值达到210亿次/分钟。
从地域分布看，虽然今年春节最喜欢发红包的前三个城市是一线的北京、深圳和广州，但是在发红包排名前二十的城市中，三四线城市数已接近一半。支付宝亦有类似的情况，除夕当晚支付宝活跃用户在三四线城市占比从节前的48%上升到64%，提升了16个百分点。
从参与人群的年龄分布来看，使用微信红包的用户年龄层在悄然扩大，微信方面称，为参与猴年春节红包狂欢，不少爷爷奶奶辈也注册微信账号并绑定了银行卡，“60后”发送红包超1.66亿次。支付宝亦有类似情况。50后、60后、70后在支付宝用户中的占比从节前的15%上升到33.5%。
红包类交互业务成为常态，移动互联网流量模型趋于高并发、高新建、长连接
数十倍于去年的互动频次、地域分布的广泛性及年龄层的扩大表明，越来越多的用户正在接纳移动互联网时代指尖上的“新年俗”。大并发的交互业务将成为常态，移动互联网流量模型已经悄然变化。
微信红包类业务分析
摇一摇：2个新建连接，2700Byte流量，平均包长约为100byte
- 1次摇一摇产生1个TCP连接，报文交互9个，1s内完成，数据量811Byte
- 摇出结果，产生1个TCP连接，交互报文16个，2s内完成，数据量1899Byte
发红包：4个新建连接，5000Byte流量，平均包长约为140byte
- 点击红包页面，新建2个TCP连接，数据量2890Byte，每次连接交互9~10个报文
- 输入金额，新建2个TCP连接，数据量1778Byte
- 支付成功，新建1个TCP连接，数据量1236Byte
抢红包：2个新建连接，4000Byte流量，平均包长约为400byte
- 点击抢红包，新建1个TCP连接，数据量1380Byte
- 抢红包成功，新建1个TCP连接，同时在微信长连接上交互4个数据报文，数据量2859Byte
- 抢红包失败，新建1个TCP连接，数据量1765Byte
支付宝红包类业务分析
咻一咻：2个新建连接，5100Byte流量，平均包长约为100byte
- 1次咻一咻动作，新建1个TCP连接，交互5个报文，数据量724Byte
- 咻出数据后，会收到服务器发回的重定向网址
- 基于重定向网址发起一次dns请求，如果已有DNS缓存，不需要该步骤
- 访问对应网址，新建1个TCP连接，数据量4429Byte
发红包：1个新建连接，1000Byte流量，平均包长约为100byte
- 发一次红包新建1条TCP连接，一次会话交互9~10个报文，90S后服务器发RST断链老化会话，数据量1046Byte
抢红包：不新建连接，3600Byte流量，平均包长为400byte
- 抢成功，不新建连接，在长连接上一次交互6~7个报文，2519Byte
- 没抢成功，不新建连接，在长连接上一次交互2~3个报文，1128Byte
总体影响有：
◆大量用户频繁操作手机参与活动，产生海量新建会话
◆会话长时间保持，大量长连接，并发会话量居高不下
◆移动APP产生大量100-400Byte小包，网络中小包数量增加
因此，为了应对海量会话对网络设备性能的挑战，防火墙业务需要做好规划，提前扩容。
不同网络设备的转发机制和工作原理
- 交换机：二层基于MAC转发，二层转发芯片处理
- 路由器：三层基于IP转发，NP转发芯片处理
- 防火墙：四层基于会话表，应用层CPU处理
防火墙性能关键参数
- 新建连接数：每条流首次经过防火墙时，根据五元组，新建会话表。
- 并发连接数：最大能够同时处理的连接会话个数
- 吞吐量：单位时间内通过防火墙的流量
可见，防火墙设备由于工作在网络模型的第四层，需要为用户的每个连接建立会话并维护会话表。进行防火墙设备容量规划设计时，必须综合考虑新建连接数、并发连接数、吞吐量等多个指标。
尤其在移动互联网场景，各种红包、“摇一摇”、“咻一咻”等业务会突发海量的新建和并发连接数，网络中的新建会话、并发会话数比平时增加3-5倍，而网络流量仅略有上升，并没有同等比例的显著增加。
而对于防火墙类设备，虽然从吞吐量上看不到明显的扩容需求，但很可能已导致现网会话数成倍激增濒临上限，需要重点关注及时扩容，避免会话突发时刻性能不足，影响用户的互联网数据业务。
