rst是复位报文 几种TCP链接中出现rst的情况

1 端口未打 开

服务器程序端口未打开而客户端来连接。这种情况是最为常见和好理解的一种了。去 telnet 一个未打开的 TCP 的端口可能会出现这种错误。这个和操作系统的实现有关。在某些情况下，操作系统也会完全不理会这些发到未打开端口请求 。

比如在下面这种情况下，主机 241 向主机 114 发送一个 SYN 请求，表示想要连接主机 114 的 40000 端口，但是主机 114 上根本没有打开 40000 这个端口，于是就向主机 241 发送了一个 RST 。这种情况很常见。特别是服务器程序 core dump 之后重启之前连续出现 RST的情况会经常发生 。

当然在某些操作系统的主机上，未必是这样的表现。比如向一台 WINDOWS7 的主机发送一个连接不存在的端口的请求，这台主机就不会回应 。

2 请求超 时

曾经遇到过这样一个情况 : 一个客户端连接服务器， connect 返回 -1 并且 error=EINPROGRESS 。 直接 telnet 发现网络连接没有问题。 ping 没有出现丢包。用抓包工具查看，客户端是在收到服务器发出的 SYN 之后就莫名其妙的发送了 RST 。

比如像下面这样 ：

有 89 、 27 两台主机。主机 89 向主机 27 发送了一个 SYN ，表示希望连接 8888 端口，主机 27 回应了主机 89 一个 SYN 表示可以连接。但是主机 27 却很不友好，莫名其妙的发送了一个 RST 表示我不想连接你了 。

后来经过排查发现，在主机 89 上的程序在建立了 socket 之后，用 setsockopt 的 SO_RCVTIMEO 选项设置了 recv 的超时时间为100ms 。而我们看上面的抓包结果表示，从主机 89 发出 SYN 到接收 SYN 的时间多达 110ms 。（从 15:01:27.799961 到15:01:27.961886 ， 小数点之后的单位是微秒）。因此主机 89 上的程序认为接收超时，所以发送了 RST 拒绝进一步发送数据 。

3 提前关 闭

关于 TCP ，我想我们在教科书里都读到过一句话， 'TCP 是一种可靠的连接 ' 。 而这可靠有这样一种含义，那就是操作系统接收到的来自 TCP 连接中的每一个字节，我都会让应用程序接收到。如果应用程序不接收怎么办？你猜对了， RST 。

4 在一个已关闭的 socket 上收到数 据

如果某个 socket 已经关闭，但依然收到数据也会产生 RST 。