简介《LTE抓包分析指导手册》面向通信网络维护、优化与测试工程师系统讲解LTE网络各接口的数据包捕获与分析方法帮助读者建立从空口到核心网的完整抓包认知。手册从抓包前的准备工作切入覆盖Uu口测试电脑与安卓手机两种方式、演进型基站及核心网三类抓包场景并详细说明Wireshark等工具的安装配置与启动、保存等操作步骤数据分析章节则重点介绍单个业务请求的过滤方法、丢包与乱序分析、IO GRAPHS图形化观察以及无线侧BLER与丢包联合定位技巧可帮助读者快速定位空口质量、基站配置及核心网信令流程中的异常。资源为单个PDF文档体积仅1.72MB目录结构清晰且内容编排紧凑适合作为现场排障和技能提升的便携参考。已有294人学习/下载对需要掌握LTE抓包技能、提升网络问题处理效率的通信工程师而言是一份实用的进阶资料。1. LTE抓包分析不是玄学一份手册解决的真实问题在LTE网络里排查“视频卡顿、掉线、时延高”这老三样应用日志和服务器监控经常给不出答案服务器端网络正常客户端报文就是到不了或慢半拍。很多工程师遇到这类问题会去翻《LTE 抓包分析指导手册》这类PDF结果发现里面全是协议栈分层、信令流程名词真正上手机敲命令那一刻还是会卡住。抓包分析落到实战上要解决的核心问题是在终端、空口、核心网三个位置把业务过程换成信令和报文再反推是哪一段出了问题。这套能力适合无线协议开发、测试和网络优化工程师也适合被App卡顿折磨的应用开发者——只要你能拿到一台可root的测试机今天就能照着跑通。2. 抓包前先画信令地图三个抓包点与四段必盯流程2.1 三个抓包点能回答什么先讲一个反直觉的结论LTE抓包不是越贴近空口越好而是哪里出了问题就去哪里抓。同一个业务异常在三个抓包点看到的景象完全不同选错位置会让你在错误的方向上浪费一下午。终端侧抓包最容易理解也最容易误解。手机里跑着两个层次的数据IP层之上是普通socket就能拿到的明文包比如HTTP、TCP、DNS再往下的物理层调度、MCS调制等级、重传次数只有Modem才知道。你在手机上跑tcpdump拿到的是前者。所以终端侧抓包擅长回答“域名解析慢不慢、TCP重传是不是集中在某个流、HTTP请求到响应隔了多久”这类IP层以上的问题。空口侧抓包要借助路测软件配合扫频设备能把物理层和RRC层完整记录下来包括RSRP、SINR、RB分配、BLER。它的优势是能看到无线侧真实调度情况代价是设备贵、场景苛刻日常排障用它属于杀鸡用牛刀。核心网侧抓包是在S1或Gi接口镜像抓取能看到从基站到核心网的信令全貌和用户面回传是否丢包。普通工程师拿不到这个接口但可以在应用服务器出口用tcpdump模拟同样的效果——本质都是站在网络另一头看报文。三个抓包点的取舍列成一张表更直观抓包点能回答的问题看不到的东西常用场景终端侧tcpdump域名解析、TCP重传、HTTP时延、应用交互空口调度、覆盖质量、NAS明文App卡顿、协议栈异常、弱网定位空口侧路测Modem日志覆盖、干扰、调度、切换、RRC失败原因应用层报文明细掉线、接入失败、RF优化核心网/服务器侧回程丢包、核心网响应、拥塞状况终端侧无线信息时延高、下行慢、回传链路实战里最划算的组合是“终端侧抓包服务器侧tcpdump两边时间对齐”不需要昂贵路测设备一个人一台电脑就能完成大部分弱网定位。我在排查某跨平台系统的滑动卡顿问题时就是这套打法手机上录pcap的同时服务器同步抓包两端一对比问题很快落在TCP重传而不是服务端响应慢。2.2 四段必盯流程抓包分析最大的误区是拿到包就直奔HTTP。LTE网络里应用报文要先走完四段信令流程才落到应用层哪一段出问题都会表现为“业务慢”或“业务断了”。第一段是RRC连接建立从随机接入到RRC Setup Complete正常几十到几百毫秒。这一步失败或变慢表现就是首屏加载前有一段空白等待。看pcap里的lte-rrc消息如果反复出现Preamble重发或者RRC Setup迟迟不来问题多半在信号覆盖或参数配置而不是应用本身。第二段是Attach附着流程核心是鉴权和EPS会话建立。App场景里最常见的是APN配置错误导致PDN拒绝或者鉴权失败后反复重试。这段流程在NAS消息里终端侧抓包在未加密阶段能看到EMM和ESM的完整状态迁移。第三段是切换与重选。用户移动过程中发生跨站切换切换期间的短暂业务中断是正常现象但如果频繁切换或切换失败视频就会出现周期性卡顿。在pcap里看RRC重配置消息一段时间内反复出现重配和UE context release基本可以判断在打乒乓。第四段是连接释放与TAU。很多“掉线”不是真掉线而是网络侧发了releaseCause为“load balancing TAU required”或“ue inactive timer”的释放把连接挂起。应用层还显示在线实际数据面已经断了。抓包看到这类释放原因就能解释为什么App界面停留在一个状态、消息却发不出去。2.3 抓包前要定下三个参数开抓之前别急着敲命令先把控制变量定死否则分析时全是噪音。第一是时间同步。LTE抓包最怕两端时间对不上方法我会在第5章展开这里先给结论抓包前后各记一次手机UTC时间和服务器UTC时间算出差值作为偏置分析时手工校正。不要相信手机界面显示的时间运营商网络时间同步不会覆盖应用层。第二是业务收敛。一次只测一种业务只拨一个APN。有人一边刷视频一边传文件抓下来的pcap里几十条TCP流交叠没一条是干净的单是分帧就要半小时。常见的做法是先把设备切飞行模式打开数据业务确认默认承载建立成功再启动被测业务。第三是文件上限。手机上tcpdump默认会写到存储满为止一小时后看到的可能是几个GB的巨型pcap桌面Wireshark直接卡死。提前按“单文件50MB、轮转8个、时长10到15分钟”来限制既能覆盖一次问题复现又不会把分析环境拖垮。3. 把抓包命令落到手机上adb加tcpdump的最小抓包方案3.1 手机端最小命令集终端侧抓包最常见的问题是工具装好了却不知道命令含义遇到“no such file”就卡住。先给一套最小可跑的命令集我日常就用这一套。第一步准备环境。需要一台可root的测试机把tcpdump二进制推到手机内部存储并确认权限adb push tcpdump /data/local/tcpdump adb shell chmod 755 /data/local/tcpdump adb shell /data/local/tcpdump --version三条命令的逻辑很直接把工具传到手机、给执行权限、验证能跑。如果最后一条返回版本信息环境就绪。踩坑点在于部分平台上/data/local执行权限受限这时把目录换成/data/local/tmp即可。第二步固定状态再开始抓包adb shell settings put global airplane_mode_on 1 adb shell am broadcast -a android.intent.action.AIRPLANE_MODE adb shell input keyevent 82 adb shell /data/local/tcpdump -i any -s 0 -C 50 -W 8 -Z root -w /sdcard/lte_capture.pcap前三条先把手机切到飞行模式再点亮屏幕目的是让抓包起点干净、不带旧连接干扰。第四条才是真正起抓包-i any表示抓所有接口因为LTE下数据通常走rmnet_data接口直接指定接口名容易写错抓全量再过滤更稳-s 0表示不截断包长保留完整载荷分析HTTP正文时缺了这个会丢关键数据-C 50表示单文件写到50MB就轮转-W 8表示最多保留8个文件总量约400MB既能覆盖复现窗口又不撑爆存储-Z root是以root身份运行避免权限不足时只抓到自己的包。第三步复现问题场景并拉取文件。让测试用户复现一次卡顿或掉线时间控制在10分钟以内结束后执行adb shell sync adb pull /sdcard/lte_capture.pcap ./cap/ ls -lh ./cap/lte_capture.pcapadb shell sync是血泪教训换来的先把缓存落盘再拉文件否则容易拿到半个文件。拉取后用ls确认大小如果跑了十分钟业务却只有几十KB基本就是没抓到数据回头检查接口名或root权限。3.2 服务器侧同步抓包终端侧抓包只能说明客户端看到了什么要判断是空口问题还是回程问题必须在服务器侧同步抓一份。常见做法是直接在业务出口网卡上跑tcpdump命令和手机上几乎一样sudo tcpdump -i eth0 -s 0 -C 100 -W 20 -w /data/cap/server_$(date %Y%m%d_%H%M).pcap区别只在参数数值服务器流量比手机大得多单文件上限提高到100MB、最多保留20个文件避免业务关键段被频繁轮转覆盖。-w后面用$(date)拼一个带日期的文件名多天抓包归档时不至于混淆。服务器抓包有一个容易翻车的点必须明确过滤条件。如果只关心某一个用户在命令里加host或port限定如果不加公网服务器的流量几秒内就能把20个轮转文件全部写满。有一种变通做法是只抓DNS和TCP握手包加“udp port 53”过滤包量小、定位精准可以长时间挂着。3.3 文件预处理先用tshark把pcap变瘦手机和服务器抓回的原始pcap动辄几百MB直接拖进桌面版Wireshark打开和过滤都要等很久。我的习惯是先让tshark按协议预过滤去掉无关流量再打开mkdir -p ./cap/filtered for f in ./cap/*.pcap; do tshark -r $f -Y lte-rrc || nas-eps || http || dns || tcp.analysis.retransmission || tcp.analysis.ack_rtt -w ./cap/filtered/$(basename $f) 2/dev/null done ls -lh ./cap/filtered这段脚本逐个文件过滤出RRC信令、NAS消息、HTTP、DNS、TCP重传和ACK时延几类关键包把其余无关流量剥掉。过滤后的文件通常只有原文件的5%到20%Wireshark打开和检索都快很多。-Y后面的表达式决定保留哪些包按排查目标定制lte-rrc和nas-eps对应信令层http和dns对应业务层tcp.analysis系列是Wireshark计算出的重传与往返时延弱网定位主要靠它们。这个环节还有个隐藏收益手机和服务器两份pcap分别过滤后再导出时间戳做对齐第4章和第6章的分析都以这份预处理文件为基础。4. 从pcap到问题定位Wireshark与tshark的信令分析套路4.1 把pcap变成可读信令序列打开pcap的第一反应是看TCP报文列表这没错但面对LTE包我更推荐先看信令序列。它像故事梗概先知道发生了什么再扎进细节。先抽RRC消息按时间排序看流程轮廓tshark -r filtered.pcap -Y lte-rrc -T fields \ -e frame.time_relative -e lte-rrc.ChannelType -e lte-rrc.message 2/dev/null | head -60输出是一个四列时间线相对时间、信道类型、消息名。比如能看到从0.000秒的RRC Setup Request到0.12秒的RRC Setup Complete再往后是多次重配置。-e参数指定输出字段frame.time_relative是相对起始时间ChannelType区分信令走控制信道还是共享信道message是具体消息名。如果整个文件里lte-rrc极少甚至为零说明抓包位置拿不到RRC请回第3章检查抓包点。只看RRC还不够NAS层承载着附着、鉴权、TAU这类移动性管理消息用这一条命令把NAS也拉出来tshark -r filtered.pcap -Y nas-eps -T fields \ -e frame.time_relative -e nas-eps.msg_type -e nas-eps.mm.attach_type 2/dev/null | head -30nas-eps.msg_type会显示“Attach request”“Authentication request”这类消息名attach_type是附着类型。用它能快速判断附着流程卡在哪一步是鉴权失败、PDN拒绝还是ESM建立没完成。4.2 常用显示过滤器一张表进入Wireshark做交互分析时别一上来就翻包先把显示过滤器打到顶部再逐步收窄。这张表是我抓包分析里出现频率最高的过滤器直接照抄显示过滤器作用典型场景lte-rrc只看RRC信令RRC建立失败、切换乒乓nas-eps只看NAS移动性消息Attach卡住、APN被拒gtp看S1-U用户面隧道核心网回程丢包定位http.request 或 http.time应用请求与响应时延App卡顿、接口响应慢dnsDNS请求与响应域名解析失败、慢DNStcp.analysis.retransmission只看TCP重传包弱网、丢包、拥塞tcp.analysis.ack_rtt每个ACK的往返时延链路抖动、时延突变最后两个过滤器价值最高它们不是包里的字段而是Wireshark根据序列号和确认号推算出的统计字段。在LTE业务里看到大量重传先去找重传发生前是否有切换或信号骤降这就是弱网定位最直接的一条证据链。另一个实用技巧是叠加过滤。比如在顶部输入框敲“tcp.stream eq 42 tcp.analysis.retransmission”只看第42条TCP流的重传包先按udp.port53看DNS是否丢请求再对这个DNS流单独分析。分析范围和目标都会清晰很多。4.3 三类常见问题的特征序列多年的抓包分析里大部分工单可以归为三类每类的特征和定位方法相对固定。第一类是“请求发出后石沉大海”。特征DNS或HTTP请求发出后出现明显时间间隙随后跟几个重传最后才收到响应。这种一般发生在弱覆盖或拥塞场景空口调度排队导致报文迟迟没被调度器送出去。定位方法看这条流的tcp.analysis.ack_rtt如果RTT突然从30ms涨到几百ms再结合终端Modem日志里的RSRP基本能确认是无线侧排队。第二类是“重传风暴”。特征tcp.analysis.retransmission密集出现并伴随重复ACK。这里有一个容易踩的误区看到重传就断言是丢包。TCP重传也可能是触发快速重传的冗余ACK在LTE调度下乱序到达。真正要区分的是单向丢包还是双向拥堵做法是拉服务器侧抓包窗口对比两边都看到重传说明链路真丢包只有终端侧重传问题可能出在终端发送方向。第三类是“异常释放”。特征RRC连接在业务进行中突然被释放pcap里出现异常重配或直接看到rrcConnectionRelease。定位方法对lte-rrc按消息排序找到rrcConnectionRelease看它的releaseCause字段。原因值不同结论完全不同有负荷均衡触发的释放也有终端空闲态切换触发的释放漏掉这一步容易把正常挂起误判成掉线。5. LTE抓包避坑指南现象、原因与后悔药5.1 NAS消息大面积空白信令流程断在半路现象pcap里RRC消息齐全但NAS字段一律空白或者只看到“EMM status”这类状态码想看的Attach流程细节什么都没有。原因RRC建立完成后网络会下发安全模式命令开启完整性保护和加密后续NAS消息都是密文抓包工具没有密钥自然解不开。这不是抓包失败是协议本身的加密机制。解决测试环境下让核心网关闭安全算法禁用完整性保护和加密或者用支持空口解密的探针终端抓Modem日志。日常定位我一般不纠结NAS明文直接看RRC层行为和TCP层表现把NAS当黑匣子就好。5.2 终端和服务器时间戳对不齐现象手机端pcap和服务器端pcap抓的是同一段业务对时间时发现同一个ACK在两边差了整整两分钟。原因手机系统时间没和服务器同步。很多测试机会自动同步网络时间但长期USB供电不动的时间基准容易漂移两个pcap基准不一致时所有对齐分析都是白做。解决抓包开始前和结束后各执行一次adb shell date记录手机UTC时间同时用date -u记服务器UTC时间两次差值作为时间偏置。分析时在Wireshark里用“编辑-时间参考-设置时间参考”把某个锚点包对齐或者在导入时手工减掉偏置。5.3 pcap文件半路截断或校验失败现象文件拉回电脑后Wireshark提示“unexpected end of file”或者文件中部出现大量无效包大小远小于预期。原因手机存储被写满后tcpdump自动退出USB拉取时进程还在写文件导致文件头记录长度和实际内容不一致还有一种是设备在抓包过程中重启或进程被系统杀掉。解决抓包前确认/sdcard剩余空间用-C和-W限制轮转而非无限写拉取前先执行adb shell sync结束抓包时按CtrlC让tcpdump正常落尾再sync再拉取不要直接拔线。5.4 Wireshark里过滤不到RRC信令现象同一个pcap文件换一台电脑就能看到lte-rrc消息当前环境里用“lte-rrc”过滤却一个包都出不来。原因Wireshark的协议解析靠解码器匹配不同版本对LTE标准支持完整度不同。老版本会把RRC消息按未知协议处理有些抓包工具导出的pcap里RRC不是标准协议类型需要手动指定。解决确认Wireshark版本并更新到较新版本在“分析-解码为”里把对应UDP端口或协议类型强制指定为LTE RRC。这个坑只在旧工具链环境下出现升级软件后重新导出一遍pcap基本能解决。5.5 多PDN连接互相干扰过滤后依然分不清现象pcap里同时存在几十条TCP流视频、下载、即时通信全混在一起按IP过滤后仍然分不清哪条是本次测试业务。原因现代终端同时存在多个APN连接IMS、数据、彩信各走各的隧道应用又可能走同一个HTTP出口多条流天然交织。解决抓包前只保留一个数据APN测试场景里用固定域名或固定IP的测速服务器分析时以http.host或dns.qry.name作为第一层过滤再结合tcp.stream拆出会话。如果必须用真实App就在服务器侧用与用户Session对应的目的端口做区分。6. 进阶把一次LTE卡顿从pcap里拆成三段时延6.1 用“问题包回溯”完成三段时延拆解拿到pcap后先别做猜想直接把最慢的一次HTTP请求拆成三段时延判断责任在无线、网络还是应用。这个收尾动作能让你从“网络差”这种笼统结论精确到“连接建立正常、首包等待600ms、其中空口排队300ms伴随一次重传”这种可执行描述。第一段是TCP建链时延从第一次SYN到对端ACK的间隔代表新连接走空口加回程的往返成本。正常LTE下应在30到80毫秒弱网下会涨到数百毫秒。用tshark找出最慢的HTTP请求再看它的TCP流握手间隔tshark -r filtered.pcap -Y http.request -T fields \ -e frame.number -e http.time -e http.host -e http.request.uri \ | sort -t$\t -k2 -nr | head -5 tshark -r filtered.pcap -Y tcp.stream42 (tcp.flags.syn1 || tcp.flags.ack1) -T fields \ -e frame.time_relative -e tcp.flags.syn -e tcp.flags.ack第一段命令把所有HTTP请求按总响应时间从大到小排序head -5取最慢的几条记下帧号后在Wireshark里右键“追踪TCP流”拿到tcp.stream编号。第二段命令单独看这条流的SYN与ACK时间点两者相减即建链时延。第二段是首包时延从HTTP GET发出到第一个数据段的间隔反映服务器处理时间加空口排队等待。建链RTT很短、首包时延却很长责任在应用或服务器首包时延里混着一串重传空口调度问题就很明确。第三段看整个流的重传百分比和RTT走势重传率高于5%就怀疑弱网或拥塞RTT随吞吐上升而爬升通常是队列打满的缓存效应。三段时间拆完结论就落地了。我现在的习惯是接到卡顿类工单先抓十分钟pcap做时延分解再看应用日志因为pcap给出的时序最客观不掺主观体验。希望帮到你。本文还有配套的精品资源点击获取