01

60 秒回答模板

Recv-Q 可以理解为接收方向还没被应用消费的数据量，Send-Q 是发送方向已经由应用写入但还没被对端确认或内核完全发送出去的数据量。对 established 连接来说，Recv-Q 高通常说明本端应用没有及时 recv，或者处理太慢；Send-Q 高通常说明对端接收慢、网络拥塞、发送窗口受限或本端发得太快。对 listen socket，Recv-Q/Send-Q 的含义会和连接队列相关，所以分析时要先看连接状态，再结合进程读写、TCP 窗口、丢包重传和业务负载判断。

考点 Recv-Q 是接收未读
难度 真实面经题
回答目标 讲清方法、取舍和追问
02

深入解析

01

先看连接状态

Recv-Q 和 Send-Q 的解释依赖 socket 状态。已建立连接主要看数据收发队列；监听 socket 则更接近连接队列和 backlog 相关状态，不能混为一谈。

02

Recv-Q 表示接收堆积

对 established 连接，Recv-Q 表示内核接收缓冲区里已经收到、但应用还没读取的数据。它持续升高通常意味着应用消费慢、事件循环卡住或读逻辑阻塞。

03

Send-Q 表示发送堆积

Send-Q 表示本端发送缓冲区中尚未完成发送或确认的数据。它持续升高常见于对端处理慢、对端接收窗口变小、网络拥塞、丢包重传或本端写入过快。

04

结合系统指标定位

排查时要一起看进程 CPU、线程栈、应用日志、socket 状态、重传、窗口大小、网卡丢包和对端负载。只看 netstat 的一个数字容易误判。

05

联系阻塞非阻塞

接收队列满时对端发送会被 TCP 流控影响；发送队列满时本端阻塞写可能卡住，非阻塞写会返回 EAGAIN，应用需要等待可写事件再继续发送。

03

易错点

  • 不要把 Recv-Q 和 Send-Q 都解释成应用层队列，它们首先是 socket/内核缓冲相关指标。
  • 不要忽略连接状态，监听 socket 和已建立连接的含义不同。
  • 不要看到 Send-Q 高就只怪本机，网络和对端也可能是原因。
  • 不要脱离应用读写速度分析，队列指标最终要回到消费和发送能力。
04

面试官追问

Recv-Q 持续升高怎么排查？

先定位对应进程和连接，检查应用是否及时读 socket、线程是否阻塞、CPU 是否打满、事件循环是否卡住，再看接收缓冲和对端发送情况。

Send-Q 高一定是本端问题吗？

不一定。可能是对端不读、对端窗口小、网络拥塞或丢包，也可能是本端写入速率超过实际发送能力。

非阻塞写遇到发送缓冲区满会怎样？

通常返回 EAGAIN 或 EWOULDBLOCK，应用应注册可写事件，等内核发送队列腾出空间后继续写。