这篇文章是对 《TCP连接的终止----主动关闭》的补充，重点关注的是被动关闭连接一端的状态迁移及内核中的 处理，被动连接的状态迁移可以参见 《TCP连接的终止----主动关闭》中的状态迁移图，这里就不再画了。
被动连接的关闭是从接收到FIN开始的，如果TCP是处于ESTABLISHED状态（我们的讨论假设连接处于此状态），这个FIN包会在tcp_rcv_established()中处理。在tcp_rcv_state_process()中的处理分为快速路径和慢速路径。如果TCP首部中第4个32位字除去保留的bit位和预测标志一致，skb包的序列号和sock结构下一个要接收到序号相等，并且skb包中的确认序列号是有效的，此时skb包会在快速路径中处理。判断时sock实例的预测标志的位图分布通常如下图所示：
其中S对应于TCP首部（struct tcphdr）中的doff成员（tcp首部的长度，以4字节为单位），？通常为0，为1的bit位对应的是ACK标志，snd_wnd则是本端发送窗口的大小。
从上面的预测标志的分布来看，如果设置了FIN标志的话，则检查预测标志时失败，所以会在慢速路径中处理FIN包。
在慢速路径处理中，会首先检查skb包的校验和及包是否是有效的，检查通过后会调用tcp_ack()处理ack的情况，接下来的处理中真正和FIN相关的操作是在调用的tcp_data_queue()中处理的，这个处理是通过调用tcp_fin()函数来处理的，从最初的TCP层接收函数tcp_v4_rcv()到tcp_fin()的处理的代码流程图如下所示：
tcp_fin()中首先调用inet_csk_schedule_ack()设置相关成员，表明需要发送ACK；因为接收了对端发送的FIN包，表明对端已经不会再发送数据包（可以发送ACK），因此关闭接收通道；还要修改sock结构的标志，表示连接将要结束；然后根据sock实例的状态会跳转到不同的分支进行处理，如果是ESTABLISHED状态下，内核会调用tcp_set_state()修改sock实例的状态，并且设置延迟发送ACK的标志，如下所示：
static void tcp_fin(struct sk_buff *skb, struct sock *sk, struct tcphdr *th)
{
struct tcp_sock *tp = tcp_sk(sk);
inet_csk_schedule_ack(sk);
sk->sk_shutdown |= RCV_SHUTDOWN;
sock_set_flag(sk, SOCK_DONE);
switch (sk->sk_state) {
case TCP_SYN_RECV:
case TCP_ESTABLISHED:
/* Move to CLOSE_WAIT */
tcp_set_state(sk, TCP_CLOSE_WAIT);
inet_csk(sk)->icsk_ack.pingpong = 1;
break;
......
}
}
tcp_fin()后面的清理乱序队列、状态更改时可能要唤醒相关进程这些操作不是我们关心的，就不作过多说明了。
在tcp_fin()中虽然设置了发送ACK的相关标志，但是要有一个引发ACK发送的操作，或者是给内核发送ACK的一个提示。这个操作是在上层函数tcp_rcv_established()函数中进行的，通过间接调用__tcp_ack_snd_check()中完成。__tcp_ack_snd_check()中会判断当前发送ACK是要立即发送还是延迟发送，如果立即发送则调用tcp_send_ack()来发送ACK，否则调用tcp_send_delayed_ack()延迟发送,代码如下所示：
static void __tcp_ack_snd_check(struct sock *sk, int ofo_possible)
{
struct tcp_sock *tp = tcp_sk(sk);
/* More than one full frame received... */
if (((tp->rcv_nxt - tp->rcv_wup) > inet_csk(sk)->icsk_ack.rcv_mss
/* ... and right edge of window advances far enough.
* (tcp_recvmsg() will send ACK otherwise). Or...
*/
&& __tcp_select_window(sk) >= tp->rcv_wnd) ||
/* We ACK each frame or... */
tcp_in_quickack_mode(sk) ||
/* We have out of order data. */
(ofo_possible && skb_peek(&tp->out_of_order_queue))) {
/* Then ack it now */
tcp_send_ack(sk);
} else {
/* Else, send delayed ack. */
tcp_send_delayed_ack(sk);
}
}
判断的条件是这样的，只要满足以下条件就会立即发送ACK：
1、接收窗口中有多个全尺寸段还未确认
2、当前处于快速确认模式下
3、在启用判断乱序队列的情况下，乱序队列中存在段
这三个条件中，我们可以确定的是第2个条件，我们首先来看判断是否处于快速确认模式的函数tcp_in_quickack_mod()函数的实现，如下所示：
static inline int tcp_in_quickack_mode(const struct sock *sk)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
return icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong;
}
在tcp_fin()中如果是ESTABLISHED状态下接收到FIN，会设置pingpong的值为1，所以可以肯定此时不处于快速确认模式下，至于是否要立即发送ACK取决于另外两个判断条件了。
我们接下来的讨论是在从对接收到的FIN确认后开始的。这时TCP连接的关闭已经进行一半了，接下来就是等待本端的上层应用调用close()来执行本端的关闭连接操作，这个操作我们在 《TCP连接的终止----主动关闭》中讲到过，是由tcp_close()来完成的。所以我们还是来看tcp_close()，只是这次sock实例的状态不一样，这时的状态应该为CLOSE_WAIT。
在tcp_close()中我们这次只关注一些和状态相关的一些处理，其他的队列清理、内存回收等就不再介绍了，所以我们只关注下面这部分代码：
void tcp_close(struct sock *sk, long timeout)
{
struct sk_buff *skb;
int data_was_unread = 0;
int state;
......
if (data_was_unread) {
......
} else if (sock_flag(sk, SOCK_LINGER) && !sk->sk_lingertime) {
......
} else if (tcp_close_state(sk)) {
tcp_send_fin(sk);
}
......
}
在tcp_close_state()中sock实例的状态会由CLOSE_WAIT迁移到LAST_ACK状态，返回值为TCP_ACTION_FIN，表示要发送FIN。因此，在第三个if判断中条件为true，所以会调用tcp_send_fin()给对端发送FIN。
当本端接收到TCP连接关闭的最后一个ACK时，由tcp_rcv_state_process()函数来处理，相关的代码如下所示：
int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
struct tcphdr *th, unsigned len)
{
struct tcp_sock *tp = tcp_sk(sk);
struct inet_connection_sock *icsk = inet_csk(sk);
int queued = 0;
int res;
......
/* step 5: check the ACK field */
if (th->ack) {
int acceptable = tcp_ack(sk, skb, FLAG_SLOWPATH) > 0;
switch (sk->sk_state) {
......
case TCP_LAST_ACK:
if (tp->snd_una == tp->write_seq) {
tcp_update_metrics(sk);
tcp_done(sk);
goto discard;
}
break;
}
} else
goto discard;
......
switch (sk->sk_state) {
case TCP_CLOSE_WAIT:
case TCP_CLOSING:
case TCP_LAST_ACK:
if (!before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt))
break;
case TCP_FIN_WAIT1:
case TCP_FIN_WAIT2:
/* RFC 793 says to queue data in these states,
* RFC 1122 says we MUST send a reset.
* BSD 4.4 also does reset.
*/
if (sk->sk_shutdown & RCV_SHUTDOWN) {
if (TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(skb)->seq &&
after(TCP_SKB_CB(skb)->end_seq - th->fin, tp->rcv_nxt)) {
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPABORTONDATA);
tcp_reset(sk);
return 1;
}
}
/* Fall through */
case TCP_ESTABLISHED:
tcp_data_queue(sk, skb);
queued = 1;
break;
}
/* tcp_data could move socket to TIME-WAIT */
if (sk->sk_state != TCP_CLOSE) {
tcp_data_snd_check(sk);
tcp_ack_snd_check(sk);
}
if (!queued) {
discard:
__kfree_skb(skb);
}
return 0;
}
如果刚好是期望的ACK包，则会在第19-23行代码中处理，调用tcp_done()将套接字状态设置为TCP_CLOSE，并且调用inet_csk_destroy_sock()释放sock实例占用的资源，并且调用sock_put()释放传输控制块（真正的调用sk_free()一般情况下不会是这里，但是这里较少引用计数后，上层再调用sock_put()时就会触发sk_free()操作）。我们知道在主动关闭一端正常情况下会通过定时器来释放描述TIME_WAIT状态的sock结构或者放在twcal_row队列中等待释放，这些释放方式比较明显。还有一个种就是这里看到的通过inet_csk_destroy_sock()来间接完成释放。
有时也可能接收到其他包，如果是包含数据的包，在44-51的处理中会发送RST给对端，如果只是单纯的ACK包，但是确认的序列号不对，则会在tcp_data_queue()中释放掉。
至此，TCP连接被动关闭一方的处理完成了。