三次握手
三次握手过程描述
第一次握手: 客户端发送syn标志位和seq num,向服务器申请建立连接,客户端状态由closed变为syn_send
第二次握手: 服务端返回 syn和ack标志位,ack num以及seq num,确认第一次握手的报文段,返回ack num=seq num(第一次握手发送的)+1,同意建立连接,服务器状态由listen变为syn_received
第三次握手: 发送确认报文段,返回ack以及ack num=seq num(第二次握手发送的)+1,客户端状态变为:established(完成连接)
最后: 服务器收到确认报文段,服务器状态由syn_received变为established(完成连接)
三次握手原因
(1) TCP连接的特性决定,一次RT(往返)完成一次TCP的动作。
即客户端一次请求携带的seq num必须得到服务端的ack num才会完成。如果没有返回确认报文段,由于重发机制,定时器经过了一次RTO,客户端就会重发报文。那为什么客户端最后一次发送之后,没有等待服务端发回ack报文段? 这是因为服务端第二次发送的报文段里 包含ack以及请求syc报文,相当于把确认报文和请求报文合并了,所以最后客户端回复一个ack报文即可。
(2) 防止失效的报文创建连接。
因为互联网链路是非常复杂的,发送的报文可能会被互联中的网络设备阻塞,经过了一段时间才到达服务器,时间大于了RTO(Retransmission TimeOut)时间,导致客户端重发syc报文(重新创建新的连接,并丢失超时的连接)。如果只有两次握手,那么服务器每接收到syc报文(包括重发的syc报文),就会创建多余的连接,造成服务器的资源浪费。如果有第三次握手,那么客户端就能够识别出服务端发出的syc和ack报文对应的请求连接在客户端是否存活,如果存活则发送第三次握手ack报文,确认建立连接。
四次挥手
四次挥手过程描述
第一次挥手: 客户端的应用说要关闭连接,给服务端发送一个含fin标志位的报文,客户端状态由established变为fin-wait-1
第二次挥手: 服务端收到客户端发来的fin报文,回复ack报文,告知服务端的应用要关闭连接,服务端状态由established变为close-wait,而客户端收到ack报文后,状态由fin-wait-1变为fin-wait-2
第三次挥手: 服务端应用说可以关闭连接了,给客户端发送fin报文,服务端状态由close-wait变为last-ack
第四次挥手: 客户端收到服务端发来的fin报文,回复ack报文,客户端状态由fin-wait-2变为time-wait,服务端收到ack报文后,直接关闭连接,状态由last-ack变为closed
客户端经过两次最大的报文存活时间后,关闭连接,状态由time-wait变为closed
四次挥手原因
(1) 假设只有二次挥手
客户端发送fin报文,服务端接收fin后,返回ack报文。客户端接收到ack报文后,断开连接。然而服务器还有没有发送完成的报文,当发送数据报文给客户端,发现客户端已经断开连接。比如说你在浏览器输入一个地址后会跟服务端建立连接,服务端会根据TCP把数据分成很多的报文段一一地发送给客户端,在没有全部发送完成之前,客户端在完成二次挥手就断开连接,服务端还没发送完的报文段就会抛客户端失去连接的异常。
(2) 假设只有三次挥手, 服务端就不能及时地关闭连接,导致连接空闲一段时间,浪费资源。
总结
具体的握手和挥手过程以及报文的内容可以通过wireshark抓包工具分析
————————————————
版权声明:本文为CSDN博主「liaokunxian」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/piexie8364/article/details/114536504