Linux 主动关闭服务器套接字

我有一个小型服务器（TCP服务器），在端口5000上最多接受10个连接。我已经在侦听模式下创建了一个套接字并接受连接。当accept成功时，我创建一个新线程并处理该线程中的流量。我在同一台机器上有一个客户机，它能够连接并与此服务器通信

现在为了理解等待的时间，我使用ctrl+c终止了我的服务器应用程序。我希望看到处于“已建立”状态的服务器套接字被传输到“TIME\u WAIT”。但是，当我在关闭后执行netstat时，我没有看到一个套接字处于“TIME\u WAIT”状态。我知道处于“侦听”模式的套接字直接转换为关闭状态。但我不明白为什么由accept返回的、当前处于已建立状态的套接字不处于TIME\u WAIT状态

（我在linux机器上，tcp_fin_超时值设置为1min。）

我的tcpdump如下所示：

localhost.49388 > localhost.5000:
    Flags [S], cksum 0xfe30 (incorrect -> 0xaa93), seq 3264533269, win 32792,
    options [mss 16396,sackOK,TS val 20216234 ecr 0,nop,wscale 3], length 0              
localhost.5000 > localhost.49388:
    Flags [S.], cksum 0xfe30 (incorrect -> 0xc6a0), seq 3352338762, ack 3264533270, win 32768,
    options [mss 16396,sackOK,TS val 20216234 ecr 20216234,nop,wscale 3], length 0
localhost.49388 > localhost.5000:
    Flags [.], cksum 0xfe28 (incorrect -> 0x9fbe), ack 1, win 4099,
    options [nop,nop,TS val 20216234 ecr 20216234], length 0           
localhost.5000 > localhost.49388:
    Flags [P.], cksum 0xfe42 (incorrect -> 0xa300), seq 1:27, ack 1, win 4096,
    options [nop,nop,TS val 20216484 ecr 20216234], length 26           
localhost.49388 > localhost.5000:
    Flags [.], cksum 0xfe28 (incorrect -> 0x9db0), ack 27, win 4099,
    options [nop,nop,TS val 20216484 ecr 20216484], length 0          
localhost.49388 > localhost.5000:
    Flags [P.], cksum 0x0211 (incorrect -> 0x6be1), seq 1:1001, ack 27, win 4099,
    options [nop,nop,TS val 20216484 ecr 20216484], length 1000              
localhost.5000 > localhost.49388:
    Flags [.], cksum 0xfe28 (incorrect -> 0x91cb), ack 1001, win 6144,
    options [nop,nop,TS val 20216484 ecr 20216484], length 0     
localhost.5000 > localhost.49388:
    Flags [R.], cksum 0xfe28 (incorrect -> 0x8eeb), seq 27, ack 1001, win 6144,
    options [nop,nop,TS val 20217216 ecr 20216484], length 0

---

*但我不明白为什么由accept返回的、当前处于已建立状态的套接字不处于TIME\u WAIT状态*

因为你终止了进程，阻止了任何有序的关闭。只有当进程在套接字上实际调用

close（）

（或

shutdown（）

）时，您才会看到

TIME\u WAIT

，该套接字将向对等方发送

FIN

，然后保持活动足够长的时间，以接收发送给对等方的

FIN

的

ACK

，以及对等方自己的

FIN

（将返回一个

ACK

）。有三种方法可以到达

TIME\u WAIT

，其中一种方法必须在

TIME\u WAIT

建立之前发生，但只有在流程仍然处于活动状态时才能发生，该流程才能过渡到FIN\u WAIT1，这是所有三条路径的开始。您的Ctrl-C甚至阻止了

close（）

启动序列

---

要查看

TIME\u WAIT

，您必须安排您的进程主动关闭套接字，例如，在为

SIGHUP

安装的处理程序中，或通过某些输入机制。在任何时候终止进程都是确保看不到您想要的内容的好方法。

您在其他计算机上的客户端上尝试过吗？没有。为什么这是不同的吗？我在两台机器之间进行了尝试，并尝试了相同的过程。现在我可以及时看到服务器套接字。为什么会有这种差异？除非您运行的是某个被黑客攻击的内核，否则不会有任何差异。如何运行

netstat

？这根本不是真的。TCP连接中断发生在内核中，而不是在userland中。O当然。如果你杀死一个进程，而不是让它以有序的方式退出，那么从另一端发送的任何东西都会得到一个RST发回。拉出

tcpdump

并跟踪一个连接，

^C

连接的一端。你会看到一个

FIN

被发送出去。内核网络堆栈为你做这件事（除其他事项外）@ Nikoli：是的，是真的。这就是为什么我希望看到TimeIt等待。我认为任何活动的关闭都应该在时间等待。如果一个服务器应用程序关闭，那么内核发送FIN，间接地意味着服务器套接字活跃地关闭，并且应该在时间等待中。我的理解是正确的吗？进程终止时，套接字将不会转换为FIN_WAIT1。甚至该FIN的另一侧的ACK也将产生RST！转换为FIN_WAIT1需要应用程序级别的close（）/shutdown（）作为触发事件。如果信号处理程序捕捉到SIGINT并调用exit（），这也足够了。但通过未捕获信号终止进程则不行。