三次握手和四次挥手

三次握手
1、    客户端申请建立连接,发送自己的序号
2、    服务器接到序号之后发送确认号,并发送自己的序号
3、    客户端对服务器发送确认号


四次挥手

 

1、    客户端断开连接,发送序列号
2、    服务器确认客户端断开,发送确认号
3、    服务器断开连接,发送序列号
4、    客户端确认服务器断开,发送确认号
其中第2步和第3步,是可以在一次报文发送中完成(三次挥手),但这种情况十分少见,只有当服务器接到客户端断开连接请求的同时断开连接,此时服务器会将确认号和自己的序号同时发送


三次握手过程中的状态转换
服务器一定处于Listen状态,否则客户端发过来的连接会被拒绝。注:服务器和客户端的角色是相对的。
客户端发送第一次握手(客户端发送连接请求(SYN包)到服务器)之后由Closed状态转为SYN-SENT状态;
服务器收到第一次握手的客户端SYN包,然后发送第二次握手(服务器发送SYN+ACK(客户端SYN包的确认)包给客户端)之后服务器由Listen状态转为SYN-RCVD状态;
客户端收到第二次握手的服务器SYN+ACK包,然后发送第三次握手(客户端对“服务器的SYN+ACK包“的ACK包给给服务器)之后客户端就转为ESTABLISHED状态;
服务器收到第三次握手的客户端ACK包之后也进入了ESTABLISHED。
四次挥手过程中的状态转换

       服务器与客户端都处于ESTABLISHED状态,且有一方主动发起了关闭,另外一方会被动关闭。被动关闭的一方需要处理socket的资源回收等,被动关闭的一方需要及时关闭,所以说被动关闭的一方出现大量CLOSE_WAIT状态通常都是因为程序代码问题。

主动关闭的一方(可能是服务器也可能是客户端)的状态迁移:FIN-WAIT1->FIN-WAIT2->TIME_WAIT-CLOSED
被动关闭的一方的状态迁移:CLOSE_WAIT->LAST_ACK->CLOSED
同时关闭:双方状态一致: FIN_WAIT1->CLOSING->TIME_WAIT

假设客户端主动关闭连接,以下说明客户端和服务器如何迁移:
客户端发送第一次挥手(客户端第一个FIN包给服务器)之后由ESTABLISHED状态转为FIN_WAIT1状态;
服务器收到客户端的第一次挥手(客户端第一个FIN包给服务器)之后,发送第二次挥手(对客户端FIN的ACK确认包)给服务器,服务器进入CLOSE_WAIT状态,等待服务器自身的socket关闭等处理(等待IO,业务处理,资源回收等等);
客户端收到服务器的第二次挥手(对客户端FIN的ACK确认包),进入FIN_WAIT2状态,等待服务器关闭(服务器调用close函数发送服务器的FIN包);
服务器发送第三次挥手(在处理完自己的事情,调用close函数之后,发送服务器的FIN包),进入LAST_ACK状态;
客户端收到第三次挥手(服务器的FIN包),发送第四次挥手(客户端第二个FIN包+ACK(对服务器FIN包的确认)),客户端进入TIME_WAIT状态;
服务器收到第四次挥手(客户端第二个FIN包+ACK(对服务器FIN包的确认)),进入CLOSED状态;
客户端等待2MSL时间,进入CLOSED状态

注:FIN_WAIT2状态等待时间是有限的,系统可配:tcp_fin_timeout 这个参数可以控制改状态存活的时间
FIN_WAIT1和CLOSE_WAIT是比较危险的状态,一般服务器网络鼓掌首先要查看这俩个状态是否正常:CLOSE_WAIT在上面说过,如果服务器代码有问题(忘记close等),服务器会一直有需要的CLOSE_WAIT状态的socket,造成服务器不可连接;FIN_WAIT1会在发出来FIN而没有手到ACK会重新发送FIN,重发次数由系统参数配置:tcp_orphan_retries;如果系统负载过重,减少tcp_orphan_retries值可能有作用。

TIME_WAIT状态存在的意义:
主动执行close()的一端才有TIME_WAIT状态
1、    可靠的终止tcp连接
我们知道,TCP是比较可靠的。当TCP向另一端发送数据时,他要求对端返回一个确认(如同我们关闭时候的FIN和ACK)。如果没有收到确认,则会重发。
回忆一下我们最终的那个FIN与ACK,被动关闭方发送FIN,并等待主动关闭方返回的ACK。我们假设最终的ACK丢失,被动关闭方将需要重新发送它的最终那个FIN,主动关闭方必须维护状态信息(TIME_WAIT),以允许它重发最终的那个ACK。
如果没有了这个状态,当他第二次收到FIN时,会响应一个RST(也是一种类型的TCP分节),会被服务器解释成一个错误。
为了TCP打算执行必要的工作以彻底终止某个连接两个方向上的数据流(即全双工关闭),那么他必须要正确处理连接终止四个分节中任何一个分节丢失的情况。
2、    让迟来的tcp报文能被识别并被丢弃
首先,存在这样的情况,某个路由器崩溃或者两个路由器之间的某个链接断开时,路由协议需要花费数秒到数分钟的时间才能稳定找出另一条通路。在这段时间内,可能发生路由循环(路由器A把分组发送给B,B又发送回给A),这种情况我们称之为迷途。假设迷途的分组是一个TCP分节,在迷途期间,发送端TCP超时并重传该分组,重传分组通过某路径到达目的地,而后不久(最多MSL秒)路由循环修复,早先迷失在这个循环中的分组最终也被送到目的地。这种分组被称之为重复分组或者漫游的重复分组,TCP必须要正确处理这些重复的分组。
我们假设ip1:port1和ip2:port2 之间有一个TCP连接。我们关闭了这个链接,过一段时间后在相同IP和端口之间建立了另一个连接。TCP必须防止来自之前那个连接的老的重复分组在新连接上出现。为了做到这一点,TCP将不复用处于TIME_WAIT状态的连接。2MSL的时间足以让某个方向上的分组存活MSL秒后被丢弃,另一个方向上的应答也最多存活2MSL秒后被丢弃。
 

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值