[历史归档]本文原发布于 cstriker1407.info 个人博客内容为历史存档仅供参考。发布时间2018-03-02 标题几种TCP连接中出现RST的情况分类编程 标签TCPUDPTCP Reset简单笔记参考链接《 https://blog.csdn.net/hzw05103020/article/details/50806759 》在TCP协议中RST表示复位用来异常的关闭连接在TCP的设计中它是不可或缺的。发送RST包关闭连接时不必等缓冲区的包都发出去直接就丢弃缓存区的包发送RST包。而接收端收到RST包后也不必发送ACK包来确认。其实在网络编程过程中各种RST错误其实是比较难排查和找到原因的。下面我列出几种会出现RST的情况。1 端口未打开服务器程序端口未打开而客户端来连接。这种情况是最为常见和好理解的一种了。去telnet一个未打开的TCP的端口可能会出现这种错误。这个和操作系统的实现有关。在某些情况下操作系统也会完全不理会这些发到未打开端口请求。比如在下面这种情况下主机241向主机114发送一个SYN请求表示想要连接主机114的40000端口但是主机114上根本没有打开40000这个端口于是就向主机241发送了一个RST。这种情况很常见。特别是服务器程序core dump之后重启之前连续出现RST的情况会经常发生。当然在某些操作系统的主机上未必是这样的表现。比如向一台WINDOWS7的主机发送一个连接不存在的端口的请求这台主机就不会回应。2 请求超时曾经遇到过这样一个情况:一个客户端连接服务器connect返回-1并且errorEINPROGRESS。 直接telnet发现网络连接没有问题。ping没有出现丢包。用抓包工具查看客户端是在收到服务器发出的SYN之后就莫名其妙的发送了RST。比如有89、27两台主机。主机89向主机27发送了一个SYN表示希望连接8888端口主机27回应了主机89一个SYN表示可以连接。但是主机89却很不友好莫名其妙的发送了一个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。比如打开一个socket然后连接一个服务器并发送5000个字节。但是服务器每次只接收4096个字节那么就是说客户端发送的剩下的4个字节服务端的应用程序没有接收到服务器端的socket就被关闭掉。4 在一个已关闭的socket上收到数据如果某个socket已经关闭但依然收到数据也会产生RST。客户端在服务端已经关闭掉socket之后仍然在发送数据。这时服务端会产生RST。总结总结本文讲了几种TCP连接中出现RST的情况。实际上肯定还有无数种的RST发生我以后会慢慢收集把更多的例子加入这篇文章。参考文献1 从TCP协议的原理来谈谈RST攻击 http://russelltao.iteye.com/blog/14053492 TCP客户-服务器程序例子http://blog.csdn.net/youkuxiaobin/article/details/6917880