Linux TCP：发送方的高 Send-Q，接收方的零 Recv-Q答案

【问题标题】：Linux TCP: high Send-Q on sender, zero Recv-Q on receiverLinux TCP：发送方的高 Send-Q，接收方的零 Recv-Q
【发布时间】：2017-05-09 20:53:06
【问题描述】：

怎么会这样：

两台机器之间有一个 TCP 套接字
在一些成功的双向通信之后，发送方应用程序在写入套接字时卡住，而接收方在读取时卡住了
netstat 报告发送方套接字的高 Send-Q（几兆字节）（即使等待几个小时后值也不会改变）
netstat 报告接收器上套接字的 Recv-Q 为零
tcpdump 报告套接字上的唯一活动是周期性（每两分钟）的 ACK，没有来自发送方的数据，以及没有来自接收方的数据的即时 ACK 响应

为什么发送方机器不尝试将排队的数据发送给接收方？

【问题讨论】：

你没有发布任何代码，所以没有什么可做的。尝试检查当前 TCP 窗口大小的周期性 ACK（可能是 TCP keepalive）的内容。
是的，它必须是 TCP keepalive。每次发送方窗口大小为 40822，接收方窗口大小为 31883。
在接收端闻起来像一个错误，没有消耗来自套接字的所有字节。但是你没有发布任何代码，所以没有办法知道。
我测试了这个假设，但是当接收器应用程序无法使用传入数据时，接收器套接字上的 Recv-Q 保持在远高于预期的零以上。我没有小的或可重复的测试用例，我怀疑这个问题只发生在网络暂时丢失一些 IP 数据包时。我不寻求有关应用程序代码的帮助，因为鉴于数据位于发送方内核缓冲区中，它似乎没有错，但寻求帮助以了解似乎不可能的 Linux 内核状态。
@OrivejDesh 你能找到这个的根本原因吗？

标签： linux sockets tcp

【解决方案1】：

我也有同样的问题，可能conntrack在接收端被删除了，检查你的 /proc/net/nf_conntrack文件，如果没有这个socket的信息，那就有问题了

另见：Connection Reset By Peer - with driver 2.8.0 and mongo 4.0.9 on a k8s cluster

【讨论】：

这并不能真正回答问题。如果您有其他问题，可以点击提问。要在此问题有新答案时收到通知，您可以follow this question。一旦你有足够的reputation，你也可以add a bounty 来引起对这个问题的更多关注。 - From Review

【解决方案2】：

这很可能是由其他问题引起的，但如果您没有尝试过，下面可能会有所帮助（这些数字是示例，请查找您自己的数字）：

估计发送方和接收方文件系统的读/写速度以及网络速度，并在 rsync 中设置适当的带宽限制：--bwlimit=1024 (1024 KBps )
如果发送方和接收方在此本地网络中有专用 NIC，请帮自己一个忙，增加这些 NIC 上的 MTU：ifconfig eth1 mtu 65744
增加发送方传输队列长度：ifconfig eth1 txqueuelen 4096
增加内核发送/接收内存：
将这些添加到 /etc/sysctl.conf 文件
net.core.wmem_max=16777216
net.core.rmem_max=16777216
net.ipv4.tcp_rmem=4096 262144 16777216
net.ipv4.tcp_wmem=4096 262144 16777216
之后运行 sysctl -p。
如果您 rsync 一个非常大的文件系统，请确保 fs.file-max 足够大，
进行检查：sysctl fs.file-max
要增加它，请在文件 /etc/sysctl.conf 中添加一行 fs.file-max=327679，
在您的 rsync 用户上运行：ulimit -n 327679

【讨论】：

【解决方案3】：

在我的情况下，客户端正在以 8KB 的块写入数据，而服务器试图读取 8KB，然后服务器会将其写入 RAID0 磁盘。对于上传大文件，我遇到了类似的情况，增加从服务器端套接字读取的数据量有所帮助。我将从套接字读取的内部缓冲区的大小提高到 1MB（从 8 kB）并且它有所帮助。我不确定是因为 RAID 还是 tcp，但这可能是您可能想要尝试的另一件事。

【讨论】：