在前文中讲述了Linux服务端TCP的某个链路变成CLOSE_WAIT状态，然后由于客户端已经关闭了（发送了RST标志的报文），那么服务端如果继续向这个链路中写入数据的话就会收到SIGPIPE信号而终止，这篇文章主要通过客户端进入CLOSE_WAIT后由于收到服务端产生的RST标志报文进入死循环的情况。注：RST表示复位，用来关闭异常的连接。

- 阅读剩余部分 -

在前文中讲述了Linux服务端TCP通信出现CLOSE_WAIT状态的原因，这篇文章主要通过一个实例演示它个一个“恶劣”影响：直接使服务端进程Down掉。

- 阅读剩余部分 -

前文《使用TCPDUMP和Wireshark排查服务端CLOSE_WAIT（一）》通过TCPDUMP和Wireshark在利用CentOS7作为服务端、Windows10作为客户端，模拟演示了一个TCP通信的CLOSE_WAIT状态，这篇文章主要利用前文的数据尝试解释Linux服务端产生CLOSE_WAIT状态的原因。

- 阅读剩余部分 -

在Linux后端服务网络通信开发中，可能会遇到CLOSE_WAIT的状况。引起TCP CLOSE_WAIT状态的情况很多，归根结底还是由于被动关闭的一方没有关闭socket链路导致的。这篇文章主要是通过用一个简单的例子通过TCPDUMP和Wireshark这两个工具来模拟产生CLOSE_WAIT的情况，下一篇主要是对这个问题的原理解释。

- 阅读剩余部分 -

在Linux TCP通信的调试中，tcpdump应该算是很好的一个工具。这篇文章主要使用Windows作为客户端，向作为服务端的Linux中的一个socket监听端口发送报文信息，然后在Linux中用TCPDUMP工具进行抓包。通过这个实例，可以较为完整的了解TCP通信中的“三次握手”等过程。

- 阅读剩余部分 -