分析tcp-rst数据报文产生场景以及判断谁主动断开连接

在linux平台上使用tcpdump抓包分析tcp socket传递数据的过程。可以使用以下命令 tcpdump -i INTERFACE_NAME -nn -l -X -S -s0 -c PACKET_NUM "tcp[tcpflags] & (tcp-syn | tcp-fin | tcp-rst) != 0 and src IP_ADDR and port PORT"，该命令可以忽略实际传递的数据，有利于分析连接在断开过程中到底传递了什么信息。在实际工作中，需要根据连接断开过程传递的信息来判断到底是哪一方主动断开连接的。

教科书般的四次挥手在实际应用中，很难被发现。主要的原因在于连接在非空闲态下断开的，即当tcp缓冲区还有未读取的数据时，或者还在传递数据时。教科书般的四次挥手可以很容易的推断出，哪一方主动断开连接。因为主动断开的一方会率先发送携带tcp-fin标识的数据报文。只要找到了第一个携带tcp-fin标识的数据报文，根据tcp-fin报文的传递方向就可以推断出来哪一方主动断开连接。

在实际应用中经常发现连接断开时会出现携带tcp-rst标识的数据报文。有时候甚至只有一个携带tcp-rst标识的数据报文。如何推断哪一方主动断开连接的呢？tcp-rst标识的数据报文的产生原因有哪些呢？

首先概括一下携带tcp-rst标识的数据报文产生的情况：

1.创建连接时，服务端口号未打开。当发起连接的一方向未监听该端口号的另一方发送携带tcp-syn标识的数据报文，接收方内核在协议栈处理的过程中，发现根本不存在那样的服务，于是向发送方回传携带tcp-rst标识的数据报文。

2.创建连接时，设置请求超时选项。假设主机A向主机B发送携带tcp-syn标识的数据报文。主机B收到来自主机A的数据报文后，回传携带tcp-syn和tcp-ack标识的数据报文。主机A却向主机B响应携带tcp-rst标识的数据报文。由于主机A在创建出socket描述符之后，设置了recv超时套接字选项。当主机A在收到主机B发送的携带tcp-syn和tcp-ack标识的数据报文之前，已经触发接收超时。这时主机A已经断开了连接，在三次握手的过程中，连接发生断开并不会产生携带tcp-fin标识的数据报文，而是默默的等待对方发送数据报文过来，一旦接收到对方发送过来的数据报文，内核协议栈认为不存在监听临时端口号的进程，于是发送了携带tcp-rst标识的数据报文。

3.tcp缓冲区还有数据未接收时，当关闭tcp连接时。linux内核协议栈会决定发送携带tcp-fin还是tcp-rst标识的数据报文。如果在关闭时，tcp缓冲区中还有未读取的数据，那么内核协议栈将会响应携带tcp-rst标识的数据报文。请注意携带tcp-rst标识的数据报文是不需要接收方确认的。

4.在一个关闭的socket描述符上接收到数据时。linux内核协议栈在传输层解析数据报文后，需要向指定端口所在的进程的用户态拷贝数据报文。由于那样的连接不存在了，内核协议栈就无法通过指定端口号找到相应的应用进程，因此向发送发发送携带tcp-rst标识的数据报文。

以上是携带tcp-rst标识的数据报文产生的主要场景。很显然场景一压根没有连接建立，也就没有连接断开的概念。这里产生的tcp-rst标识的数据报文可以理解成主机不可达。场景二中产生的tcp-rst标识的数据报文可以认为是连接断开所产生的。和场景四类似，都是在数据到来之前连接断开。不同的是场景二不会产生tcp-fin标识的数据报文，而场景四常常伴随tcp-fin标识的数据报文产生。无论是哪一种情况，都可以认为发送携带tcp-rst标识的数据报文的一方主动断开了连接。因为主动断开连接的一方，将不能继续发送携带tcp-push标识的数据报文。

情况较为复杂的是场景三，视主动断开连接的一方的状态而定。如果主动断开的一方还有未读取的数据在tcp缓冲区中，此时抓包将会发现连接断开过程只会出现一个携带tcp-rst标识的数据报文。在这种情况下，主动发送携带tcp-rst标识的数据报文的一方是主动断开连接。如果主动断开的一方在tcp缓冲区中没有未读取的数据，那么将会发送携带tcp-fin标识的数据报文，而接收到携带tcp-fin标识的数据报文后，也将被动关闭。这时如果tcp缓冲区中存在未读取的数据，那么被动断开的这一端将会产生携带tcp-rst标识的数据报文。

如何推断哪一方主动断开连接的呢？以上分析已经给出答案。如果断开的时候，通过tcpdump抓包发现了携带tcp-fin标识的数据报文，那么可以直接确认谁主动发送携带tcp-fin标识的数据报文，谁主动断开连接。如果没有出现携带tcp-fin标志的数据报文，那么谁主动发送携带tcp-rst标识的数据报文，谁主动断开。