TCP/IP详解--接收RST回应的几种情况:
1、端口未打开
服务器程序端口未打开而客户端来连接。这种情况是最为常见和好理解的一种了。去telnet一个未打开的TCP的端口可能会出现这种错误。这个和操作系统的实现有关。在某些情况下,操作系统也会完全不理会这些发到未打开端口请求。
2、请求超时
曾经遇到过这样一个情况:一个客户端连接服务器,connect返回-1并且error=EINPROGRESS。 直接telnet发现网络连接没有问题。ping没有出现丢包。用抓包工具查看,客户端是在收到服务器发出的SYN之后就莫名其妙的发送了RST。
3、提前关闭
关于TCP,我想我们在教科书里都读到过一句话,'TCP是一种可靠的连接'。 而这可靠有这样一种含义,那就是操作系统接收到的来自TCP连接中的每一个字节,我都会让应用程序接收到。
扩展资料
TCP/IP连接三次握手
在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。
第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认; SYN:同步序列编号(Synchronize Sequence Numbers)
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。
完成三次握手,客户端与服务器开始传送数据。
我们先熟悉一下 tcp 三次握手和四次挥手:RST的标志位,这个标识为在如下几种情况下会被设置,以下是我了解的情况,可能还有更多的场景,没有验证:
1. 当尝试和未开放的服务器端口建立tcp连接时,服务器tcp将会直接向客户端发送reset报文;
2. 双方之前已经正常建立了通信通道,也可能进行过了交互,当某一方在交互的过程中发生了异常,如崩溃等,异常的一方会向对端发送reset报文,通知对方将连接关闭;
3. 当收到TCP报文,但是发现该报文不是 已建立的TCP连接列表 可处理的,则其直接向对端发送reset报文;
4. ack报文丢失,并且超出一定的重传次数或时间后,会主动向对端发送reset报文释放该TCP连接。
“ Connection reset by peer ”和“ Connection reset” 是有区别的:
服务器返回了“RST”时,如果此时 客户端 正在从Socket套接字的 输出流 中 读数据 则会提示Connection reset”;
服务器返回了“RST”时,如果此时 客户端 正在往Socket套接字的 输入流 中 写数据 则会提示“Connection reset by peer”。
“connection reset by peer”和”broken pipe”出现的场景:
1)往一个对端已经close的通道写数据的时候,对方的tcp会收到这个报文,并且反馈一个reset报文。
当收到reset报文的时候,继续做 select读数据 的时候就会抛出Connect reset by peer的异常。
2)当第一次往一个对端已经close的通道写数据的时候会和上面的情况一样,会收到reset报文。
当再次 往这个socket写数据 的时候,就会抛出Broken pipe了 。
根据tcp的约定,当收到reset包的时候,上层必须要做出处理,调用将socket文件描述符进行关闭,其实也意味着pipe会关闭,因此会抛出这个顾名思义的异常。
Orderly Versus Abortive Connection Release in Java
https://docs.oracle.com/javase/1.5.0/docs/guide/net/articles/connection_release.html
关于 Connection reset原因分析和解决方案
https://my.oschina.net/xionghui/blog/508758
从tcp原理角度理解Broken pipe和Connection Reset by Peer的区别
http://lovestblog.cn/blog/2014/05/20/tcp-broken-pipe
对TCP重传的进一步认识
http://blog.sina.com.cn/s/blog_4d276ac901011ee7.html
https://www.cnblogs.com/YXBLOGXYY/p/14243259.html
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)