三次握手与四次挥手

三次握手与四次挥手

TCP报文

在这里插入图片描述

序号(seq)TCP是面向字节流的。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。seq是本报文段发送的数据组的第一个字节的序号

确认号(ack):确认序号为上次接收的序号的最后一个字节序号加1.只有确认标志位(ACK)为1的时候,确认序号才有效。

同步SYN(synchronization):在连接建立时用来同步序号。当SYN=1ACK=0时,表明这是一个连接请求报文段。对方若同意建立连接,则应在响应的报文段中使SYN=1和ACK=1。因此SYN=1就表示这是一个连接请求或连接接受报文。

终止FIN(finis,意思是“完”“终”):用来释放一个连接。当FIN=1时,表明此报文段的发送发的数据已发送完毕,并要求释放运输连接

确认ACK(acknowledgment):仅当ACK = 1时确认号字段才有效,当ACK = 0时确认号无效。TCP规定,在连接建立后所有的传送的报文段都必须把ACK置为1。

TCP/IP协议中的三次握手and四次挥手

TCP/IP即传输控制/网络协议,是面向连接的协议,发送数据前要先建立连接,TCP提供安全可靠的服务。
在这里插入图片描述

三次握手

  • TCP/IP 协议是传输层的一个面向连接安全可靠的一个传输协议,三次握手的机制是为了保证能建立一个安全可靠的连接,那么第一次握手是由客户端发起,客户端会向服务端发送一个报文,在报文里面:SYN标志位置为1,表示发起新的连接。
  • 当服务端收到这个报文之后就知道客户端要和我建立一个新的连接,于是服务端就向客户端发送一个确认消息包,在这个消息包里面:ack标志位置为1,表示确认客户端发起的第一次连接请求。
  • 以上两次握手之后,对于客户端而言:已经明确了我既能给服务端成功发消息,也能成功收到服务端的响应。但是对于服务端而言:两次握手是不够的,因为到目前为止,服务端只知道一件事,客户端发给我的消息我能收到,但是我响应给客户端的消息,客户端能不能收到我是不知道的所以,还需要进行第三次握手,第三次握手就是当客户端收到服务端发送的确认响应报文之后,还要继续去给服务端进行回应,也是一个ack标志位置1的确认消息。
  • 通过以上三次连接,不管是客户端还是服务端,都知道我既能给对方发送消息,也能收到对方的响应。那么,这个连接就被安全的建了。

四次挥手

  • 四次挥手也是客户端发起的,客户端会发送一个报文,报文FIN=1,当客户端收到这个报文之后,就知道了客户端想要和我断开连接,
  • 但是此时服务端不一定做好准备,因为当客户端发起断开连接的报文的时候,服务端有可能还有未发送完的报文消息需要继续发送,所以此时服务端只能告诉客户端我知道你要和我断开连接了,但是我这里可能还没做好准备,需要等我一下,等会我会告诉你,
  • 于是,发完这个消息确认报之后,稍过片刻之后服务端继续发送一个断开连接的报文,FIN=1,表明服务端已经做好断开连接的准备
  • 那么,当这个消息发给客户端的时候,客户端同样需要继续发送一个消息确认的报文,那么通过这四次的相互沟通和连接,我就知道了,不管是客户端还是服务端,都已经做好了断开的准备。

用现实理解三次握手的具体细节TCP的四次挥手

客户端:我数据传完了,我要下线了
服务器:知道了,我还有点数据,你等下
一段时间后
服务器:我数据发完了,你可以下线了
客户端:好的


(1)三次握手面试问题

为什么不是两次握手?
因为在这两次握手之后,对于客户端来说,发送和接收都没有问题,但是对于服务器,只知道接受没有问题,发送的消息客户端有没有收到,服务器是不知道的,因此需要第三次握手。

为什么不是四次握手?
这是两种情况,第一种是把服务器的确认ACK和连接SYN分两次发送,这种在理论上是可行的,就好比

服务器:我在
服务器:你在线吗?

但是一次性能干完的事情,非分两次,太浪费资源了,降低传输的效率
第二种情况就是客户端再次发送确认消息,也是同理,三次握手就已经保证了双方的连接是可靠的,客户端再确认也是浪费资源

第三次握手中,如果客户端的ACK未送达服务器,会怎样?

  • Server端:由于Server没有收到ACK确认,因此会每隔 3秒 重发之前的SYN+ACK(默认重发五次,之后自动关闭连接进入CLOSED状态),Client收到后会重新传ACK给Server。
  • Client端,会出现两种情况:
    1. 在Server进行超时重发的过程中,如果Client向服务器发送数据,数据头部的ACK是为1的,所以服务器收到数据之后会读取 ACK number,进入 establish 状态
    2. 在Server进入CLOSED状态之后,如果Client向服务器发送数据,服务器会以RST包应答。

如果已经建立了连接,但客户端出现了故障怎么办?

  • 服务器每收到一次客户端的请求后都会重新复位一个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段以后每隔75秒钟发送一次若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接

  • 三次握手的目的是建立可靠的通信信道,主要的目的就是双方确认自己与对方的发送与接收机能正常
  1. 第一次握手:客户什么都不能确认;服务器确认了对方发送正常
  2. 第二次握手:客户确认了:自己发送、接收正常,对方发送、接收正常;服务器确认 了:自己接收正常,对方发送正常
  3. 第三次握手:客户确认了:自己发送、接收正常,对方发送、接收正常;服务器确认 了:自己发送、接收正常,对方发送接收正常 所以三次握手就能确认双发收发功能都正常,缺一不可。

(4)四次挥手面试问题

为啥不是三次挥手?

  • 因为客户端要关闭连接的时候,无法保证服务器已经将数据发送完成,所以此时服务器只能告诉客户端我收到你的关闭请求,知道你的数据发送完成。在服务器把数据发送完成之后,告知客户端,数据发送完了,可以关闭连接。此时,客户端也要应答,同意关闭连接

如果第二次挥手时服务器的ACK没有送达客户端,会怎样?

  • 客户端没有收到ACK确认,会重新发送FIN请求。

CLOSE_WAIT状态意义是什么?(为什么不能把服务器发送的ACK和FIN合并起来,变成三次挥手)

  • 因为服务器收到客户端断开连接的请求时,可能还有一些数据没有发完,这时先回复ACK,表示接收到了断开连接的请求。等到数据发完之后再发FIN,断开服务器到客户端的数据传送,
  • close_wait:等待服务器把数据传输完毕!

2.4、状态

img

CLOSE_WAIT状态意义是什么?(为什么不能把服务器发送的ACK和FIN合并起来,变成三次挥手)

  • 因为服务器收到客户端断开连接的请求时,可能还有一些数据没有发完,这时先回复ACK,表示接收到了断开连接的请求。等到数据发完之后再发FIN,断开服务器到客户端的数据传送,
  • close_wait:等待服务器把数据传输完毕!

客户端TIME_WAIT状态的意义是什么?/2MSL的意义

  • 第四次挥手时,客户端发送给服务器的ACK有可能丢失,TIME_WAIT状态就是用来重发可能丢失的ACK报文如果Server没有收到ACK,就会重发FIN,如果Client在2*MSL的时间内收到了FIN,就会重新发送ACK并再次等待2MSL,防止Server没有收到ACK而不断重发FIN。 MSL(Maximum Segment Lifetime),指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。
  • 1MSL保证四次挥手中主动关闭 方最后的ACK报文能最终到达服务器
  • 下一个1MSL保证服务器如果没有收到ACK那么进行重传的FIN报文能够到达客户端
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值