客户端向服务器发送延迟的 FIN ACK (~500ms) [英] Client sends delayed FIN ACK (~500ms) to server

问题描述

我有一个 node.js 客户端 (10.177.62.7) 从服务器 (10.177.0.1) 的 http 休息服务请求一些数据.客户端只是使用 node.js http.request() 方法 (agent=false).客户端在 Ubuntu 11.10 机器上.

为什么客户端在 475 毫秒后发送 FIN ACK?为何这么慢?他应该立即发送FIN ACK.我有很多这样的情况.大约 1% 的整个流量是带有延迟 FIN ACK 的请求.

客户端上的 CPU 空闲率约为 99%，因此没有消耗 CPU.

如何调试?会是什么呢?我需要调整任何 sysctl 选项吗?

屏幕截图的第二列是数据包之间经过的时间.

.

通常您应该将 TCP_QUICKACK 选项添加到您的 Linux TCP 套接字 到 禁用延迟 ACK 但我认为 JavaScript Node.js 并不明显API(我只看到 socket.setNoDelay 对于 TCP_NODELAY 选项).

所以您在 TCP 堆栈上应用 系统范围更改 的想法似乎不错，但我找不到与此套接字选项行为匹配的 sysctl.这是另一个完整列表和解释.

I have a node.js client (10.177.62.7) requesting some data from http rest service from server (10.177.0.1). Client is simply using node.js http.request() method (agent=false). Client is on Ubuntu 11.10 box.

Why client sends FIN ACK after 475ms? Why so slow? He should send FIN ACK immediately. I have many situations like this. About 1% of whole traffic is request with delayed FIN ACK.

Cpu idle on the client is about 99%, so nothing is draining CPU.

How to debug this? What could it be? Is there any sysctl option I need to tune?

On screenshot 2nd column is the elapsed time between packets.

Link to bigger picture.

解决方案

This behaviour is the Delayed ACK feature of RFC1122 TCP stack.

Normally you should add the TCP_QUICKACK option to your Linux TCP socket to disable delayed ACK but I think it is not obvious with JavaScript Node.js API (I only saw socket.setNoDelay for TCP_NODELAY option).

So your idea to apply a system-wide change on TCP stack seems good but I found no sysctl matching this socket option behaviour. Here is another full list with explanation.

这篇关于客户端向服务器发送延迟的 FIN ACK (~500ms)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！