精品文档5GSA TCP数传问题分析应用总结.docx

精品文档5GSA TCP数传问题分析应用总结.docx

《精品文档5GSA TCP数传问题分析应用总结.docx》由会员分享，可在线阅读，更多相关《精品文档5GSA TCP数传问题分析应用总结.docx（19页珍藏版）》请在冰豆网上搜索。

精品文档5GSATCP数传问题分析应用总结

5G_SATCP数传问题分析应用总结

5G_SATCP数传问题分析应用总结

【摘要】随着移动网络的不断发展，5G网络已逐渐进入商用元年，相对于传统的LTE网络，5G网络最大的特点是拥有更低的接入时延、更宽的频段资源与更高的速率体验。

伴随5G用户数量的快速增长，开展5G特性研究、提升用户感知显得尤为重要。

在SA网络优化中，存在较多TCP数传问题，此类问题分析较为困难，难以发现，且问题处理往往需要同时多点抓包定位，处理起来周期长、难度大，迫切需要针对TCP数传类问题开展专题性研究分析，总结相关问题经验。

本文针对SA组网模式下TCP数传问题进行研究、分析并梳理出TCP数传六类典型问题加以论证。

【关键字】TCP拥塞控制、TCP问题定界

【业务类别】优化方法、TCP数传问题分析

一、问题描述

在SA网络优化中，存在较多TCP数传问题，此类问题分析较为困难，难以发现，且问题处理往往需要同时多点抓包定位，处理周期长，处理难度大。

迫切需要针对TCP数传类问题开展专题性研究分析，总结相关问题经验。

二、分析过程

1

2

2.1TCP拥塞控制基本原理

现实中TCP网络状态并不是稳定的，随着提供的负载增大，网络吞吐量的增长速率逐渐减小。

在网络吞吐量还没有饱和时，就已经有一部分分组被丢弃了。

当网络的吞吐量远小于理想吞吐量时，网络就进入了轻度拥塞的状态。

当提供的负载达到某一数值时，网络的吞吐量开始下降，这是网络就进入了拥塞状态。

当提供的负载继续增大到某一数值时，网络的吞吐量就下降到零，此时进入死锁。

拥塞控制是通过拥塞窗口处理网络拥塞现象的一种机制。

在拥塞控制中，有一个"拥塞窗口"的概念，该窗口由发送方根据当前计算机网络的拥塞情况来计算，和通知窗口共通作用于发送窗口，"拥塞窗口"的单位也是字节，通常拥塞窗口的初始值为一个最大TCP报文段的大小是,但下面我们以每个传输轮次所能发送TCP数据段（用户数据）的次数作为其单位来描述。

在拥塞控制中，我们主要使用四种算法：

慢启动、拥塞避免、快速重传和快速恢复

1）慢启动

TCP建立之初cwnd=1（MSS），之后每收到1个报文段被确认，cwnd=cwnd+1，直至cwnd≤ssthresh，慢启动结束。

之所以叫慢启动，是相对于没有拥塞控制只有流控的情况下发送端一次发下不超过接收窗口大小的数据来讲的。

2）拥塞避免

cwnd超过慢启动门限即进入拥塞避免阶段，拥塞窗口大小随时间线性上升

3）快速重传

当收到3个（默认3，有些配置为2）重复ACK即启动快速重传，进入快速重传阶段。

快速重传过程中，不需要等到重传定时器超时，收到3个重复ACK后立即重传数据包。

4）快速恢复

快速重传结束后，不进入慢启动阶段，而是进入拥塞避免阶段，这就是快速恢复。

快速过程中慢启动门限更新为当前cwnd的一半。

2.2基于空口灌包快速定界TCP问题

TCP为端到端业务，对于TCP数传类问题，可能为从内容源到终端路径中任一网元引入，因此在开展5GSA优化中，如怀疑存在TCP问题，需要通过空口灌包方式快速定界。

协议规定MAC层支持下行paddingbit的调度，MAC层如果收到的RLC层来水量不足的情况下，基站会根据当前可调度的MCS和RB，选择对应的TBS进行调度，如果“实际业务量”<“调度TBS”，那么TBS中多余的bit填入paddingbit，UE的MAC层在收到这些paddingbit之后丢弃，不上报到RLC层。

