简介这是一份面向高校课程设计或期末大作业场景的在线流量分类项目整体采用CNN与LSTM相结合的时空神经网络可对正常业务流量、恶意软件流量及网络攻击流量进行实时识别与可视化展示。项目已完成全部代码调试在导师指导下获评97分下载后即可直接运行适合计算机、网络安全相关专业学生作为从模型构建到实验验证的完整参考。压缩包共24个文件涵盖6个Python源码包含CNN分类器、LSTM分类器、CNNLSTM混合分类器及数据预处理脚本、3个CSV数据文件训练数据、测试数据与预测结果、模型参数与词表文件、实验报告PDF、使用手册docx以及可视化图片等整体约23.7MB目录按功能划分清晰便于按需调用与二次开发。目前已有192人学习下载。资源中附有解析思博伦官方流量包得到的URL级训练数据与测试集可稳定复现93.5%准确率的在线分类结果同时提供完整的训练、测试流程脚本和模型摘要帮助理解CNN空间特征提取与LSTM时序特征提取的结合方式。1. 在线流量分类为什么传统方法接不住现代流量CNNLSTM补上了什么在边界路由器或安全设备上每秒钟要经过成千上万个网络流。你要做的是把其中的视频、网页、P2P下载以及混在里面的恶意流量一条条认出来。传统做法靠端口号猜可如今大量服务走443、随机端口和QUIC端口早已失去区分度DPI能看协议特征但遇到加密流量和高速链路性能和隐私都是问题。基于CNNLSTM的时空神经网络把流量当时空信号来读CNN抓空间特征即报文载荷的字节分布LSTM抓时间特征即流内报文的先后规律。这套方案能在流开始的头几个报文就给出分类结果不必等整条流结束。适合做网络运维、安全分析和相关毕设的人照着源码加文档就能复现训练与在线分类流程。2. 流量数据预处理把PCAP原始报文变成CNNLSTM张量的三个关键环节流量分类项目里真正花时间最多的不是搭模型而是把原始pcap规整成模型能吃的张量。CNNLSTM分类器的输入是固定形状的数值矩阵可pcap里是长度不一、方向混杂、协议各异的二进制报文。下面三个环节是完整链路先做流切分再做报文截断与填充最后做字节归一化。每一步都直接影响模型精度参数也最容易在这三个环节里翻车。源码包里一般也是按这三个函数组织数据准备脚本拿到手先看这几个常量对不对得上你的数据集。2.1 为什么不能把原始pcap直接喂给神经网络神经网络要求定长输入而一个pcap里从64字节的TCP心跳包到1500字节的巨型帧都有。其次IP地址、端口这类头部字段受采集环境影响很大同一台机器换个网段数值族就会整体变化模型学到“某个IP属于某类应用”只是捷径不是泛化能力。再者原始字节取值0到255不做归一化就让卷积层输入数值范围偏大训练初期梯度极易震荡。所以常见做法是只取传输层载荷并且截断到固定长度。头部字段在传统流量分类里能提高不少准确率但换环境后衰减非常明显CNNLSTM方案里我更倾向于放弃头字段纯靠载荷字节分布。底层原因是载荷内容直接反映应用协议本身而头字段反映的是网络拓扑和会话状态后者与我们要分的目标类别并不稳定相关。2.2 流切分与五元组归并从混合报文到结构化流序列拿到pcap后第一步是按五元组把报文聚成流。五元组是源IP、源端口、目的IP、目的端口和传输协议。需要特别注意同一个TCP连接正反两个方向的报文要放进同一条流并全部按时间戳排序这叫双向流归并。原因很简单多数应用是请求-响应模式LSTM必须同时看到请求和响应两个方向的报文才能学到“发请求、等响应、再发请求”这种时间节律。如果只取单向模型看到的是一半对话许多对交互敏感的协议会认错。下面是一份基于dpkt的流切分代码处理标准pcap格式。如果你的抓包文件是pcapng格式先转成pcap再跑dpkt只解析经典pcap封装。import dpkt from collections import defaultdict def build_flows(pcap_path, idle_timeout60.0): 按五元组聚合双向流并按时间戳排序。 idle_timeout: 相邻报文间隔超过该秒数切分为新流。 raw defaultdict(list) # key: 规范化五元组, value: 报文列表 with open(pcap_path, rb) as f: reader dpkt.pcap.Reader(f) for ts, buf in reader: eth dpkt.ethernet.Ethernet(buf) if eth.type ! dpkt.ethernet.ETH_TYPE_IP: continue ip eth.ip if ip.p not in (dpkt.ip.IP_PROTO_TCP, dpkt.ip.IP_PROTO_UDP): continue if ip.p dpkt.ip.IP_PROTO_TCP: l4 ip.tcp else: l4 ip.udp # 双向流归并对端点统一排序保证正反方向是同一条流 a (str(ip.src), l4.sport) b (str(ip.dst), l4.dport) key (ip.p, a if a b else b, b if a b else a) raw[key].append((ts, ip, l4)) flows [] for key, packets in raw.items(): packets.sort(keylambda x: x[0]) # 按时间戳升序 seg [packets[0]] for pkt in packets[1:]: if pkt[0] - seg[-1][0] idle_timeout: flows.append(seg) # 超时切分 seg [] seg.append(pkt) if seg: flows.append(seg) return flows这段代码里有两个参数值得解释。idle_timeout是最常被忽略的TCP长连接可能持续十几分钟如果整条连接算一条流序列过长LSTM在长序列上既慢又难训练。常见取值30到120秒间隔超过就认为会话断开拆成多条子流。五元组key的排序归并是双向流的关键如果直接用原始五元组不排序同一连接的两个方向会被当成两条流训练时方向歧义会让模型时好时坏。另外这个阶段要做一次明显的过滤去掉pure ACK、纯控制报文和纯重复报文。它们载荷几乎为空会稀释流内的有效序列让CNN在补零区浪费计算。最好在聚合前根据TCP标志位过滤只保留带载荷的报文参与建模。2.3 报文截断、填充与载荷归一化变长报文变定长矩阵得到流以后要把流内每个报文转成一个定长向量这里的取舍点是取多长。常见做法是取传输层载荷的前512字节。为什么是512TCP报文负载长度分布非常偏斜大量报文只有几十到几百字节512已经覆盖了相当比例的载荷再长CNN计算量明显上升准确率并不会跟着涨。对明文HTTP、DNS这类流量前几十字节往往就是方法名、域名、查询类型等关键标识512足够充裕。载荷不足512字节的报文要做填充最常用的是补零。注意不要用随机值填充补零能让CNN把填充区学成“恒定的无信息模式”随机填充只会增加训练噪声。最后把字节从uint8归一化到[0,1]浮点整体除以255即可。这一步在CNN训练里属于标配不做归一化时第一层卷积的梯度容易被大数值主导学起来特别费劲。import numpy as np import dpkt MAX_PACKET_BYTES 512 # 单报文载荷截断长度 MAX_PACKETS_PER_FLOW 50 # 单流最多保留报文数 def get_payload(ip): 提取传输层载荷兼容部分dpkt版本data属性解析异常的情况。 try: if ip.p dpkt.ip.IP_PROTO_TCP: return bytes(ip.tcp.data) if ip.p dpkt.ip.IP_PROTO_UDP: return bytes(ip.udp.data) except AttributeError: # 老版本dpkt不自动解析data退回取传输层报文整体切片 if ip.p dpkt.ip.IP_PROTO_TCP: return bytes(ip.tcp) if ip.p dpkt.ip.IP_PROTO_UDP: return bytes(ip.udp) return b def flow_to_tensor(flow_packets): 把一条流转成 [T, M] 的float32矩阵T流内报文数M单报文字节数。 seq [] for _, ip, _ in flow_packets[:MAX_PACKETS_PER_FLOW]: raw get_payload(ip) if len(raw) MAX_PACKET_BYTES: raw raw[:MAX_PACKET_BYTES] # 截断 else: raw raw b\x00 * (MAX_PACKET_BYTES - len(raw)) # 补零 arr np.frombuffer(raw, dtypenp.uint8).astype(np.float32) / 255.0 seq.append(arr) while len(seq) MAX_PACKETS_PER_FLOW: seq.append(np.zeros(MAX_PACKET_BYTES, dtypenp.float32)) # 流级补零 return np.stack(seq) # 形状 [50, 512]MAX_PACKETS_PER_FLOW值得单独说。流内报文数量差异极大一个HTTP短流可能只有几个报文一个视频流可能上万。LSTM展开步数太多计算代价和梯度风险同时上升。常见折中是保留前20到100个报文。只保留前50个长流被截断模型看到的是流的“开头段”这一点和在线分类场景正好一致因为在线推理本来就不应该等整条流结束。想让模型更擅长短流决策就把这个值调到10到20想走长流路线可以调到100但要接受更长的训练时间。预处理脚本写完可以用公开数据集省去自己抓包的麻烦。CICIDS2017、UNSW-NB15这类数据集是常见起点但每份对“流”定义略有差异CSV字段命名、pcap格式都要微调。不要指望一份预处理脚本直接通吃所有数据集至少五元组字段和链路层封装得先核对清楚。3. 时空网络搭建与训练CNNLSTM的PyTorch实现和参数设定预处理把一条流变成 [T, M] 矩阵之后模型要做的就是从矩阵里同时提取两类信息单个报文的局部字节特征以及报文之间的时间依赖。CNNLSTM的组合方式不是随意拼接。下面先讲清结构分工再给一个能直接跑的最小模型。3.1 CNN管空间、LSTM管时间为什么这个结构适合流量流量分类模型的设计有一个关键矛盾。对单个报文要从字节序列里提取局部模式比如HTTP方法名、TLS握手字段、DNS查询类型这些字符串特征这是空间特征对整条流要从报文序列里提取交互规律比如请求-响应的交替节拍、数据包到达的节奏这是时间特征。纯CNN的问题是把所有报文拼成一个长向量做卷积把时间顺序当成空间位置很容易丢掉“先请求后响应”这样的顺序关系纯LSTM的问题是直接把整条流的所有字节喂进去LSTM对局部字节模式的抽象能力远不如卷积序列边界的干扰也大。所以常见组合是CNN对每个报文独立提取特征把空间特征浓缩成一个向量再把一组向量按时间顺序交给LSTM由LSTM在流维度上建模时间依赖。单个报文之间没有卷积关联CNN只管把“一个报文的512字节”压成特征报文与报文的关系全部交给LSTM。这样模型结构清清爽爽哪个模块负责什么问题出了问题也好定位。卷积核大小也有讲究。kernel_size7意味着一次只看7字节的局部模式这类模式对应的是短协议串。如果数据集里频繁出现较长的特征串比如某些TLS扩展字段可以考虑加一个kernel_size15的分支做多尺度卷积让网络同时看短模式和长模式。但我建议先跑通默认配置多尺度是后续优化手段不是起步配置。3.2 最小可跑模型CNNLSTM分类器的PyTorch实现下面是一个最小可实现的双层卷积加单层LSTM分类器。输入是预处理阶段输出的 [B, T, M]即一批流每条流里T个报文每个报文M个字节特征。对新手来说模型定义里最容易出错的地方是view操作和维度对应代码注释里我把每一步的形状变化都标了出来。import torch import torch.nn as nn class CNNLSTMClassifier(nn.Module): def __init__(self, feat_dim512, num_classes8, cnn_out64, lstm_hidden128, num_layers1): super().__init__() # CNN部分对每个报文独立做空间特征提取 self.cnn nn.Sequential( nn.Conv1d(1, 32, kernel_size7, padding3), nn.ReLU(), nn.MaxPool1d(2), nn.Conv1d(32, 64, kernel_size5, padding2), nn.ReLU(), nn.AdaptiveAvgPool1d(cnn_out), # 输出 [B*T, 64, cnn_out] ) # LSTM部分对报文特征序列做时间建模 self.lstm nn.LSTM( input_size64 * cnn_out, hidden_sizelstm_hidden, num_layersnum_layers, batch_firstTrue, ) self.dropout nn.Dropout(0.3) self.classifier nn.Linear(lstm_hidden, num_classes) def forward(self, x): # x: [B, T, M]Bbatch_sizeT流内报文数M报文特征维度 B, T, M x.shape x x.view(B * T, 1, M) # 拆开每个报文单独过CNN cnn_feat self.cnn(x).view(B * T, -1) cnn_feat cnn_feat.view(B, T, -1) # 恢复序列形状 [B, T, 64*cnn_out] lstm_out, _ self.lstm(cnn_feat) # [B, T, lstm_hidden] last lstm_out[:, -1, :] # 取最后时间步 return self.classifier(self.dropout(last))forward里的流程可以拆成三步理解。第一步把batch维度乘上序列长度变成B*T个独立样本分别过CNNCNN输出拉平得到的是“每个报文一个稠密特征”第二步把特征重新折叠成[B, T, feature_dim]恢复序列结构第三步交给LSTM最后取序列末尾的隐状态作为整条流的表示接全连接层分类。batch_firstTrue的作用是让输入输出形状都以batch开头方便检查和调试。参数对应关系要摆清楚cnn_out控制每个报文被投影成多长的特征向量这个值越大LSTM输入维度越高模型容量越大但过拟合风险也上升lstm_hidden是LSTM隐状态维度一般取64到256。num_layers设为1时LSTM内部dropout参数不生效这是PyTorch的API限制只有层数大于等于2才启用别在这个细节上多做文章。3.3 训练策略与参数表让loss平稳下降而不是来回震荡模型定义好后训练循环本身没有特别之处但LSTM模型比纯CNN多一个必须写的操作梯度裁剪。时间步一多反向传播经过展开的LSTM之后梯度范数很容易超过几十不裁剪的话loss会在某个batch直接跳到NaN特别是学习率调大的时候。max_norm设成5.0是一个常用起点。def train_one_epoch(model, loader, optimizer, criterion, device): model.train() total_loss, correct, total 0.0, 0, 0 for x, y in loader: x, y x.to(device), y.to(device) optimizer.zero_grad() logits model(x) loss criterion(logits, y) loss.backward() nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0) optimizer.step() total_loss loss.item() * x.size(0) correct (logits.argmax(dim1) y).sum().item() total x.size(0) return total_loss / total, correct / total交叉熵损失加Adam优化器是分类任务的默认组合初始学习率1e-3。学习率调度常见做法是ReduceLROnPlateau或余弦退火我推荐配合早停一起用验证集loss连续5个epoch不降就停保存最佳权重用于后续在线推理。注意最佳权重的加载要放在整个训练循环结束后统一执行不要在每个epoch内部反复读写模型文件磁盘IO会拖慢训练好几倍。下表是我在做同类项目时常用的参数起点这些值在中小型数据集上基本能先跑出一个正常结果再根据验证集表现微调。参数推荐值调整方向MAX_PACKETS_PER_FLOW50短流多调小到20长流多调到100MAX_PACKET_BYTES512明文协议多可减到256加密流量多可加到768cnn_out64过拟合调小欠拟合调大lstm_hidden128一般不超过256batch_size64数据集小用32内存够大用128learning_rate1e-3loss来回震荡就降到3e-4max_norm5.0出现NaN降到1.0num_classes按数据集标签类别不平衡时配加权交叉熵训练中怎么判断模型状态训练集准确率超过97%、验证集还在85%以下基本是过拟合先加dropout或调小lstm_hidden验证集准确率起伏大、训练集loss下不来检查学习率和输入是否做了归一化验证loss不降但训练loss在降也是过拟合信号。每轮epoch把准确率、loss、学习率记下来后面排查问题会非常有用。4. 在线分类落地从离线训练到实时流量预测的改造要点离线训练完成不代表能直接上线。在线流量分类的关键区别是模型必须在流还在进行时给出判断而不是等整条流结束。这一章的改造要点集中在决策窗口、流缓存和吞吐压测上。4.1 在线分类与离线评估的区别决策窗口是关键离线训练时一条流从头看到尾标签也是整条流的标签。在线场景里流是边发生边到达的模型能看到的只有已经到达的前K个报文。这个K就是决策窗口。K越小决策越快但对模型要求越高因为信息不完整K越大准确率会接近离线水平但可能流已经结束了分类结果对实时管控已经失去意义。常见做法是K取5到20模型在前10个报文左右给出首个判断。还有一个和决策窗口配套的问题一条流的方向是动态的。同一五元组里第一个到达的报文可能是客户端发出的SYN也可能是服务器反向的报文。在线分类器需要在缓存里同时保存两方向的数据按时间戳交错排列。如果在实现时不做交错把两方向分开存放LSTM看到的序列会和训练时不一致推理效果直接打折。4.2 流级缓存与滑窗推理一个可用的在线分类器代码在线分类器的核心是一个流缓存表。每个活动流对应一个缓冲队列新报文到达时归一化后入队累计到决策窗口大小就执行推理并清理缓存。还要处理空闲超时一条流如果后续不再有报文缓存不能一直占内存。import numpy as np import torch class OnlineFlowClassifier: def __init__(self, model, decide_after10, max_buffer100, idle_timeout30.0, devicecpu): self.model model.to(device).eval() self.decide_after decide_after # 收集多少个报文后给出分类 self.max_buffer max_buffer # 单流缓存上限防止内存膨胀 self.idle_timeout idle_timeout # 空闲超时秒 self.device device self.buffers {} # key: 五元组, value: [arr, last_ts] def classify(self, five_tuple, payload_bytes, ts): key five_tuple if key not in self.buffers: self.buffers[key] [[], ts] buf, last_ts self.buffers[key] # 空闲超时清理 if ts - last_ts self.idle_timeout: del self.buffers[key] self.buffers[key] [[], ts] buf self.buffers[key][0] raw payload_bytes[:512] if len(raw) 512: raw raw b\x00 * (512 - len(raw)) arr np.frombuffer(raw, dtypenp.uint8).astype(np.float32) / 255.0 buf.append(arr) self.buffers[key][1] ts if len(buf) self.max_buffer: buf.pop(0) if len(buf) self.decide_after: x torch.tensor(np.stack(buf), dtypetorch.float32).unsqueeze(0) x x.to(self.device) with torch.no_grad(): logits self.model(x) pred logits.argmax(dim1).item() del self.buffers[key] # 决策后释放缓存 return pred return None这个类的设计要点在缓存生命周期。decide_after决定系统在“信息不完整”和“等待成本”之间取哪个平衡点max_buffer防止长流无限增长idle_timeout复用和离线切流相同的参数保证在线和离线对流边界的判定一致。推理时用torch.no_grad()并切到eval()这两行不能省否则显存会被梯度图吃光。在线推理框架的选择要结合流量速率。如果每秒只需要处理几百条新流Python类加GIL足够如果面对万兆链路建议把预处理和推理拆成两个线程池中间用无锁队列衔接或者干脆用ONNX Runtime导出再加载省掉PyTorch的框架开销。先跑通这个最小类再根据压测结果决定要不要换推理后端。4.3 吞吐压测与延迟调优判断模型能否追上真实链路速度上线前要做一次压测。把一段标注好的pcap按报文到达顺序回放给在线分类器统计两个指标单报文最大处理耗时以及从流首包到达输出分类结果的时延。如果平均单报文耗时超过报文到达间隔说明模型跟不上实时速率需要优化。调优方向按成本从低到高排列第一是减小decide_after少等几个报文单流决策更早但吞吐几乎不受影响第二是把输入x直接搬上GPU做batch推理批量处理多个待决策流比一条条推快得多第三是换更小的CNN比如把两层Conv1d减到一层或者把cnn_out从64降到32最后才是上int8量化或更换推理框架。压测时注意别把抓包写盘的开销算进模型耗时先过滤再计时不然数据会误导你。5. 在线流量分类避坑指南五个让人翻车的典型问题这一部分是从多个流量分类项目里沉淀下来的踩坑记录。每条按现象、原因、解决的顺序写对照自己的日志和验证指标就能定位。5.1 类别不平衡准确率90%但目标类一个没抓到现象训练日志显示验证集准确率冲到90%以上但调出混淆矩阵一看某几类恶意流量全被分成了大类召回率基本为零。原因真实流量里样本比例严重偏斜视频和网页可能占八成攻击流量连1%都不到。交叉熵在多数类样本的梯度主导下把决策边界越推越偏模型只需要押注大类就能刷高准确率。解决训练前统计标签分布给少数类设置更高的类别权重用nn.CrossEntropyLoss(weightclass_weights)替代默认交叉熵。若数据量允许也可以对少数类做过采样把每条流的样本重复拼进batch。评估时多看宏平均召回率不要只看准确率。5.2 时间泄漏随机切分训练集导致性能虚高现象从同一个pcap里随机切出70%做训练、30%做验证验证集准确率高达96%。换到另一天新抓的流量准确率直接掉到70%以下。原因同一个时段、同一批主机产生的流量有极强的相关性报文内容、端口特征、时序模式都被同一个网络环境污染。随机切分让训练集和验证集混在同一时段模型等于提前看到了答案。这是时间泄漏比特征泄漏更隐蔽。解决严格按时间切分前70%时间的流做训练后30%做验证。如果pcap跨越多天用前几天的数据训练、最后一天验证。做在线分类评估时这点尤其重要因为真正上线面对的一定是训练集之后的新流量。5.3 加密流量TLS流上CNN学到的东西失效了现象明文HTTP流量分类准确率很高把同一套模型搬到TLS流量上类别混淆严重很多流被归到少量几个大类。原因CNN的卷积核学到的是明文载荷里的可见关键字比如GET、POST、HTTP/1.1。TLS加密后载荷变成伪随机字节这些模式全部消失模型退化成靠报文长度和方向猜。解决对加密流量改用TLS握手阶段的明文信息做补充特征比如ClientHello里的SNI、加密套件列表、证书长度序列。常见的做法是让CNN同时吃“密文载荷”和“握手元数据”两个分支深挖一下可以发现SNI对视频、网页这类域名特征明显的类别区分度相当高。别指望纯载荷模型在加密流量上交出好答卷。5.4 梯度爆炸loss出现NaN或序列变长后不收敛现象训练到某个epochloss突然变成NaN或者把MAX_PACKETS_PER_FLOW从20调到100后训练彻底不收敛了。原因LSTM展开步数增加反向传播路径变长梯度范数指数级增长。学习率稍大一点更新步就冲出了正常范围。如果输入归一化没做好这种爆炸会来得更快。解决训练循环里加上clip_grad_norm_梯度裁剪max_norm从5.0开始仍不稳定就降到1.0。同时确认预处理已经做字节归一化并适当调小学习率到3e-4。还有一个隐藏点把LSTM的batch_firstTrue确认对不然输入维度排列不对也会出现不收敛的诡异现象。5.5 设备指纹污染模型记住设备而非记住应用现象训练集里视频流量几乎来自同一台手机模型验证集准确率高但换一台设备抓包验证视频类识别率大幅下跌。原因不同设备的TCP实现参数、发送窗口、TTL值、报文时间分布都有明显差异。如果训练数据来源单一CNN完全可能不学“视频内容特征”而是学“这台设备的网络行为指纹”。这是典型的端到端模型的捷径学习。解决数据集里尽量混合多种设备的抓包至少两三台不同系统、不同网卡。另一个验证方法是留出一个设备的全部流量做验证集看跨设备准确率是否还能保住。如果跨设备掉点明显说明模型学偏了要从数据侧补而不是从模型侧补。6. 模型验证与进阶准确率会骗人按流评估才知道模型真实水平6.1 按流统计结果报文级指标会误导你流量分类评估最容易犯的错误是按报文统计准确率。一条长流可能占几万个报文如果模型把这条长流分对了报文级准确率就被大幅拉高几十条短流全错在报文级上却看不出什么问题。正确做法是把推理结果还原到流级别每条流只计一次预测统计流级混淆矩阵。如果你做的是在线分类还需要把“未决策就断流的样本”单独记一类这些流在真实场景里是漏报的主要来源。6.2 短流与长流分段测试暴露模型短板另一个可靠的验证手段是按流长度分组看指标。把测试流按报文数分成三组1到5个报文的短流、6到20个报文的中流、20个以上的长流。短流准确率低是正常的在线场景里如果能保住短流不崩溃说明决策窗口设计合理如果长流准确率也低问题多半出在线程方向排序或截断逻辑上。进阶做法是画一条“决策时延与准确率”曲线横轴是decide_after取值纵轴是流级准确率。用这条曲线去和业务方谈“等多少个报文再报警”比拍脑袋定参数有说服力得多。最后分享一个习惯每次改参数记录准验证集结果时把数据集切分seed、流的定义参数、模型超参全写进实验备注。流量分类项目最大的坑不是模型复杂度不够而是实验条件不一致导致两个结果没法对比。我早期就吃过这个亏同一个模型隔三天跑出来的结果差了五个点最后发现是idle_timeout被人改过。先把数据管线的可复现性做扎实再谈模型优化顺序不能反。希望这篇整理能让你少走几步弯路。本文还有配套的精品资源点击获取 CNN+LSTM在线流量分类：从PCAP预处理到实时预测完整指南
简介这是一份面向高校课程设计或期末大作业场景的在线流量分类项目整体采用CNN与LSTM相结合的时空神经网络可对正常业务流量、恶意软件流量及网络攻击流量进行实时识别与可视化展示。项目已完成全部代码调试在导师指导下获评97分下载后即可直接运行适合计算机、网络安全相关专业学生作为从模型构建到实验验证的完整参考。压缩包共24个文件涵盖6个Python源码包含CNN分类器、LSTM分类器、CNNLSTM混合分类器及数据预处理脚本、3个CSV数据文件训练数据、测试数据与预测结果、模型参数与词表文件、实验报告PDF、使用手册docx以及可视化图片等整体约23.7MB目录按功能划分清晰便于按需调用与二次开发。目前已有192人学习下载。资源中附有解析思博伦官方流量包得到的URL级训练数据与测试集可稳定复现93.5%准确率的在线分类结果同时提供完整的训练、测试流程脚本和模型摘要帮助理解CNN空间特征提取与LSTM时序特征提取的结合方式。1. 在线流量分类为什么传统方法接不住现代流量CNNLSTM补上了什么在边界路由器或安全设备上每秒钟要经过成千上万个网络流。你要做的是把其中的视频、网页、P2P下载以及混在里面的恶意流量一条条认出来。传统做法靠端口号猜可如今大量服务走443、随机端口和QUIC端口早已失去区分度DPI能看协议特征但遇到加密流量和高速链路性能和隐私都是问题。基于CNNLSTM的时空神经网络把流量当时空信号来读CNN抓空间特征即报文载荷的字节分布LSTM抓时间特征即流内报文的先后规律。这套方案能在流开始的头几个报文就给出分类结果不必等整条流结束。适合做网络运维、安全分析和相关毕设的人照着源码加文档就能复现训练与在线分类流程。2. 流量数据预处理把PCAP原始报文变成CNNLSTM张量的三个关键环节流量分类项目里真正花时间最多的不是搭模型而是把原始pcap规整成模型能吃的张量。CNNLSTM分类器的输入是固定形状的数值矩阵可pcap里是长度不一、方向混杂、协议各异的二进制报文。下面三个环节是完整链路先做流切分再做报文截断与填充最后做字节归一化。每一步都直接影响模型精度参数也最容易在这三个环节里翻车。源码包里一般也是按这三个函数组织数据准备脚本拿到手先看这几个常量对不对得上你的数据集。2.1 为什么不能把原始pcap直接喂给神经网络神经网络要求定长输入而一个pcap里从64字节的TCP心跳包到1500字节的巨型帧都有。其次IP地址、端口这类头部字段受采集环境影响很大同一台机器换个网段数值族就会整体变化模型学到“某个IP属于某类应用”只是捷径不是泛化能力。再者原始字节取值0到255不做归一化就让卷积层输入数值范围偏大训练初期梯度极易震荡。所以常见做法是只取传输层载荷并且截断到固定长度。头部字段在传统流量分类里能提高不少准确率但换环境后衰减非常明显CNNLSTM方案里我更倾向于放弃头字段纯靠载荷字节分布。底层原因是载荷内容直接反映应用协议本身而头字段反映的是网络拓扑和会话状态后者与我们要分的目标类别并不稳定相关。2.2 流切分与五元组归并从混合报文到结构化流序列拿到pcap后第一步是按五元组把报文聚成流。五元组是源IP、源端口、目的IP、目的端口和传输协议。需要特别注意同一个TCP连接正反两个方向的报文要放进同一条流并全部按时间戳排序这叫双向流归并。原因很简单多数应用是请求-响应模式LSTM必须同时看到请求和响应两个方向的报文才能学到“发请求、等响应、再发请求”这种时间节律。如果只取单向模型看到的是一半对话许多对交互敏感的协议会认错。下面是一份基于dpkt的流切分代码处理标准pcap格式。如果你的抓包文件是pcapng格式先转成pcap再跑dpkt只解析经典pcap封装。import dpkt from collections import defaultdict def build_flows(pcap_path, idle_timeout60.0): 按五元组聚合双向流并按时间戳排序。 idle_timeout: 相邻报文间隔超过该秒数切分为新流。 raw defaultdict(list) # key: 规范化五元组, value: 报文列表 with open(pcap_path, rb) as f: reader dpkt.pcap.Reader(f) for ts, buf in reader: eth dpkt.ethernet.Ethernet(buf) if eth.type ! dpkt.ethernet.ETH_TYPE_IP: continue ip eth.ip if ip.p not in (dpkt.ip.IP_PROTO_TCP, dpkt.ip.IP_PROTO_UDP): continue if ip.p dpkt.ip.IP_PROTO_TCP: l4 ip.tcp else: l4 ip.udp # 双向流归并对端点统一排序保证正反方向是同一条流 a (str(ip.src), l4.sport) b (str(ip.dst), l4.dport) key (ip.p, a if a b else b, b if a b else a) raw[key].append((ts, ip, l4)) flows [] for key, packets in raw.items(): packets.sort(keylambda x: x[0]) # 按时间戳升序 seg [packets[0]] for pkt in packets[1:]: if pkt[0] - seg[-1][0] idle_timeout: flows.append(seg) # 超时切分 seg [] seg.append(pkt) if seg: flows.append(seg) return flows这段代码里有两个参数值得解释。idle_timeout是最常被忽略的TCP长连接可能持续十几分钟如果整条连接算一条流序列过长LSTM在长序列上既慢又难训练。常见取值30到120秒间隔超过就认为会话断开拆成多条子流。五元组key的排序归并是双向流的关键如果直接用原始五元组不排序同一连接的两个方向会被当成两条流训练时方向歧义会让模型时好时坏。另外这个阶段要做一次明显的过滤去掉pure ACK、纯控制报文和纯重复报文。它们载荷几乎为空会稀释流内的有效序列让CNN在补零区浪费计算。最好在聚合前根据TCP标志位过滤只保留带载荷的报文参与建模。2.3 报文截断、填充与载荷归一化变长报文变定长矩阵得到流以后要把流内每个报文转成一个定长向量这里的取舍点是取多长。常见做法是取传输层载荷的前512字节。为什么是512TCP报文负载长度分布非常偏斜大量报文只有几十到几百字节512已经覆盖了相当比例的载荷再长CNN计算量明显上升准确率并不会跟着涨。对明文HTTP、DNS这类流量前几十字节往往就是方法名、域名、查询类型等关键标识512足够充裕。载荷不足512字节的报文要做填充最常用的是补零。注意不要用随机值填充补零能让CNN把填充区学成“恒定的无信息模式”随机填充只会增加训练噪声。最后把字节从uint8归一化到[0,1]浮点整体除以255即可。这一步在CNN训练里属于标配不做归一化时第一层卷积的梯度容易被大数值主导学起来特别费劲。import numpy as np import dpkt MAX_PACKET_BYTES 512 # 单报文载荷截断长度 MAX_PACKETS_PER_FLOW 50 # 单流最多保留报文数 def get_payload(ip): 提取传输层载荷兼容部分dpkt版本data属性解析异常的情况。 try: if ip.p dpkt.ip.IP_PROTO_TCP: return bytes(ip.tcp.data) if ip.p dpkt.ip.IP_PROTO_UDP: return bytes(ip.udp.data) except AttributeError: # 老版本dpkt不自动解析data退回取传输层报文整体切片 if ip.p dpkt.ip.IP_PROTO_TCP: return bytes(ip.tcp) if ip.p dpkt.ip.IP_PROTO_UDP: return bytes(ip.udp) return b def flow_to_tensor(flow_packets): 把一条流转成 [T, M] 的float32矩阵T流内报文数M单报文字节数。 seq [] for _, ip, _ in flow_packets[:MAX_PACKETS_PER_FLOW]: raw get_payload(ip) if len(raw) MAX_PACKET_BYTES: raw raw[:MAX_PACKET_BYTES] # 截断 else: raw raw b\x00 * (MAX_PACKET_BYTES - len(raw)) # 补零 arr np.frombuffer(raw, dtypenp.uint8).astype(np.float32) / 255.0 seq.append(arr) while len(seq) MAX_PACKETS_PER_FLOW: seq.append(np.zeros(MAX_PACKET_BYTES, dtypenp.float32)) # 流级补零 return np.stack(seq) # 形状 [50, 512]MAX_PACKETS_PER_FLOW值得单独说。流内报文数量差异极大一个HTTP短流可能只有几个报文一个视频流可能上万。LSTM展开步数太多计算代价和梯度风险同时上升。常见折中是保留前20到100个报文。只保留前50个长流被截断模型看到的是流的“开头段”这一点和在线分类场景正好一致因为在线推理本来就不应该等整条流结束。想让模型更擅长短流决策就把这个值调到10到20想走长流路线可以调到100但要接受更长的训练时间。预处理脚本写完可以用公开数据集省去自己抓包的麻烦。CICIDS2017、UNSW-NB15这类数据集是常见起点但每份对“流”定义略有差异CSV字段命名、pcap格式都要微调。不要指望一份预处理脚本直接通吃所有数据集至少五元组字段和链路层封装得先核对清楚。3. 时空网络搭建与训练CNNLSTM的PyTorch实现和参数设定预处理把一条流变成 [T, M] 矩阵之后模型要做的就是从矩阵里同时提取两类信息单个报文的局部字节特征以及报文之间的时间依赖。CNNLSTM的组合方式不是随意拼接。下面先讲清结构分工再给一个能直接跑的最小模型。3.1 CNN管空间、LSTM管时间为什么这个结构适合流量流量分类模型的设计有一个关键矛盾。对单个报文要从字节序列里提取局部模式比如HTTP方法名、TLS握手字段、DNS查询类型这些字符串特征这是空间特征对整条流要从报文序列里提取交互规律比如请求-响应的交替节拍、数据包到达的节奏这是时间特征。纯CNN的问题是把所有报文拼成一个长向量做卷积把时间顺序当成空间位置很容易丢掉“先请求后响应”这样的顺序关系纯LSTM的问题是直接把整条流的所有字节喂进去LSTM对局部字节模式的抽象能力远不如卷积序列边界的干扰也大。所以常见组合是CNN对每个报文独立提取特征把空间特征浓缩成一个向量再把一组向量按时间顺序交给LSTM由LSTM在流维度上建模时间依赖。单个报文之间没有卷积关联CNN只管把“一个报文的512字节”压成特征报文与报文的关系全部交给LSTM。这样模型结构清清爽爽哪个模块负责什么问题出了问题也好定位。卷积核大小也有讲究。kernel_size7意味着一次只看7字节的局部模式这类模式对应的是短协议串。如果数据集里频繁出现较长的特征串比如某些TLS扩展字段可以考虑加一个kernel_size15的分支做多尺度卷积让网络同时看短模式和长模式。但我建议先跑通默认配置多尺度是后续优化手段不是起步配置。3.2 最小可跑模型CNNLSTM分类器的PyTorch实现下面是一个最小可实现的双层卷积加单层LSTM分类器。输入是预处理阶段输出的 [B, T, M]即一批流每条流里T个报文每个报文M个字节特征。对新手来说模型定义里最容易出错的地方是view操作和维度对应代码注释里我把每一步的形状变化都标了出来。import torch import torch.nn as nn class CNNLSTMClassifier(nn.Module): def __init__(self, feat_dim512, num_classes8, cnn_out64, lstm_hidden128, num_layers1): super().__init__() # CNN部分对每个报文独立做空间特征提取 self.cnn nn.Sequential( nn.Conv1d(1, 32, kernel_size7, padding3), nn.ReLU(), nn.MaxPool1d(2), nn.Conv1d(32, 64, kernel_size5, padding2), nn.ReLU(), nn.AdaptiveAvgPool1d(cnn_out), # 输出 [B*T, 64, cnn_out] ) # LSTM部分对报文特征序列做时间建模 self.lstm nn.LSTM( input_size64 * cnn_out, hidden_sizelstm_hidden, num_layersnum_layers, batch_firstTrue, ) self.dropout nn.Dropout(0.3) self.classifier nn.Linear(lstm_hidden, num_classes) def forward(self, x): # x: [B, T, M]Bbatch_sizeT流内报文数M报文特征维度 B, T, M x.shape x x.view(B * T, 1, M) # 拆开每个报文单独过CNN cnn_feat self.cnn(x).view(B * T, -1) cnn_feat cnn_feat.view(B, T, -1) # 恢复序列形状 [B, T, 64*cnn_out] lstm_out, _ self.lstm(cnn_feat) # [B, T, lstm_hidden] last lstm_out[:, -1, :] # 取最后时间步 return self.classifier(self.dropout(last))forward里的流程可以拆成三步理解。第一步把batch维度乘上序列长度变成B*T个独立样本分别过CNNCNN输出拉平得到的是“每个报文一个稠密特征”第二步把特征重新折叠成[B, T, feature_dim]恢复序列结构第三步交给LSTM最后取序列末尾的隐状态作为整条流的表示接全连接层分类。batch_firstTrue的作用是让输入输出形状都以batch开头方便检查和调试。参数对应关系要摆清楚cnn_out控制每个报文被投影成多长的特征向量这个值越大LSTM输入维度越高模型容量越大但过拟合风险也上升lstm_hidden是LSTM隐状态维度一般取64到256。num_layers设为1时LSTM内部dropout参数不生效这是PyTorch的API限制只有层数大于等于2才启用别在这个细节上多做文章。3.3 训练策略与参数表让loss平稳下降而不是来回震荡模型定义好后训练循环本身没有特别之处但LSTM模型比纯CNN多一个必须写的操作梯度裁剪。时间步一多反向传播经过展开的LSTM之后梯度范数很容易超过几十不裁剪的话loss会在某个batch直接跳到NaN特别是学习率调大的时候。max_norm设成5.0是一个常用起点。def train_one_epoch(model, loader, optimizer, criterion, device): model.train() total_loss, correct, total 0.0, 0, 0 for x, y in loader: x, y x.to(device), y.to(device) optimizer.zero_grad() logits model(x) loss criterion(logits, y) loss.backward() nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0) optimizer.step() total_loss loss.item() * x.size(0) correct (logits.argmax(dim1) y).sum().item() total x.size(0) return total_loss / total, correct / total交叉熵损失加Adam优化器是分类任务的默认组合初始学习率1e-3。学习率调度常见做法是ReduceLROnPlateau或余弦退火我推荐配合早停一起用验证集loss连续5个epoch不降就停保存最佳权重用于后续在线推理。注意最佳权重的加载要放在整个训练循环结束后统一执行不要在每个epoch内部反复读写模型文件磁盘IO会拖慢训练好几倍。下表是我在做同类项目时常用的参数起点这些值在中小型数据集上基本能先跑出一个正常结果再根据验证集表现微调。参数推荐值调整方向MAX_PACKETS_PER_FLOW50短流多调小到20长流多调到100MAX_PACKET_BYTES512明文协议多可减到256加密流量多可加到768cnn_out64过拟合调小欠拟合调大lstm_hidden128一般不超过256batch_size64数据集小用32内存够大用128learning_rate1e-3loss来回震荡就降到3e-4max_norm5.0出现NaN降到1.0num_classes按数据集标签类别不平衡时配加权交叉熵训练中怎么判断模型状态训练集准确率超过97%、验证集还在85%以下基本是过拟合先加dropout或调小lstm_hidden验证集准确率起伏大、训练集loss下不来检查学习率和输入是否做了归一化验证loss不降但训练loss在降也是过拟合信号。每轮epoch把准确率、loss、学习率记下来后面排查问题会非常有用。4. 在线分类落地从离线训练到实时流量预测的改造要点离线训练完成不代表能直接上线。在线流量分类的关键区别是模型必须在流还在进行时给出判断而不是等整条流结束。这一章的改造要点集中在决策窗口、流缓存和吞吐压测上。4.1 在线分类与离线评估的区别决策窗口是关键离线训练时一条流从头看到尾标签也是整条流的标签。在线场景里流是边发生边到达的模型能看到的只有已经到达的前K个报文。这个K就是决策窗口。K越小决策越快但对模型要求越高因为信息不完整K越大准确率会接近离线水平但可能流已经结束了分类结果对实时管控已经失去意义。常见做法是K取5到20模型在前10个报文左右给出首个判断。还有一个和决策窗口配套的问题一条流的方向是动态的。同一五元组里第一个到达的报文可能是客户端发出的SYN也可能是服务器反向的报文。在线分类器需要在缓存里同时保存两方向的数据按时间戳交错排列。如果在实现时不做交错把两方向分开存放LSTM看到的序列会和训练时不一致推理效果直接打折。4.2 流级缓存与滑窗推理一个可用的在线分类器代码在线分类器的核心是一个流缓存表。每个活动流对应一个缓冲队列新报文到达时归一化后入队累计到决策窗口大小就执行推理并清理缓存。还要处理空闲超时一条流如果后续不再有报文缓存不能一直占内存。import numpy as np import torch class OnlineFlowClassifier: def __init__(self, model, decide_after10, max_buffer100, idle_timeout30.0, devicecpu): self.model model.to(device).eval() self.decide_after decide_after # 收集多少个报文后给出分类 self.max_buffer max_buffer # 单流缓存上限防止内存膨胀 self.idle_timeout idle_timeout # 空闲超时秒 self.device device self.buffers {} # key: 五元组, value: [arr, last_ts] def classify(self, five_tuple, payload_bytes, ts): key five_tuple if key not in self.buffers: self.buffers[key] [[], ts] buf, last_ts self.buffers[key] # 空闲超时清理 if ts - last_ts self.idle_timeout: del self.buffers[key] self.buffers[key] [[], ts] buf self.buffers[key][0] raw payload_bytes[:512] if len(raw) 512: raw raw b\x00 * (512 - len(raw)) arr np.frombuffer(raw, dtypenp.uint8).astype(np.float32) / 255.0 buf.append(arr) self.buffers[key][1] ts if len(buf) self.max_buffer: buf.pop(0) if len(buf) self.decide_after: x torch.tensor(np.stack(buf), dtypetorch.float32).unsqueeze(0) x x.to(self.device) with torch.no_grad(): logits self.model(x) pred logits.argmax(dim1).item() del self.buffers[key] # 决策后释放缓存 return pred return None这个类的设计要点在缓存生命周期。decide_after决定系统在“信息不完整”和“等待成本”之间取哪个平衡点max_buffer防止长流无限增长idle_timeout复用和离线切流相同的参数保证在线和离线对流边界的判定一致。推理时用torch.no_grad()并切到eval()这两行不能省否则显存会被梯度图吃光。在线推理框架的选择要结合流量速率。如果每秒只需要处理几百条新流Python类加GIL足够如果面对万兆链路建议把预处理和推理拆成两个线程池中间用无锁队列衔接或者干脆用ONNX Runtime导出再加载省掉PyTorch的框架开销。先跑通这个最小类再根据压测结果决定要不要换推理后端。4.3 吞吐压测与延迟调优判断模型能否追上真实链路速度上线前要做一次压测。把一段标注好的pcap按报文到达顺序回放给在线分类器统计两个指标单报文最大处理耗时以及从流首包到达输出分类结果的时延。如果平均单报文耗时超过报文到达间隔说明模型跟不上实时速率需要优化。调优方向按成本从低到高排列第一是减小decide_after少等几个报文单流决策更早但吞吐几乎不受影响第二是把输入x直接搬上GPU做batch推理批量处理多个待决策流比一条条推快得多第三是换更小的CNN比如把两层Conv1d减到一层或者把cnn_out从64降到32最后才是上int8量化或更换推理框架。压测时注意别把抓包写盘的开销算进模型耗时先过滤再计时不然数据会误导你。5. 在线流量分类避坑指南五个让人翻车的典型问题这一部分是从多个流量分类项目里沉淀下来的踩坑记录。每条按现象、原因、解决的顺序写对照自己的日志和验证指标就能定位。5.1 类别不平衡准确率90%但目标类一个没抓到现象训练日志显示验证集准确率冲到90%以上但调出混淆矩阵一看某几类恶意流量全被分成了大类召回率基本为零。原因真实流量里样本比例严重偏斜视频和网页可能占八成攻击流量连1%都不到。交叉熵在多数类样本的梯度主导下把决策边界越推越偏模型只需要押注大类就能刷高准确率。解决训练前统计标签分布给少数类设置更高的类别权重用nn.CrossEntropyLoss(weightclass_weights)替代默认交叉熵。若数据量允许也可以对少数类做过采样把每条流的样本重复拼进batch。评估时多看宏平均召回率不要只看准确率。5.2 时间泄漏随机切分训练集导致性能虚高现象从同一个pcap里随机切出70%做训练、30%做验证验证集准确率高达96%。换到另一天新抓的流量准确率直接掉到70%以下。原因同一个时段、同一批主机产生的流量有极强的相关性报文内容、端口特征、时序模式都被同一个网络环境污染。随机切分让训练集和验证集混在同一时段模型等于提前看到了答案。这是时间泄漏比特征泄漏更隐蔽。解决严格按时间切分前70%时间的流做训练后30%做验证。如果pcap跨越多天用前几天的数据训练、最后一天验证。做在线分类评估时这点尤其重要因为真正上线面对的一定是训练集之后的新流量。5.3 加密流量TLS流上CNN学到的东西失效了现象明文HTTP流量分类准确率很高把同一套模型搬到TLS流量上类别混淆严重很多流被归到少量几个大类。原因CNN的卷积核学到的是明文载荷里的可见关键字比如GET、POST、HTTP/1.1。TLS加密后载荷变成伪随机字节这些模式全部消失模型退化成靠报文长度和方向猜。解决对加密流量改用TLS握手阶段的明文信息做补充特征比如ClientHello里的SNI、加密套件列表、证书长度序列。常见的做法是让CNN同时吃“密文载荷”和“握手元数据”两个分支深挖一下可以发现SNI对视频、网页这类域名特征明显的类别区分度相当高。别指望纯载荷模型在加密流量上交出好答卷。5.4 梯度爆炸loss出现NaN或序列变长后不收敛现象训练到某个epochloss突然变成NaN或者把MAX_PACKETS_PER_FLOW从20调到100后训练彻底不收敛了。原因LSTM展开步数增加反向传播路径变长梯度范数指数级增长。学习率稍大一点更新步就冲出了正常范围。如果输入归一化没做好这种爆炸会来得更快。解决训练循环里加上clip_grad_norm_梯度裁剪max_norm从5.0开始仍不稳定就降到1.0。同时确认预处理已经做字节归一化并适当调小学习率到3e-4。还有一个隐藏点把LSTM的batch_firstTrue确认对不然输入维度排列不对也会出现不收敛的诡异现象。5.5 设备指纹污染模型记住设备而非记住应用现象训练集里视频流量几乎来自同一台手机模型验证集准确率高但换一台设备抓包验证视频类识别率大幅下跌。原因不同设备的TCP实现参数、发送窗口、TTL值、报文时间分布都有明显差异。如果训练数据来源单一CNN完全可能不学“视频内容特征”而是学“这台设备的网络行为指纹”。这是典型的端到端模型的捷径学习。解决数据集里尽量混合多种设备的抓包至少两三台不同系统、不同网卡。另一个验证方法是留出一个设备的全部流量做验证集看跨设备准确率是否还能保住。如果跨设备掉点明显说明模型学偏了要从数据侧补而不是从模型侧补。6. 模型验证与进阶准确率会骗人按流评估才知道模型真实水平6.1 按流统计结果报文级指标会误导你流量分类评估最容易犯的错误是按报文统计准确率。一条长流可能占几万个报文如果模型把这条长流分对了报文级准确率就被大幅拉高几十条短流全错在报文级上却看不出什么问题。正确做法是把推理结果还原到流级别每条流只计一次预测统计流级混淆矩阵。如果你做的是在线分类还需要把“未决策就断流的样本”单独记一类这些流在真实场景里是漏报的主要来源。6.2 短流与长流分段测试暴露模型短板另一个可靠的验证手段是按流长度分组看指标。把测试流按报文数分成三组1到5个报文的短流、6到20个报文的中流、20个以上的长流。短流准确率低是正常的在线场景里如果能保住短流不崩溃说明决策窗口设计合理如果长流准确率也低问题多半出在线程方向排序或截断逻辑上。进阶做法是画一条“决策时延与准确率”曲线横轴是decide_after取值纵轴是流级准确率。用这条曲线去和业务方谈“等多少个报文再报警”比拍脑袋定参数有说服力得多。最后分享一个习惯每次改参数记录准验证集结果时把数据集切分seed、流的定义参数、模型超参全写进实验备注。流量分类项目最大的坑不是模型复杂度不够而是实验条件不一致导致两个结果没法对比。我早期就吃过这个亏同一个模型隔三天跑出来的结果差了五个点最后发现是idle_timeout被人改过。先把数据管线的可复现性做扎实再谈模型优化顺序不能反。希望这篇整理能让你少走几步弯路。本文还有配套的精品资源点击获取