
我们都知道 TCP 是全双工通信,当客户端发送 FIN 后,服务端回复 ACK 进入 CLOSE_WAIT 状态,这个时候对于客户端来说,发送功能没有了,但是还可以正常接收服务端的数据,对于服务端来说,既可以接收客户端的数据也可以给客户端发数据。当被动关闭方在 CLOSE_WAIT 状态下接收到数据时,它依然会遵循 TCP 的协议规范,对接收的数据进行确认,即向对方发送 ACK 报文。这是 TCP 协议确保数据可靠传输的基本行为,确保每一个数据包都被确认接收。所以如果服务端在 CLOSE_WAIT 状态,客户端有报文过来,服务端是能正常接收并且回复 ACK 确认的,客户端也能收到这个 ACK。
总结来说,在 CLOSE_WAIT 状态下,不仅可以接收数据,而且对接收到的数据会正常回复 ACK 报文。不过,需要注意的是,处于这个状态应当尽快完成数据处理并主动关闭连接,避免资源被长时间占用。
上面是我们的理解,我们直接拿源码证明我们的理解:在 net/ipv4/tcp_input.c 文件里有个函数:
int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
struct tcphdr *th, unsigned len)
{
// ...
/* step 7: process the segment text */
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_CLOSE_WAIT 最终还是落入了和 TCP_ESTABLISHED 一样的处理流程:tcp_data_queue(sk, skb)。所以源码证明我们上面的理解没有问题。