如何基于多日志与三种计算方法分析LTE终端并行下载吞吐量？

我在LTE吞吐量测试分析这块摸过不少案例，结合你手里的L1/L2/L3厂商日志和tPacketCapture抓取的Wireshark日志，还有三种吞吐量计算维度，咱们可以从「交叉验证」「分层拆解」「异常定位」三个核心方向来开展分析：

一、多维度吞吐量的交叉验证（核心第一步） #

你提到的三种吞吐量计算方式，本质是从不同协议层反映传输效率，先把它们拉出来做横向对比，验证数据一致性：

• L1调度吞吐量：这是物理层的理论调度能力，由厂商日志统计的传输比特数计算而来。你可以把它作为「天花板值」，后续各层吞吐量都应该低于这个数值（除非统计逻辑有问题）。
• L3 IP层吞吐量：可以从厂商L3日志里提取IP包的总字节数，或者用Wireshark统计IP层的总流量（过滤ip协议后统计字节数），计算出IP层吞吐量。对比L1和L3的差值，就能算出物理层到IP层的损耗（通常来自MAC层HARQ重传、RLC层分段开销、IP包头、调度间隙等，正常损耗在10%-25%之间）。
• 应用层HTTP吞吐量：用Wireshark过滤http协议，统计下载文件的总字节数，除以总下载时间得到。再和L3吞吐量对比，差值就是TCP+HTTP的协议开销（比如TCP包头、HTTP头、握手时间、拥塞控制窗口限制等，正常损耗在5%-15%）。

如果某两层的差值远超合理范围，那大概率是对应协议层出了问题，比如L1到L3损耗超过30%，就要去看MAC/RLC层的重传率。

二、基于L1/L2/L3厂商日志的深层瓶颈分析 #

厂商专属日志的优势是能拿到协议栈内部的关键指标，用来定位吞吐量上不去的根因：

• L1层：重点看这几个指标：
  • 调度RB数：是否持续占满带宽（比如20MHz带宽对应100个RB），如果RB数波动大，可能是基站资源不足或终端信号差；
  • MCS调制方式：MCS越高（比如MCS28对应64QAM），单RB传输的比特数越多，如果MCS持续偏低，说明无线环境差（信噪比低、干扰大）；
  • 下行误块率（BLER）：BLER超过10%的话，HARQ重传会大幅增加，直接拉低实际吞吐量。
• L2层：关注RLC和MAC的关键数据：
  • RLC层的PDU丢包率：如果丢包率高，说明无线链路不稳定，终端频繁请求重传；
  • MAC层的HARQ重传次数：重传次数越多，有效传输的时间占比越低，吞吐量自然上不去。
• L3层：看IP包的转发情况，有没有丢包、分片异常，同时结合TCP的参数（比如终端的TCP初始窗口、拥塞控制算法），6条并行TCP线程是否都能稳定跑满带宽，有没有某条线程被限流。

三、结合Wireshark日志的端到端校验 #

tPacketCapture抓的Wireshark日志能帮你从终端侧看端到端的传输细节，和厂商日志互补：

• TCP流分析：对6条TCP线程分别做「流统计」（Wireshark菜单：Statistics > Flow Graph），看每条流的RTT（往返时延）、重传次数、窗口大小。如果某条流重传频繁，可能是这条流的路径有干扰，或者终端TCP拥塞控制过于保守；
• HTTP下载过程校验：看HTTP请求的建立时间（TCP三次握手+HTTP请求响应），是否有请求超时、重试的情况，下载过程中是否有TCP窗口收缩（说明拥塞）；
• 时间轴对齐：把厂商日志的时间戳和Wireshark的时间戳对齐（如果有偏差，先做时间同步），比如某一时刻厂商日志显示L1调度了大量数据，但Wireshark里没收到对应的IP包，那就要查RLC层是否丢包，或者终端侧的接收问题。

四、异常场景的定位思路 #

如果吞吐量达不到预期，按这个流程排查：

1. 先看L1调度吞吐量是否达标：如果L1本身就低，优先查无线环境（RSRP、SINR）、基站资源配置；
2. 如果L1正常但L3低：查MAC/RLC层的重传、丢包，看是否是无线链路质量差；
3. 如果L3正常但应用层低：查TCP的拥塞控制、HTTP的连接效率，是否有线程调度不均的问题（比如某几条TCP流没跑起来）。

内容的提问来源于stack exchange，提问作者Andrea