关于测试结果中的 udpRt 是什么意思 ?

[penghaiheng]

我也是在用 UDP protocol 测试的时候才看到 UdpRt 会有数据产生. 而且数量还不少.

有点不太明白 udpRt , 本身没有连接, client 与 server 本身也不共享会话和报文信息. 那他们会察觉丢失并进行重传么 ?

UDP的重传有点不好理解. 是因为测试中接口有收到非测试源的任意UDP报文么 ?

Total Numbers:
pktRx   13,848,639         pktTx    14,763,964         bitsRx   165,740,300,384    bitsTx  176,695,051,936    dropTx  0                 
tcpRx   0                  tcpTx    0                  udpRx    13,848,626         udpTx   14,763,958        
arpRx   4                  arpTx    6                  icmpRx   0                  icmpTx  0                 
tosRx   0                  otherRx  9                  badRx    0                 
udpRt   2,171,519🥺          udpDrop  6                  tcpDrop  0                 
skOpen  98                 skClose  0                  skCon    98                 skErr   0                 
ierrors 0                  oerrors  0                  imissed  0 

[pengjianzhang]

可以理解客户端与服务器在ping-pong，客户端在一个interval内没有收到服务器的响应，就会重发一次，如果发生了重传，说明网络层面有问题，可能是网卡丢包，或者交换机丢包等
如果喜欢dperf，加个star哦，谢谢

[penghaiheng]

我在每段测试中, 收发包都是一样的. 为什么也会有 重传呢 ? 毕竟是UDP 也不会主动发才对.

我比较好奇, 为什么会有这样的重传机制. 一般来说, 要用UDP进行测试的时候, 是为了测得设备的稳定性和丢包率.

两端的数据无法保持一致, 如何确认刚好卡在 1 秒统计之外的某个(些) Expect 的包 , 在下一秒的时候抵达, 其实数据上是正常的了. 这样会在 第二秒统计的时候, 发出重传, 但是重传的报文是由谁确认的呢 ? TCP 的重传是机制中有包含, 可以确定报文的唯一性. UDP 的重传貌似不太对劲.

我抓包查看了一下, 发现 server 和client 发送和接收的报文除了不只是五元组, payload 都是一模一样的. 他们应该没有通过报文内容进行丢包的确认. 比如 "第N个包, 1.1.1.1:1000 -> 2.2.2.2:1001" 丢了, 它是如何确认这个包被丢掉了呢 ? 是因为它没有收到 "2.2.2.2:1001 -> 1.1.1.1:1000" 的报文么? 所以判定丢失了 ?

如果是这样的话， 那下一个发包周期里就会有 2 种情况 ;

1. 如果要额外增加这个重传报文. 那 pps 就会超出原有预期的数量变为 预期pps+1. 这样收端的 pps 就能正常. 这样对于数据的统计会更麻烦.
2. 如果预期pps 不变, 那么 pps 保持正常. 但是在对端收包统计的时候, 就会变为 pps+1

总感觉哪里不太对劲.

比如 : 在 第 20秒 - 22秒 之间的日志是如下这样的
client.log

seconds 20                 cpuUsage 0   
pktRx   10,000             pktTx    10,000             bitsRx   119,680,000        bitsTx  119,680,000        dropTx  0                 
tcpRx   0                  tcpTx    0                  udpRx    10,000             udpTx   10,000            
arpRx   0                  arpTx    0                  icmpRx   0                  icmpTx  0                 
tosRx   0                  otherRx  0                  badRx    0                 
udpRt   21                 udpDrop  0                  tcpDrop  0                 
skOpen  0                  skClose  0                  skCon    10                 skErr   0                 
ierrors 0                  oerrors  0                  imissed  0                 


seconds 21                 cpuUsage 0   
pktRx   10,000             pktTx    10,000             bitsRx   119,680,000        bitsTx  119,680,000        dropTx  0                 
tcpRx   0                  tcpTx    0                  udpRx    10,000             udpTx   10,000            
arpRx   0                  arpTx    0                  icmpRx   0                  icmpTx  0                 
tosRx   0                  otherRx  0                  badRx    0                 
udpRt   4                  udpDrop  0                  tcpDrop  0                 
skOpen  0                  skClose  0                  skCon    10                 skErr   0                 
ierrors 0                  oerrors  0                  imissed  0                 


seconds 22                 cpuUsage 0   
pktRx   10,000             pktTx    10,000             bitsRx   119,680,000        bitsTx  119,680,000        dropTx  0                 
tcpRx   0                  tcpTx    0                  udpRx    10,000             udpTx   10,000            
arpRx   0                  arpTx    0                  icmpRx   0                  icmpTx  0                 
tosRx   0                  otherRx  0                  badRx    0                 
udpRt   15                 udpDrop  0                  tcpDrop  0                 
skOpen  0                  skClose  0                  skCon    10                 skErr   0                 
ierrors 0                  oerrors  0                  imissed  0                 

server.log

seconds 20                 cpuUsage 0   
pktRx   10,000             pktTx    10,000             bitsRx   119,680,000        bitsTx  119,680,000        dropTx  0                 
tcpRx   0                  tcpTx    0                  udpRx    10,000             udpTx   10,000            
arpRx   0                  arpTx    0                  icmpRx   0                  icmpTx  0                 
tosRx   0                  otherRx  0                  badRx    0                 
udpRt   0                  udpDrop  0                  tcpDrop  0                 
skOpen  0                  skClose  0                  skCon    0                  skErr   0                 
ierrors 0                  oerrors  0                  imissed  0                 


seconds 21                 cpuUsage 0   
pktRx   10,001             pktTx    10,000             bitsRx   119,680,480        bitsTx  119,680,000        dropTx  0                 
tcpRx   0                  tcpTx    0                  udpRx    10,000             udpTx   10,000            
arpRx   1                  arpTx    0                  icmpRx   0                  icmpTx  0                 
tosRx   0                  otherRx  0                  badRx    0                 
udpRt   0                  udpDrop  0                  tcpDrop  0                 
skOpen  0                  skClose  0                  skCon    0                  skErr   0                 
ierrors 0                  oerrors  0                  imissed  0                 


seconds 22                 cpuUsage 0   
pktRx   10,001             pktTx    10,000             bitsRx   119,680,480        bitsTx  119,680,000        dropTx  0                 
tcpRx   0                  tcpTx    0                  udpRx    10,000             udpTx   10,000            
arpRx   1                  arpTx    0                  icmpRx   0                  icmpTx  0                 
tosRx   0                  otherRx  0                  badRx    0                 
udpRt   0                  udpDrop  0                  tcpDrop  0                 
skOpen  0                  skClose  0                  skCon    0                  skErr   0                 
ierrors 0                  oerrors  0                  imissed  0 

互为收发报文时, client 的日志就会有 udpRt, 但是 对于 server , 只发送了 10,000 个包, client 收到 10,000 , 这不是相等么 ? 这样为什么会触发重传呢 ?

[penghaiheng]

应该是没有问题的. 尝试问了 github copilot , udpRt 貌似只是计数, 因为我之前的测试方法里, 我配置的 keepalive周期是 us 级的, 很容易触发接收统计出偏差. 应该是我这种测试方法和测试的设备会容易出现统计周期内发送状态与接收的间隔. 我以为 udpRt 会实际发送报文. 应该是不会插队发送的 😢