TypeCodes

Linux TCP客户端出现CLOSE_WAIT后进入死循环

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

- 阅读剩余部分 -

Linux TCP通信出现CLOSE_WAIT后导致服务端进程挂掉

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

CentOS服务端建立监听端口

1 CentOS服务端建立监听端口

如上图所示,在虚拟机CentOS7服务器(192.168.1.178)中打开一个终端界面,建立8000端口的监听服务(PID …

- 阅读剩余部分 -

使用TCPDUMP和Wireshark排查服务端CLOSE_WAIT(二)

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

客户端和服务端的TCP通信流程

1 原因分析:从客户端和服务端TCP通信的流程出发

从前文中的tcpdump和Wireshark抓包都可看到当Windows客户端关闭后,会主动发送带有FIN+ACK标志的报文给Linux服务端。那么从上图TCP客户端和服务端的通信流程图开始分析:客户端先进入FIN_WAIT_1状态,在收到服务端应答的 …

- 阅读剩余部分 -

使用TCPDUMP和Wireshark排查服务端CLOSE_WAIT(一)

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

CentOS服务端建立监听端口

1 CentOS服务端建立监听端口

如上图所示,在虚拟机CentOS7服务器(192.168.1.178)中打开一个终端界面,然后使用下面这个简单的服务端程序,建立8000端口的监听服务(PID …

- 阅读剩余部分 -

Linux中使用TCPDUMP进行简单的TCP抓包

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

Linux中使用TCPDUMP进行简单的TCP抓包

1 CentOS服务端建立监听并抓包

在虚拟机服务器(192.168.1.178)使用下面这个简单的服务端程序,建立8000端口的监听服务,然后使用 …

- 阅读剩余部分 -

Linux TCP连接Connection Refused和Connection timed out的问题

前段时间和其它系统做联调测试,对方系统采用的是负载均衡模式。调试时采用的是多台手机作为客户端发送到对方负载均衡服务器,然后再把报文转发送到我这边的服务端。在测试的时候,对方测试人员说有的手机客户端会偶尔出现报文发不过来的情况。

故事有点长,先发一张tcp三次握手的过程图镇楼~

Linux tcp三次握手

1 自己服务端的socket监听出现问题

一开始认为可能是自己作为服务端的监听有问题,因为后面排查监听端口的时候发现了close_wait的情况。当时没多想,认为对方负载均衡不会出错(先前跟其它系统联调过了),就急着解决close_wait的问题去了。

可是后面测试的时候,尽管服务端监听没有任何异常 …

- 阅读剩余部分 -