因此基站MAC层可在真实业务的基础上，按照空口最大的MCS和可用RB将剩余资源进行paddingbit调度，实现空口MAC层灌包能力，padding包不上报RLC层，不需TCP反馈，因此可用于隔离空口性能，评估是否存在基站以上TCP性能：

定点对比评估FTP下载等TCP业务和基于Padding的空口mac层灌包，如灌包速率与FTP速率大致相当，说明不存在基站以上不存在TCP问题；如灌包速率大于FTP速率，结合上游来水，则可判断基站以上可能存在TCP问题。

2.3TCP数传六类典型问题定界分析

TCP数传六类典型问题包括：

丢包、乱序、重传、网络分片、接收和发送窗口、时延分析等。

2.3.1丢包问题

1）丢包识别原则

丢包对于抓包点来说一般指的是上游丢包。

上游丢包场景初传包在抓包点没有抓到，只抓到了重传的包。

通过识别重传报文的IPID和SeqNo.，如果之前抓包中未收到过此重传报文SeqNo.，且其IP.ID比该SeqNo.后续正常接收的数据包的IP.ID还要大，则判断该SeqNo.的初传数据包在上游丢包，当前接收到的数据包为上游丢包后的重传包。

发生上游丢包应重点排查抓包点上游问题。

2）丢包问题定界

如下图IP.ID为02、SeqNo.为200的TCP报文为初传包，在gNB上游丢包，因此IP.ID为02，SeqNo.为200的数据包在抓包点gNB没抓到，其重传包IP.ID为06，SeqNo.为200，重传包的IP.ID为06，比SeqNo.为300的IP.ID03还大，证明该数据包是在IP.ID03&04&05之后发的，因此该IP.ID06的数据包是IP.ID02的重传包。

通过wireshark->Statistics->TCPStreamGraphs->TCPSequence（TCPTrace）时序图分析所示，蓝色的每一小节为一个是数据包，正常情况下，数据包的接收是连续的，中间没有断链，如果出现断链，则可能是发生了乱序或者丢包。

判断是乱序或丢包则需要看后续收到的数据包的IPID是新IPID还是本来应该有的IPID。

通过wiresharkTCP序号分析发现，SeqNo.在3539849~3568157之间的数据包丢失，即IPID在30679~30703之间的数据包丢包

SeqNo.在3539849~3568157之间的数据包发生重传，其IPID已不再居于30679~30703之间，而是31275~31295，是新的IPID，表明是丢包的重传包。

2.3.2乱序和乱序导致的重传问题

1）乱序识别原则

乱序对于抓包点来说一般指的是上游乱序。

当序列号SeqNo.低的TCP报文先发后至，则出现了乱序，Wireshark便会标记报文为“TCPOutofOrder”。

乱序分为普通乱序（一般深度<3）与深度乱序（一般深度>=3），重点关注深度乱序，深度乱序的SEQNo.有重传包。

上游发生大量乱序或深度乱序导致的重传应重点排查抓包点上游问题。

2）乱序问题定界

如下图IP.ID为02、SeqNo.为200的TCP报文在发送端先发，但是在抓包点却在SeqNo.300之后收到，因此该TCP报文在上游发生了乱序，由于乱序深度为1，为普通乱序。

IP.ID为05、SeqNo.为500的TCP报文在抓包点却在SeqNo.700之后才收到，因此该TCP报文在上游发生了乱序，由于乱序深度为3，为深度乱序，发送端会发生快速重传，会导致发送窗口减半。

通过wireshark->Statistics->TCPStreamGraphs->TCPSequence（TCPTrace）时序图分析所示，SeqNo.小的却后收到，表明发生了乱序：

2.3.3重传问题

1）重传问题识别原则：

重传对于抓包点来说一般指的是下游重传。

下游重传场景初传包在抓包点抓到，而且还抓到了重传的包，同一个SeqNo.在抓包点抓到两次。

发生重传的原因可能是抓包点下游初传包丢包或乱序，造成接收端先收到后续TCP报文，多次给发送端回DupACK，从而引起发送端快速重传。

