简介《LTE 抓包分析指导手册》是一份面向通信工程师与网络优化人员的 PDF 文档专注于解决 LTE 网络中信令面与用户面数据包的捕获和分析难题。手册系统梳理了 UU 口、ENBeNodeB以及核心网三类场景的抓包前准备与具体操作流程既支持使用测试电脑配合 Wireshark 抓包也介绍了通过安卓手机实现 UU 口抓包的方法。数据分析部分重点讲解了单业务/线程过滤、利用 IO GRAPHS 与 Apply as Filter 进行丢包和乱序分析以及无线侧 BLER 与丢包联合定位的思路可直接用于日常网络排障与性能优化。这份资源包共包含 1 个 PDF 文件压缩包大小仅 1.72MB便于下载和离线查阅。目前已有 294 人学习适合需要快速上手 LTE 抓包或完善分析方法的通信从业者。1. LTE 速率不达标先别急着调天线三端抓包才是定位利器SINR 在 25 以上、RSRP 也正常无线环境挑不出毛病但下行速率就是跑不满预期——这种“无线好、速率差”的定位难题做 LTE 优化的工程师应该都不陌生。端到端的网优工具和性能统计在系统发展初期往往不够完善你只能看到“速率低”这个结果却不知道问题出在终端处理能力、S1 传输质量、核心网协同还是无线丢块上。面对这种情况最直接有效的定位手段就是在 Uu 口、eNB、核心网三端同时抓包通过报文级别的数据对比把排查范围从整条链路缩到某一个网元。这份 LTE 抓包分析指导手册讲的就是这套三端联合抓包与数据分析的方法准备工作到位的前提下半天就能定位问题网元。适合网优工程师、测试工程师和做 LTE 协议分析的人阅读。2. 抓包前的准备工作从电脑选型到测试卡静态 IP2.1 Uu 口准备测试电脑方案与 Wireshark 网卡检查先说结论如果用测试电脑抓 Uu 口电脑选型比软件安装更容易翻车。手册给的经验上限是“每次录取的行数不超过 80 万行约 800M 的数据”超过这条线轻则系统反应迟钝重则点了停止抓包却卡死保存按钮按了半天没反应之前抓到的东西全丢。我拆这份手册时专门留意了这条——它不是凭空给的Wireshark 在解析超过 800M 的 pcap 文件时UI 线程会被大量 TCP 包的重组和统计运算吃掉内存占用暴涨保存时又要做一次全量写入确实是高危操作。新手最容易犯的错是一开抓包就不停一个业务从头录到尾流量大点的站点随便就上千兆。选型上优先看硬盘随机读取能力和 CPU 处理能力其次是内存。我一般会按业务段分段保存每段控制在 80 万行以内而不是录一大段再手工拆。测试前把无关后台任务关掉避免抓包过程中系统卡顿这也是容易被忽略的一环。准备工作的第二步是装驱动、确认网卡能被 Wireshark 看到。MIFI 这类测试终端的驱动装好后网络连接成功时打开 Wireshark 菜单Capture - Interfaces应该能看到对应测试终端驱动的 Interface而且在浏览网页的情况下那个接口的 Packets 计数在涨。这一步看着简单实际上不少工程师跳过它直接开抓结果 Wireshark 抓到的是电脑自己网卡的流量测试卡的报文一条都没有。判断标准很简单网页在刷新Packets 在涨确认无误后再进入测试任务。2.2 Uu 口准备安卓 ROOT 终端与 Shark.apk手机方案有两个硬性前提一是安卓系统二是必须 ROOT。手册里写得很直白Shark.apk 装好后无法正常启动绝大多数情况就是终端没有 ROOT。这里要注意终端厂商对 ROOT 后的设备是不保修的所以别拿测试员的私人手机去 ROOT项目上最好备一台专门的测试终端ROOT 后只做抓包用。终端选型上还有一个容易被忽略的点CPU 处理能力。手机抓包同样是全量捕获低端机在高速下行时丢包率会明显上升抓出来的数据本身就缺了一段分析时会把“终端丢包”误判成“网络丢包”。我一般会用中高端的测试终端做抓包专用机性能足够成本也相对可控。Shark.apk 的 Parameters 里默认是-vv -s 0手册特别强调“请不要修改”。后面分析时会看到-vv是 tcpdump 的详细输出模式-s 0表示 snaplen 设为 0也就是每个包不截断、完整保存。如果手滑把 snaplen 改小比如改成 96pcap 里只剩包头没有负载后续 Follow TCP Stream、丢包分析全部废掉——这是最不值当的翻车方式。2.3 eNB 与核心网侧准备长网线、机房权限与测试卡 IPeNB 侧的准备事项比较朴素但卡人得有能进机房的权限得有一根足够长的网线。eNB 上抓包抓的是整个 CC 板的流量如果这个站点下不只有测试用户在做业务商用用户的报文也会一并抓进来所以电脑选型要求比 Uu 口更高建议同样按 80 万行上限来控制单次抓包数据量。核心网侧的准备才是真正的重点最好为测试卡申请静态 IP。申请不到也不代表不能做手册给了一套备用流程先在 Uu 口抓包不断链的情况下做多次串行测试观察核心网分配给终端的 IP 是否比较固定。如果地址固定那就不需要静态 IP每次联合抓包前由 Uu 口先抓包、确定测试卡的 IP 地址再通知核心网侧按这个 IP 过滤抓包。这里有一个理解上的坑核心网侧抓包是整个 S1 接口的流量而不是只抓某一个终端。没有 IP 过滤器核心网抓下来的数据会混杂大量其他用户的业务文件巨大且难以分析。所以核心网侧抓包的“准备”本质上是解决“怎么从海量流量里只抓测试卡那一条流”的问题。静态 IP 是最省事的解法动态 IP 就得靠 Uu 口先行、拿到 IP 后同步给核心网侧的流程来兜底。3. Uu口、eNB、核心网联合抓包Uu口牵头配合是关键3.1 联合抓包的协调机制三端同时抓包最忌讳“各抓各的”。手册里明确了一条协调纪律抓包工作由 Uu 口统一协调。Uu 口拿到测试卡被分配的 IP 地址后第一时间通知核心网侧做抓包过滤设置Uu 口每完成一段测试都要及时通知 eNB 侧和核心网侧保存抓包文件并核对文件名是否匹配。这个机制看着简单做起来很容易变味。实际项目里我见过的情况是Uu 口已经测完三段了核心网侧才刚把过滤条件配好中间一段直接抓空或者三段业务抓完了三边的文件名各起各的日期都写不对后期对数据时根本不知道哪个文件对应哪一段。所以 Uu 口侧不只是抓自己的包还承担了“调度中心”的角色每段业务的开始、停止、保存都要喊话通知文件名也要跟着业务段走。3.2 测试电脑抓包Wireshark 启停与保存用测试电脑抓 Uu 口的操作步骤很直接Wireshark 菜单Capture - Interfaces找到测试终端对应的 Interface点Start就开始抓包。完成测试后点工具栏上的红色停止按钮然后File - Save As保存。这里有一个小细节手册在保存截图里标了“注意不要修改红色标注的地方”。我理解是指文件名后缀和保存类型保持 pcap 格式不要动别为了省空间存成其他格式或者只保存过滤后的包。三端联合分析时需要对比时间戳和报文序号文件格式不一致会让后续处理多出很多不必要的转换步骤。启动前建议把Capture Options里的环形缓冲打开按文件大小自动切片。常见做法是每个文件 100M 左右切一个既能控制单文件体积又能在分析时按时间分段快速定位。这是对“80 万行上限”的实操补强比录一大段再手工拆要稳得多。3.3 Shark.apk 手机抓包启动、停止与文件保存Shark.apk 的使用更简单启动后点Start就开始记录.pcap 文件名是软件自动生成的无法自定义。测试完成后点Stop抓包文件会自动保存到 SD 卡根目录下。文件名不能自定义这个限制是真的让人头疼。一次测试跑下来SD 卡根目录下可能躺着好几个自动命名的文件不手动改的话后面根本对不上是哪个业务段。我的习惯是每停一次抓包立刻把文件名改成“站点_业务_日期_段号.pcap”趁记忆还新鲜的时候改别攒到最后统一处理。另外确认下文件确实是保存完整了再拔卡自动保存偶尔会因为 SD 卡写入速度跟不上而出问题。参数设置那里再强调一次保持-vv -s 0不要动。如果手痒改了参数导致包被截断从 Uu 口抓上来的数据就废了一多半这个没有后悔药。3.4 eNB 与核心网侧抓包的配合要点手册里有两处比较特殊的内容处理方式一处是 eNB 抓包方法涉密删除另一处是核心网抓包因厂家差异不详细介绍。这正好说明了两侧的工具链是分散的。eNB 侧常见做法是接 CC 板抓包端口做镜像分流核心网侧则是在 S1 接口上用专用采集设备或者网管自带的抓包功能。对无线侧工程师来说这两侧的抓包操作不是重点怎么配合才是重点。核心网抓包时需要无线侧配合做两件事一是 Uu 口先把测试卡的 IP 地址发过去让核心网侧能把过滤条件设好二是每一段测试结束都要及时通知核心网侧保存文件并确认三端文件名能对上。eNB 侧配合的核心同样是文件保存节奏要跟着 Uu 口的指令走不要让 eNB 侧的抓包变成无人值守的黑匣子最后存了一堆不知道对应哪段业务的文件。4. 抓包数据分析Follow TCP Stream 过滤单线程与双线程识别4.1 为什么要先过滤单业务/单线程抓包数据裸奔是没法看的。eNB 的抓包是整个站点的里面既有测试用户的流量也有普通商用用户的流量业务侧的测试工具又大多是并发多线程比如 Speedtest、FileZilla 都会默认开多个线程。不先把某个业务或线程的报文单独过滤出来后面做吞吐量统计、丢包分析全部会失真——丢包率看着吓人可能只是把几个用户的数据混在一起算了。这里给出一个常见的 Wireshark 显示过滤表达式用于过滤特定 TCP 流tcp.stream 1024逻辑说明tcp.stream是 Wireshark 为每条 TCP 连接生成的唯一编号Follow TCP Stream 本质上就是复用这个过滤器的图形化操作。当你用 Follow TCP Stream 选中了某一行Wireshark 会自动跳到对应的tcp.stream N视图此时再File - Save As保存下来的就是这个线程的完整报文。参数说明1024只是示例编号实际以你在抓包里看到的 stream 编号为准。如果业务是 UDP 流量则改用ip.addr 测试卡IP udp.port 目标端口来做过滤因为 Follow TCP Stream 对 UDP 的流重组支持有限。4.2 实例识别双线程下载手册里给了一个非常经典的实操案例我把关键数据拆出来。先用Statistics - IO Graphs看整体从图里可以了解到有效数据下载业务阶段约为 69000 行。选中数据传输过程中的任意一行右键Follow TCP Stream可以看到这个线程有 33434 行再对比整个抓包文件是 89780 行。两个数字对不上说明这次抓包不是单线程。接下来是关键步骤在 Follow TCP Stream 的视图里随机找到一处不连续的 NO. 编号比如第 153 到 196 行之间存在跳号。点Clear回到全量视图选择第 154 到 195 行之前的任意一行再次Follow TCP Stream这次捕捉到的线程有 35882 行。结合两次过滤的结果可以得出结论这个业务是使用双线程进行下载的。这里要解释一下原理为什么 NO. 不连续能说明多线程因为 Wireshark 的 NO. 是全文件按捕获顺序统一编号的双线程并发时两个连接的交错报文在总编号里自然会产生跳号。找到跳号段再对跳号前的一行做 Follow TCP Stream就能把另一条线程也找出来。有个判断技巧两次 Follow TCP Stream 过滤出来的行数之和如果接近业务阶段的有效总行数那么基本可以断定就是两个线程而没有第三个隐藏线程如果相加明显小于总行数就继续在剩下的报文里找新的 stream 编号可能还有第三个、第四个线程。4.3 File Save As 与有效数据的对照当你在 Follow TCP Stream 视图中执行File - Save As时保存对话框里会显示当前过滤视图的报文数也就是这个线程在总文件中的占比。手册里的例子是整个抓包文件 89780 行第一个线程 33434 行。通过这个占比数字可以快速判断这次测试是单线程还是多线程占比接近 100%基本是单线程单业务占比只有三分之一、二分之一必定有多个线程在跑。保存的时候注意保持 pcap 格式并且不要在 Follow TCP Stream 视图里直接保存整个文件——那个视图只包含当前 stream 的报文保存下来的是过滤后的子集不是原始全量数据。如果你后面还要重新分析其他线程就必须在点Clear回到全量视图后再保存。这是新手经常踩的坑分析到一半把过滤后的数据存了原始文件反而没留。5. 避坑LTE 三端抓包里常见的 5 个坑5.1 抓包文件太大Wireshark 卡到无法停止和保存现象抓包数据超过 80 万行之后点停止没反应等了几分钟界面还是卡死状态最后强制重启抓了一下午的数据全没了。原因Wireshark 对超大数据包的处理能力有限内存占用高UI 线程被大量报文重组的运算阻塞保存又是全量写入变成一个“既停不下来也存不出去”的死局。解决按业务段分段抓、分段存单段控制在 80 万行以内必要的话开启Capture Options里的环形缓冲按大小切片。如果已经卡死别急着关进程给它几分钟可能还会恢复实在恢复不了看看有没有临时文件。从那以后我每次抓包都强制走一遍这个流程开环形缓冲、预估流量、分段停止绝不等到录完一大段再统一保存。5.2 Shark.apk 无法启动或抓出来的包全是截断的现象Shark.apk 安装完成后点启动直接闪退或者抓包能跑但 Follow TCP Stream 时看不到任何应用层数据。原因闪退基本是终端没有 ROOTShark.apk 需要 root 权限才能创建原始套接字去捕获报文抓包能跑但数据截断多半是 Parameters 里的-s 0被改过snaplen 变小了。解决换一台已 ROOT 的安卓测试终端别在这上面省时间每次启动前检查 Parameters 是否为-vv -s 0不是就改回来改完不要动其他设置。这条没有捷径参数错了数据就是残废的。5.3 核心网侧抓到的不是测试卡的业务流量现象核心网侧同时抓了 S1 接口的包回头分析时发现文件巨大里面夹杂大量陌生 IP 的业务测试卡的报文只占很小一部分过滤起来非常痛苦。原因没有在核心网侧配置 IP 过滤就启动了抓包。核心网抓的是整个接口的流量不是只针对某个终端测试卡如果没有静态 IP也无法提前写入过滤规则。解决优先为测试卡申请静态 IP来不及申请的就先做串行测试确认动态分配的 IP 是否固定。如果 IP 不固定每次联合抓包前由 Uu 口先启动抓包拿到这次测试卡的 IP 后立即通知核心网侧按该 IP 配置过滤器再开始正式业务测试。5.4 把多线程业务的交错报文误判为丢包现象抓包文件里某个 TCP 流出现了大量乱序、重传的标记看起来像是网络质量极差但业务测速结果却正常。原因多线程并发时多个 TCP stream 的报文在总文件里交错排列如果按全局 NO. 或时间戳去分析乱序而没有先按tcp.stream过滤出单个连接就会把两个线程之间的交错当成乱序重传。解决任何丢包/乱序分析之前先做单线程过滤。右键任意报文Follow TCP Stream在tcp.stream N的视图里做后续的统计和图谱分析。分析结束点Clear回到全量视图再处理下一条线程。这样得出来的丢包重传指标才不会冤枉无线侧。5.5 无线 BLER 与 Wireshark 丢包时间对不齐现象Wireshark 里看到某段时间有丢包DT 软件打的 BLER LOG 里却找不到对应的无线丢块两个工具各说各话没法联合定位。原因BLER LOG 和 pcap 的时间基准不一致或者两者根本没有做过时间对齐。常见做法是在测试开始前用同一个时间源同步两部设备的时间并在测试开始时做一个标记事件方便后续在两个文件里找共同参考点。解决测试前完成设备时间同步测试中留下标记事件分析时先根据同步点对齐时间轴再对比 BLER 曲线和 Wireshark 的丢包位置。如果 BLER 一直很低而丢包集中在某几秒说明问题大概率在传输侧或核心网侧不在无线侧。6. 实战习惯三端抓包的文件命名与双线程验证流程三端联合抓包数据对了分析技巧有了最后拼的就是文件管理习惯。我拆完这份手册后自己定了一套流程现在每次 LTE 速率类问题定位都按这个走。文件命名方面三端各自保存时按统一规则命名日期_站点_业务_段号_抓包位置.pcap。抓包位置字段必须有Uu 口、eNB、核心网三端靠它区分没有这个字段三份文件放到一起根本分不清谁是谁。eNB 和核心网侧的文件名由 Uu 口协调员事先发到工作群里各侧保存时直接套用不要自己发挥。保存节奏上“每完成一段测试就通知保存”这条纪律不能打折扣。业务测试经常是连续好几段每段之间只隔几十秒如果等全部测完再统一保存中间任何一段出错都没法补救。我一般会在每段测试结束后先让三端各自保存文件再确认文件名匹配然后再开始下一段。这个过程重复几次之后数据的可用性会高很多。双线程验证有个非常实用的收尾技巧把两次 Follow TCP Stream 的行数相加和业务阶段的有效总行数做对比。如果相加约等于总行数说明分析已经覆盖了全部有效报文没有漏掉隐藏线程如果明显小于总行数就要回到全量视图继续找下一条不连续的 NO. 段并再次 Follow TCP Stream。这个收尾步骤能帮你确认“这个业务到底开了几个线程”是排查多线程速率分配不均问题的关键手法。最后说一个多数人容易忽略的验证动作分析完之后把结论和测速工具的结果做个交叉验证。比如 Speedtest 显示上下行速率Wireshark 里按 IP 过滤统计出实际吞吐量两个数值如果差得远先检查过滤条件是否漏了报文别急着下“限速”的结论。我把这套流程跑过好几轮之后最大的感受是三端抓包百分之七十的价值在准备工作百分之二十在文件管理真正放到分析技巧上的只有百分之十。希望帮到你。本文还有配套的精品资源点击获取