求助一个网络延时的问题
68 views
Skip to first unread message
Bamboo Hui
Nov 6, 2015, 10:28:09 PM11/6/15
to sh...@googlegroups.com
我们现在有一个网络应用对延时比较敏感，通过wireshark抓包（见下图）发现：
C/S间的网络每隔一段时间就会出现一个200ms的时延
（如图中蓝色部分与其后的一个包相差200ms，可以发现这类延时200ms的包都只是ACK，图中包的长度都是54）
工作环境：
服务端：CentOS 6.5，网络层用的是ACE库
客户端：Windows 7，网络层用的C#的API
ping: 客户端和服务端的平均时延不超过1msC/S间的网络每隔一段时间就会出现一个200ms的时延
（如图中蓝色部分与其后的一个包相差200ms，可以发现这类延时200ms的包都只是ACK，图中包的长度都是54）
工作环境：
服务端：CentOS 6.5，网络层用的是ACE库
客户端：Windows 7，网络层用的C#的API
其它：服务端，客户端都有20ms消息缓冲，即最长40ms的缓冲时间；服务端对数据的处理时间在10-30ms之间
google了一下"tcp 200ms"得到的相差答案基本都是: TCP的Nagle algorithm引起的，Windows下可以关闭（https://support.microsoft.com/en-us/kb/214397）
将客户端的socket设定为 TCP_NODELAY，问题仍然没有解决。
大家有什么思路指点一二？谢谢
将客户端的socket设定为 TCP_NODELAY，问题仍然没有解决。
大家有什么思路指点一二？谢谢
Shell Xu
Nov 7, 2015, 1:29:06 AM11/7/15
to shlug
你只在单端抓包。在对端抓一下吧，我怀疑你对端传回的ack丢了。
--
-- You received this message because you are subscribed to the Google Groups Shanghai Linux User Group group. To post to this group, send email to sh...@googlegroups.com. To unsubscribe from this group, send email to shlug+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/shlug?hl=zh-CN
---
您收到此邮件是因为您订阅了Google网上论坛上的“Shanghai Linux User Group”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到shlug+un...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。
彼節者有間，而刀刃者無厚；以無厚入有間，恢恢乎其於游刃必有餘地矣。
blog: http://shell909090.org/blog/
blog: http://shell909090.org/blog/
Qian Hong
Nov 7, 2015, 2:39:27 PM11/7/15
to sh...@googlegroups.com
Hi,
> （如图中蓝色部分与其后的一个包相差200ms，可以发现这类延时200ms的包都只是ACK，图中包的长度都是54）
我几年前在红帽内核测试组做网卡驱动测试实习生，当时碰到一个网卡驱动的bug，就是客户的机器平均每天会随机出现两三次莫名其妙的网卡暂停，每次暂停200ms左右。我对这个bug印象深刻，是因为我当时花了很大功夫，都没有办法重现，有可能是网络环境不同没有造成触发bug的条件，也有可能是硬件规格不完全一样。我现在记不清细节了，但是看到你的一台机器是Centos，又看到随机延迟200ms，第一反应就想到这个印象深刻的bug了。
我只是联想到了而已，不一定帮得上忙。祝好运。
--
Regards,
Qian Hong
-
http://www.winehq.org
> （如图中蓝色部分与其后的一个包相差200ms，可以发现这类延时200ms的包都只是ACK，图中包的长度都是54）
我几年前在红帽内核测试组做网卡驱动测试实习生，当时碰到一个网卡驱动的bug，就是客户的机器平均每天会随机出现两三次莫名其妙的网卡暂停，每次暂停200ms左右。我对这个bug印象深刻，是因为我当时花了很大功夫，都没有办法重现，有可能是网络环境不同没有造成触发bug的条件，也有可能是硬件规格不完全一样。我现在记不清细节了，但是看到你的一台机器是Centos，又看到随机延迟200ms，第一反应就想到这个印象深刻的bug了。
我只是联想到了而已，不一定帮得上忙。祝好运。
--
Regards,
Qian Hong
-
http://www.winehq.org
Qian Hong
Nov 7, 2015, 2:45:41 PM11/7/15
to sh...@googlegroups.com
2015-11-08 3:38 GMT+08:00 Qian Hong <frac...@gmail.com>:
> 我只是联想到了而已，不一定帮得上忙。祝好运。
当时的记忆已经有些失真了，邮箱记录也搜不到过去的bug了，现在也没有RHEL
bugzilla的访问权限了，不过我google了一下，找到这个链接，跟记忆有点像，但是细节不多：
http://unix.stackexchange.com/questions/31158/200ms-latency-between-tcp-send-and-tcpdump-only-with-large-messages
还是只能祝你好运：）
> 我只是联想到了而已，不一定帮得上忙。祝好运。
当时的记忆已经有些失真了，邮箱记录也搜不到过去的bug了，现在也没有RHEL
bugzilla的访问权限了，不过我google了一下，找到这个链接，跟记忆有点像，但是细节不多：
http://unix.stackexchange.com/questions/31158/200ms-latency-between-tcp-send-and-tcpdump-only-with-large-messages
还是只能祝你好运：）
Bamboo Hui
Nov 9, 2015, 2:03:28 AM11/9/15
to sh...@googlegroups.com
谢谢！
上午在server和client两边都抓包，对比seq和 ack seq，应该是没有出现丢包的情况。
（下面两张图，第一张为客户端的抓包，第二张在服务端抓的包，高亮的四项为是对比发送序号和确认序号对上的记录，中间没有重传）
上午在server和client两边都抓包，对比seq和 ack seq，应该是没有出现丢包的情况。
（下面两张图，第一张为客户端的抓包，第二张在服务端抓的包，高亮的四项为是对比发送序号和确认序号对上的记录，中间没有重传）
Bamboo Hui
Nov 9, 2015, 2:04:00 AM11/9/15
to sh...@googlegroups.com
谢谢！正在下驱动试试
--
-- You received this message because you are subscribed to the Google Groups Shanghai Linux User Group group. To post to this group, send email to sh...@googlegroups.com. To unsubscribe from this group, send email to shlug+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/shlug?hl=zh-CN
---
您收到此邮件是因为您订阅了 Google 网上论坛的“Shanghai Linux User Group”群组。
Shell Xu
Nov 9, 2015, 2:27:39 AM11/9/15
to shlug
唔。确实不是重传。但是你那两个报文的性质不一样啊。第一个报文讲的是收到了对方的数据并确认，第二个报文里面携带了载荷。正常考虑，这是一个程序收到数据后，200ms后发送回数据的正常场景。
当然，你上面说了，这个得算非预期的。如果从延迟的稳定性考虑，nagle算法当然是第一个嫌疑犯。不过nagle协议需要在服务器和客户端两端关闭，你都关闭了么？我在截图里看不出你客户端和服务器端的顺序。
当然，你上面说了，这个得算非预期的。如果从延迟的稳定性考虑，nagle算法当然是第一个嫌疑犯。不过nagle协议需要在服务器和客户端两端关闭，你都关闭了么？我在截图里看不出你客户端和服务器端的顺序。
Reply all
Reply to author
Forward
0 new messages