发生下游重传应重点排查抓包点下游问题。

2）重传问题定界：

如下图IP.ID为05、SeqNo.为500的TCP报文为初传包，在抓包点gNB发往下游后由于下游的原因无法送达接收端，造成接收端先收到后续TCP报文，多次给发送端回DupACK，从而引起发送端快速重传。

此IP.ID为05，SeqNo.为500的数据包在抓包点gNB已抓到，其重传包IP.ID为09，SeqNo.为500，重传包的IP.ID为09，比SeqNo.为600的IP.ID06还大，证明该数据包是在IP.ID06&07&08之后发的，因此该IP.ID09的数据包是IP.ID05的重传包。

如下图的Wireshark分析，抓包点已经抓到了786886121的包，但是下游发来了多个DUPACK，最后导致该TCP报文发生快速重传：

2.3.4网络分片

1）分片原理说明：

MTU:

IP层的最大传输单元，MaximumTransmissionUnit

MSS：

是TCP层最大报文段长度，MaximumSegmentSize，

MSS的值一般为MTU值减去两个首部大小（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes），MTU的值一般默认为1500。

TCP协议在建立连接的时候通常要协商双方的MSS值。

例如：

第一次握手：

接收端向发送端通报自己支持的MSS=1460Byte；第二次握手：

发送端向接收端通报自己支持的MSS=1400Byte；则后续数据包发送时取两者最小值，每条报文的实际净核大小为1400B。

如果IP报文的大小大于MTU，IP层就会将该IP报文进行分片。

对于TCP来说，要尽量避免分片。

因为必须所有分片都到达才能重组成一个包，其中任何一个分片丢失了，都必须重发所有分片。

分片会增大丢包和乱序的概率，同时也会增加时延。

2）网络分片定界：

如果在TCP报文经过的传输网络中有某个设备的MTU设置得太小，则它会将收到的IP报文进行分片。

分片会增大丢包和乱序的概率，同时也会增加时延。

传输中若存在IPSec，IPSec会增加额外的协议头，MSS建议不超过1350，这样MTU就不会超过1500，不会引起分片。

2.3.5TCP接收和发送端口

1）TCP接收窗口分析：

接收窗口受限是指接收端收到了发送方发出的TCP报文段之后，在进行确认时，告知发送端本接收端TCP接收缓存耗尽，请暂停发送数据。

通常分析TCP接收窗口，主要识别三种异常：

Ø接收窗口值逐渐减小为0；

Ø接收窗口值频繁波动；

Ø接收窗口最大只能达到65535。

如果存在上述问题，则有两种可能：

Ø发送端或网络侧发包频率异常；

Ø接收端本身处理能力不足。

此类问题一般都出现在数据接收端，可能的原因如下：

✓接收端配置太低，无法为相关程序进行分配足够的内存；

✓运行在数据接收方的应用程序无法从操作系统得到足够的缓存；

✓运行在数据接收方的应用程序消耗的内存太多，操作系统对其进行了资源的限制；

✓接收端TCP接收窗口太小，导致接收能力受限

2）TCP发送窗口/拥塞窗口分析说明

TCP发送窗口是指TCP发送缓冲区的大小。

由于无法通过TCP抓包报文直接得到发送窗口的大小，只能通过分析已发送未确认的数据量推算TCP发送窗口的大小。

如果发送窗口太小，可能是服务器发送缓存设置得太小，需要优化服务器。

数据发送之后会被缓存在TCP发送缓冲区中，接收到对应的TCPACK后，数据才会被从缓冲区中删除，已发送未确认的数据一定是保存在TCP发送缓冲区中的，换句话说：

TCP发送缓冲区的大小一定大于等于已发送未确认的数据量。

✓已发送未确认的数据量小于接收窗口的大小，说明TCP发送缓冲区已经满了，TCP无法发送更多的数据，这种情况下TCP发送窗口=已发送未确认的数据量

✓已发送未确认的数据量等于接收窗口的大小，说明TCP发送缓冲区还没满，但由于TCP接收窗口的限制，TCP无法发送更多的数据，这种情况下TCP发送窗口≥已发送未确认的数据量=TCP接收窗口。

发送窗口