这几天因为业务上的需求对两台主机的高并发报文进行一些测试,捉包发现一些问题。
测试场景:
主机A:172.18.18.15 做为服务器端,不停地向主机B发送报文。A机采用epoll(IO复用)的方式串行非阻塞发包。
主机B : 172.18.18.99 做为客户端,启动多个进程(100个)连接A机,建立不同的socket(端口)与主机进行通讯,
不停接收主机报文。
现象:
正常情况下,A机发送一个报文耗时15us。100个包正常来说1.5ms就可以搞定,但从程序日志来看经常出现
最后2-7个包会与第一个包有200ms+的时间差距。在A机上捉包发现出现了附录3种异常的报文,其中只要出
现TCP Retransmission(重发)就会有200ms的时间差,这个时间差应该是RTO的时间,从B机捉包发现,
这些包第一次确实没有出现在B机上,只有重发第二次才到,也就是第一次发的时候丢包的。但奇怪的是两
台机在同一个机房,网卡与交换机都至少是100M,网卡甚至是1000M的。
我们最大的包大概是500Byte, 100个包,50K。1.5ms发50K, 也就达到 33MB/s,转成小b, 达到了264Mb/s,
是不是因为这个原因占满了带宽导致重发呢?
附录:
[TCP Previous segment lost]
发现大量的TCP Previous segment lost.这种应该是对方回了个ACK,而A机自己下个包的seq比上个ACK要高,也就是有个包和ACK丢了。
实际上应该是发了的,应该是tcpdump没捉到。
[TCP ACKed lost segment]
"TCP Acked lost segment" These are ack's that ethereal can't match with a sent segment. Are ACK that Ethereal detects, but cant see the segment sent.
这个的意思应该是收到B机的ACK但A机找不到对应的包,应该也跟上一个类似,实际是发了,但tcpdump没捉到。
[TCP Retransmission] 这个是重点,包出现重发。
[参考资料]