故障发散-Recv-Q阻塞

之前有个开发遇到个生产问题，开发发现有时候CS之间的心跳直接丢了，查看日志发现客户端一直没收到心跳报文，但服务端其实已经把报文发了，觉得很奇怪，TCP 是可靠链接，不可能丢了吧，最终是发现了netstat 里的recv-q 有积压导致的，问题虽然解决了，但还是需要复盘一下，看看细节。
先看下啥是Recv-Q 和 Send-Q

Recv-Q

Established: The count of bytes not copied by the user program connected to this socket. Listening: Since Kernel 2.6.18 this column contains the current syn backlog.
单位是字节，是表示程序总共还有多少字节的数据没有从内核空间的套接字缓存拷贝到用户空间。

Send-Q

Established: The count of bytes not acknowledged by the remote host. Listening: Since Kernel 2.6.18 this column contains the maximum size of the syn backlog.
单位是字节，是表示远程主机还没有ack的数据包的大小。

这2个Q本质上操作的数据其实是socket 上的缓存数据以及用户进程的缓存数据，对应的分别是recv() 和 send() 方法， 之后的发送接收都是纯TCP来操作的，和socket关系了，所以一般发现recv-q 阻塞了，其实和tcp关系已经不大了，因为tcp的可靠性