【面试高频】TCP三次握手、四次挥手【为什么建立连接协议是三次握手,而关闭连接却是四次握手?/为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?/如果已经建立连接,但是客户端】

三次握手

【面试高频】TCP三次握手、四次挥手【为什么建立连接协议是三次握手,而关闭连接却是四次握手?/为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?/如果已经建立连接,但是客户端】_第1张图片

第一次握手:在建立连接时,客户端发送SYN包(SYN=1)到服务器,
			并进入了SYN_SENT状态,等待服务端的确认;

第二次握手:服务端接收到SYN包后,必须确认客户端的SYN,
			同时自己也发送一个SYN包,即SYN+ACK包,此时服务端进入了SYN_RCVD状态;

第三次握手:客户端收到服务端的SYN+ACK包,向服务端发送一个确认包ACK,
			此包发送完毕后,客户端和服务端就进入了ESTABLISHDE状态,完成三次握手。

第一步:客户机的TCP首先向服务器的TCP发送一个连接请求报文段。这个特殊的报文段中不含应用层数据,其首部中的SYN标志位被置为1。另外,客户机会随机选择一个起始序列号 seq = x(连接请求报文不携带数据,但要消耗掉一个序号)。

第二步:服务器的TCP收到连接请求报文段后,如同意建立连接,就向客户机发回确认,并未该TCP连接分配TCP缓存和变量。在确认报文段中,SYN和ACK位都被置为1,确认号字段的值为x+1,并且服务器随机产生起始序列号 seq = y(确认报文不携带数据,但也要消耗掉一个序号)。确认报文段同样不包含应用层数据。

第三步:当客户机收到确认报文段后,还要向服务器给出确认,并且也要给该连接分配缓存和变量。这个报文段的ACK标志位被置为1,序号字段为 x+1,确认号字段 ack = y+1。该报文段可以携带数据,如果不携带数据则不消耗序号。

四次挥手

【面试高频】TCP三次握手、四次挥手【为什么建立连接协议是三次握手,而关闭连接却是四次握手?/为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?/如果已经建立连接,但是客户端】_第2张图片
第一步:客户机打算关闭连接,就向其TCP发送一个连接释放报文段,并停止再发送数据,主动关闭TCP连接,该报文段的FIN标志位被置为1,seq = u,它等于前面已传送过的数据的最后一个自己的序号加1(FIN报文段即使不携带数据,也要消耗一个序号)。TCP是全双工的,即可以想象成是一条TCP连接上有两条数据通路。当发送FIN报文时,发送FIN报文的一段就不能再发送数据,也就是关闭了其中一条数据通路,但对方还可以发送数据。

第二步:服务器收到连接释放报文段后即发出确认,确认号是ack = u+1,而这个报文段自己的序号是v,等于它们前面已传送过的数据的最后一个字节的序号加1。此时,从客户机到服务器这个方向的连接就释放了,TCP连接处于半关闭状态。但服务器若发送数据,客户机仍要接收,即从服务器到客户机这个方向的连接并未关闭。

第三步:若服务器已经没有要向客户机发送的数据,就通知TCP释放连接,此时其发出FIN=1的连接释放报文段。

第四步:客户机收到连接释放报文段后,必须发出确认。在确认报文段中,ACK字段被置为1,确认号ack = w+1,序号seq = u+1。此时TCP连接还没有释放掉,必须经过时间等待计时器设置的时间2MSL后,A才进入到连接关闭状态。


面试高频问题:

1.为什么建立连接协议是三次握手,而关闭连接却是四次握手呢?

这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后,它可以把ACK和SYN(ACK起应答作用,而SYN起同步作用)放在一个报文里来发送。但关闭连接时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送给你了;但未必你所有的数据都全部发送给对方了,所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的.

2.为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?

这是因为虽然双方都同意关闭连接了,而且握手的4个报文也都协调和发送完毕,按理可以直接回到CLOSED状态(就好比从SYN_SEND状态到ESTABLISH状态那样);但是因为我们必须要假想网络是不可靠的,你无法保证你最后发送的ACK报文会一定被对方收到,因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文,而重发FIN报文,所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

3.如果已经建立连接,但是客户端突然出现了故障会怎么办?

TCP还设有一个保活机制。显然,如果客户端出现了故障,服务端不能一直等下去。若等了一段时间还没有收到客户端的任何数据,服务端就会发送一个探测报文段,若一连发送10个探测报文段仍然没有反应,服务端就认为是客户端出现了故障,就会关闭连接。

4.TCP的三次握手过程?为什么会采用三次握手,若采用二次握手可以吗?

建立连接的过程是利用客户服务器模式,假设主机A为客户端,主机B为服务器端。

(1)TCP的三次握手过程:主机A向B发送连接请求;主机B对收到的主机A的报文段进行确认;主机A再次对主机B的确认进行确认。

(2)采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B,因而产生错误。失效的连接请求报文段是指:主机A发出的连接请求没有收到主机B的确认,于是经过一段时间后,主机A又重新向主机B发送连接请求,且建立成功,顺序完成数据传输。考虑这样一种特殊情况,主机A第一次发送的连接请求并没有丢失,而是因为网络节点导致延迟达到主机B,主机B以为是主机A又发起的新连接,于是主机B同意连接,并向主机A发回确认,但是此时主机A根本不会理会,主机B就一直在等待主机A发送数据,导致主机B的资源浪费。

5.tcp的保活计时器

除时间等待计时器外,TCP还设有一个保活计时器 keepalive timer))设想有这样的情况:
客户已主动与服务器建立了TCP连接。但后来客户端的主机突然出故障。显然,服务 器以后就不能再收到客户发来的数据。因此,应当有措施使服务器不要再白白等待下去,这 就是使用保活计时器。服务器每收到一次客户的数据,就重新设置保活计时器,时间的设置 通常是两小时。若两小时没有收到客户的数据,服务器就发送一个探测报文段,以后则每隔 75秒钟发送一次。若一连发送10个探测报文段后仍无客户的响应,服务器就认为客户端出 了故障,接着就关闭这个连接 .

6.为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?

这是因为虽然双方都同意关闭连接了,而且握手的4个报文也都协调和发送完毕,按理可以直接回到CLOSED状态(就好比从SYN_SEND状态到ESTABLISH状态那样);但是因为我们必须要假想网络是不可靠的,你无法保证你最后发送的ACK报文会一定被对方收到,因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文,而重发FIN报文,所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。


文章持续更新:欢迎各位小伙伴关注我的公众号:菜丸的程序屋。希望将我的不足之处给予指点,谢谢大家。喜欢Java,热衷学习的小伙伴可以加我微信: CaiWan_Y
【面试高频】TCP三次握手、四次挥手【为什么建立连接协议是三次握手,而关闭连接却是四次握手?/为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?/如果已经建立连接,但是客户端】_第3张图片

【面试高频】TCP三次握手、四次挥手【为什么建立连接协议是三次握手,而关闭连接却是四次握手?/为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?/如果已经建立连接,但是客户端】_第4张图片

你可能感兴趣的:(java,面试,java,分布式,http,网络)