TCP的三次握手和四次挥手 以及相关的问题和面试问题

面试的三次握手四次挥手应该怎么回答？

 

     1、第一次握手：客户端给服务器发送一个 SYN 报文。

     2、第二次握手：服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。

     3、第三次握手：客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。

     4、服务器收到 ACK 报文之后，三次握手建立完成。

      作用：是为了确认双方的接收与发送能力是否正常。

 

为什么是三次握手而不是两次？

 第一次握手：客户端发送网络包，服务端收到了。

服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

 第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：

服务端的接收、发送能力，客户端的接收、发送能力是正常的。

不过此时服务器并不能确认客户端的接收能力是否正常？

  第三次握手：客户端发包，服务端收到了。

这样服务端就能得出结论：

客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

 因此，需要三次握手才能确认双方的接收与发送能力是否都正常。

面试加分的描述回答三次握手的作用和过程：

 刚开始客户端处于 closed 的状态，服务端处于 listen 状态。然后

      1、第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN（c）。此时客户端处于 SYN_SenT 状态。

    SYN-SENT -在发送连接请求后等待匹配的连接请求；

      2、第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。

SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认；

      3、第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 establised 状态。

      4、服务器收到 ACK 报文之后，也处于 establised 状态，此时，双方以建立起了链接。

三次握手其他作用：

        1、确认双方的接收能力、发送能力是否正常。

      2、指定自己的初始化序列号，为后面的可靠传送做准备。

      3、如果是 https 协议，三次握手这个过程，还会进行数字证书的验证以及加密密钥的生成。

三次握手其他问题

 1、（ISN）是固定的吗？

      三次握手的一个重要功能是客户端和服务端交换ISN初始化序列号(Initial Sequence Number), 以便让对方知道接下来接收数据的时候如何按序列号组装数据。

     如果ISN是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

2、什么是半连接队列

      服务器第一次收到客户端的 SYN 之后，就会处于 （同步已接收） 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

全连接队列：

就是已经完成三次握手，建立起连接的就会放在全连接队列中。

如果队列满了就有可能会出现丢包现象。

   3、关于SYN-ACK 重传次数的问题：

服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超 过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。

注意！每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s, 2s, 4s, 8s, …

3、三次握手过程中可以携带数据吗

    第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。

原因：

第一次握手可以携带数据的话：若有人攻击服务器，就会从第一次握手的ＳＹＮ报文中投放大量数据，会使服务器花费很多时间　内存空间来接收这些报文，会使服务器更容易受到攻击

而对于第三次的话，此时客户端已经处于 established 状态，并且也已经知道服务器的接收、发送能力是正常的了，所以携带数据是可以的

四次挥手 ：

 刚开始双方都处于 establised 状态，假如是客户端先发起关闭请求，则：

（客户端是主动关闭，服务端是被动关闭）

      1、第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于

FIN_WAIT1状态。

FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；

      2、第二次握手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。

CLOSE-WAIT - 等待从本地用户发来的连接中断请求；

      3、第三次挥手：如果服务端也想断开连接，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；

      4、第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态

TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认；

      5、服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

 

   TIME_WAIT状态：

为什么客户端发送 ACK 之后不直接关闭，而是要等一阵子才关闭。这其中的原因就是：

要确保服务器是否已经收到了我们的 ACK 报文，如果没有收到的话，服务器会重新发 FIN 报文给客户端，客户端再次收到 ACK 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文。

      至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时，如果过了这个计时没有再次收到 FIN 报文，则代表对方成功就是 ACK 报文，此时处于 CLOSED 状态。

LISTEN - 听来自远方TCP端口的连接请求；

ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；

FIN-WAIT-2 - 从远程TCP等待连接中断请求；

CLOSING -等待远程TCP对连接中断的确认；

CLOSED - 没有任何连接状态；

　

三次握手：

三次握手能建立一个安全可靠的连接，由客户端发起向服务端发一个SYN =1发起一个新的连接，服务端向客户端发起一个确认ACK=1 ack=seq+1  ，两次握手之后客户端已经知道了但服务端不知道客户端是否收到还要确认一次，ACK=1 ack=seq+1给服务端一个回应，客户端可以是收到服务端也可以发送给服务端

四次挥手：

四次挥手：客户端发送到服务端FIN=1  seq随机、客户端想要和服务端断开连接但服务端，还没有准备好先发送给客户端说我先准备一下，可以断开的时候我回应你、发送确认后，等会发一个断开连接FIN=1 由服务端再发给客户端，客户端在回应服务端消息确认，就真的断开连接。

＊常见面试题：

【问题1】为什么连接的时候是三次握手，关闭的时候却是四次挥手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文。

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然四个报文都发送完毕，可以直接进入CLOSE状态了，但是，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

【问题3】为什么不能用两次握手进行连接？

答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

       现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP靠解决什么问题保证可靠传输：

• 乱序

• 丢包

• 流控

• 拥塞控制

目录

面试的三次握手四次挥手应该怎么回答？

为什么是三次握手而不是两次？

面试加分的描述回答三次握手的作用和过程：

三次握手其他作用：

三次握手其他问题

四次挥手 ：

 TIME_WAIT状态：

         TCP靠解决什么问题保证可靠传输：