您的位置:首页 > 理论基础 > 计算机网络

tcp连接中分组丢失情况分析

2016-03-16 19:36 477 查看
简单分析一下tcp连接过程中分组丢失情况下,服务端与客户端的反应,如有不足或错误之处,希望各位道友指导!

先上个图对照着看



注:分析分组丢失指一直丢失

三路握手:

客户端第一次发送SYN包丢失,因为得不到ACK相应,故客户端间隔一段时间继续发送几次,而后继续失败,然后关闭套接字,客户端connect()返回ETIMEDOUT错误
服务端发送的SYN+ACK包丢失,对客户端而言,也是未接收到ACK,客户端如1一般的反应。而对于服务端而言,服务端发送了SYN+ACK而得不到客户端的ACK响应,故亦间隔一段时间后继续发送几次,得不到相应后,服务端关闭相应的连接并发送RST,若此RST客户端能够接收到,客服端的connect()返回ECONNREFUSED.
客户端发送的ACK包丢失,对于客户端而言,它认为自己己建立连接并且connect()返回,而对于服务端,它未接收到ACK相应包,故间隔一段时间后继续发送SYN+ACK包,结果还是未收到ACK相应包,故关闭相应的连接并发送RST。
连接建立后:

           客户端发送数据包,发送数据包丢失或ACK包确认丢失,则根据RTO时间重传,而数据包一直丢失,故发送缓冲区填满超时从传的数据,客户端将发送超时,而后取消发送,

           若是客户端接收数据时,数据包丢失,则一直阻塞

四路挥手断开连接:

客户端发送的FIN包丢失,客户端一直得不到ACK回应,故隔一段时间继续重传,而后失败,最后只能发送RST报给服务端,客户端关闭套接字
服务端发送ACK包丢失,对客户端而样,如1一般,继续失败重传发送RST后关闭套接字。而服务端对ACK包并不要求确认,所以发送一次后就不关心客户端是否接收到。
服务端发送FIN包丢失,服务端未接收到相应的ACK包,故隔一段时间后重传,结果仍未收到ACK包,故最后发送RST并关闭套机字。此时客户端处于FIN_WAIT2状态,而一直等待。
客户端发送ACK包丢失,服务端如3重传失败关套接字,客户端发送完ACK后并不关心服务端是否能收到,客户端此时是处于TIME_WAIT状态,2MSL后客户端套接字关闭。
至此,分析完毕,当然以上的情况是在默认的情况下发生的,若是设置了套接字选项就得另当别论了。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  tcp linux