5G优化案例TCP问题定界六大方向分析总结.docx

5G优化案例TCP问题定界六大方向分析总结.docx

《5G优化案例TCP问题定界六大方向分析总结.docx》由会员分享，可在线阅读，更多相关《5G优化案例TCP问题定界六大方向分析总结.docx（9页珍藏版）》请在冰点文库上搜索。

5G优化案例TCP问题定界六大方向分析总结

TCP问题定界六大方向分析总结

【摘要】QZDXSA组网，5G建设加速中。

对网格测速中往往会遇到速率低的问题，其中出现“来水不足”导致速率低是常见现象，需要拉通传输，对TCP问题进行分析。

本文针对TCP需要重点分析的六大方向：

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

为优化人员提供基础说明及分析优化思路。

【关键字】来水不足、TCP问题、速率低

【业务类别】无线网、传输网、方案类

TCP问题定界六大方向

TCP需要重点分析的六类问题包括：

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

1、丢包问题

1.1丢包识别原则

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

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

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

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

1.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、乱序和乱序导致的重传问题

2.1乱序识别原则

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

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

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

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

2.2乱序问题举例

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

IP.ID为05、SeqNo.为500的TCP报文在抓包点却在Seq

No.700之后才收到，因此该TCP报文在上游发生了乱序，由于乱序深度为3，为深度乱序，发送端会发生快速重传，会导致发送窗口减半。

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

3、重传问题

3.1重传问题识别原则

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

下游重传场景初传包在抓包点抓

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

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

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

3.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报文发生快速重传：

4、网络分片

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来说，要尽量避免分片。

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

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

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

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

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

5、TCP接收和发送窗口

5.1TCP接收窗口分析

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

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

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

✓接收窗口值频繁波动；

✓接收窗口最大只能达到65535如果存在上述问题，则有两种可能：

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

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

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

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

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

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

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

5.2TCP发送窗口/拥塞窗口分析

需要说明的是：

严格来讲，发送窗口是指TCP发送缓冲区的大小。

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

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

原理：

数据发送之后会被缓存在TCP发送缓冲区中，接收到对应的TCPACK

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

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

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

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

已发送未确认的数据量（字节数）一般被称为Flightsize。

Flightsize的统计方法：

针对每个TCPdata进行统计，将之前没有收到对应TCPACK的所有TCPdata净荷累加起来即可。

或者这样计算：

用当前TCPdata中的sequencenumber加上MSS，再减去前面离得最近的一个TCPACK中的acknumber。

发送窗口满在Wireshark中如下图所示：

纵轴是窗口大小，单位是字节，横轴是时间；最上面的浅绿色的线是接收窗口曲线图。

蓝色的线是发送的数据字节数，当蓝色的发送数据顶到浅绿色接收窗口线，表明发送窗口已满。

如下图所示，蓝色发送数据线多次顶到浅绿色线，表明发送窗口已满。

同时发送窗口和接收窗口都被受限在65535字节。

需要优化服务器和接收端TCP设置。

6、时延

6.1时延概念说明

时延是影响速率的一个关键因素，当TCP窗口

RTT越小，吞吐率越大（BDP=bandwidth（b/s）×round-triptime（s）一般称之为带宽时延乘积

（BandwidthDelayProduct））

TCPRTT（RoundTripTime，往返时延）时延分析统计机制为在每个抓包点，针对每个tcp报文SeqNo.，找到其对应的tcpack，算出两者之间的时间差，即可得到RTT。

6.1时延问题举例

如下图所示，在发送端Server抓包，可以获得TCP包发出到接收到其ACK的端到端往返时延RTT；在gNodeB侧抓包，可以获得gNodeB收到该TCP包的时间以及其ACK的时间之间的差，即空口以下的RTT；在UE侧抓包，可以获得UE收到该TCP包的时间以及回ACK的时间之间的差，即UE的处理时延RTT。

gNodeB测量到的RTT减去UE的处理时延RTT，即为空口的RTT；Server测量的RTT减

去gNodeB测量的RTT，即为基站到服务器之间的RTT。

时延分析推荐使用FMAIPPA的多点对包功能进行分析。

7、应用成效

根据案例的分析总结，大大提高了测速过程中遇到来水不足的分析效率与成果，QZDX移动根据此方法，解决网格路测来水不足问题，将SA网格的路测速率提高到符合精品网格速率。

该方法具有较强的推广性，目前已经全省推广。