企业官网建设流程全解析

简介：《LTE 抓包分析指导手册》是一份面向通信工程师与网络优化人员的 PDF 文档，专注于解决 LTE 网络中信令面与用户面数据包的捕获和分析难题。手册系统梳理了 UU 口、ENB（eNodeB）以及核心网三类场景的抓包前准备与具体操作流程，既支持使用测试电脑配合 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. 抓包前的准备工作：从电脑选型到测试卡静态 IP

2.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 改小，比如改成 96，pcap 里只剩包头没有负载，后续 Follow TCP Stream、丢包分析全部废掉——这是最不值当的翻车方式。

2.3 eNB 与核心网侧准备：长网线、机房权限与测试卡 IP

eNB 侧的准备事项比较朴素但卡人：得有能进机房的权限，得有一根足够长的网线。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 时看不到任何应用层数据。

原因：闪退基本是终端没有 ROOT，Shark.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 过滤统计出实际吞吐量，两个数值如果差得远，先检查过滤条件是否漏了报文，别急着下“限速”的结论。我把这套流程跑过好几轮之后，最大的感受是：三端抓包百分之七十的价值在准备工作，百分之二十在文件管理，真正放到分析技巧上的只有百分之十。希望帮到你。

本文还有配套的精品资源，点击获取