为什么客户端在475ms之后发送FIN ACK?为什么这么慢?他应该立即发送FIN ACK.我有很多这样的情况.整个流量的约1%是延迟FIN ACK的请求.
客户端上的cpu空闲大概是99%,所以没有什么可以排除cpu的.
如何调试?可能是什么
有没有需要调整的sysctl选项?
截图第二列是数据包之间经过的时间.
Link to bigger picture.
解决方法 此行为是 RFC1122 TCP stack的延迟ACK功能.通常你应该把TCP_QUICKACK选项添加到你的Linux TCP socket到disable delayed ACK中,但是我觉得JavaScript Node.Js API是不明显的(我只看到了TCP_NODELAY选项的socket.setNoDelay).
所以你的想法应用一个system-wide change on TCP stack似乎很好,但我发现没有sysctl匹配这个套接字选项的行为.这是另一个full list with explanation.
总结以上是内存溢出为你收集整理的linux – 客户端向服务器发送延迟FIN ACK(〜500ms)全部内容,希望文章能够帮你解决linux – 客户端向服务器发送延迟FIN ACK(〜500ms)所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)