3次握手4次挥手面试怎么回答(三次挥手四次握手过程)

三次握手和四次挥手面试题怎么回答

三次握手和四次挥手面试题这样回答

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

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

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

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

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

这里我顺便解释一下为啥只有三次握手才能确认双方的接受与发送能力是否正常，而两次却不可以：

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

三次握手和四次挥手

三次握手的流程图：

在网络数据传输中，传输层协议TCP(传输控制协议)是建立连接的可靠传输，TCP建立连接的过程，我们称为三次握手。

第一次，客户端向服务器发送SYN同步报文段，请求建立连接

客户端发送网络包，服务端收到了。

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

第二次，服务器确认收到客户端的连接请求，并向客户端发送SYN同步报文，表示要向客户端建立连接

服务端发包，客户端收到了。

这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次，客户端收到服务器端的确认请求后，处于建立连接状态，向服务器发送确认报文

客户端发包，服务端收到了。

这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

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

无法确认客户端的接收能力。

假设第二次握手的报文丢失了，或者是说有人恶意向服务器不断发送SYN同步报文（SYN洪水）。那么服务器端就会有大量的无效连接，服务器处理连接的数量是有限的，当有大量的无效连接建立后，服务器处理有效连接是能力就会受限，且建立连接会消耗大量是资源，至此有可能导致服务器崩溃。

因为三次已经足够确认双方的发送和接收的能力了，四次以及四次以上当然就没必要啦

可以，但是只有第三次，此时的established状态相对安全并且够确认服务器的接收发送能力。但是，第一次、第二次握手不可以携带数据

为什么这样呢?大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

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

当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

SYN Flood 属于典型的 DoS/DDoS 攻击。其攻击的原理很简单，就是用客户端在短时间内伪造大量不存在的 IP地址，并向服务端疯狂发送SYN。对于服务端而言，会产生两个危险的后果:

处理大量的SYN包并返回对应ACK, 势必有大量连接处于SYN_RCVD状态，从而占满整个半连接队列，无法处理正常的请求。

由于是不存在的 IP，服务端长时间收不到客户端的ACK，会导致服务端不断重发数据，直到耗尽服务端的资源。

增加 SYN 连接，也就是增加半连接队列的容量。

减少 SYN + ACK 重试次数，避免大量的超时重发。

利用 SYN Cookie技术，在服务端接收到SYN后不立即分配连接资源，而是根据这个SYN计算出一个Cookie，连同第二次握手回复给客户端，在客户端回复ACK的时候带上这个Cookie值，服务端验证Cookie 合法之后才分配连接资源。

下面来看看四次挥手的流程图：

中断连接端可以是客户端，也可以是服务器端。

不像建立连接的过程,服务器端在调用了accept()之后,剩下的都交给内核来处理,用户空间不用做什么,断开连接是,A端调用close()关闭文件描述符后,A端就停止发送数据了进行发送,B端收到后结束报文段之后,的得知A端要断开连接了,但是B端可能有自己还没有处理完的数据,不能立即断开连接,就要先给出回复,表示自己已经收到消息了,然后将自己的数据处理完之后,可以断开连接的时候,再调用close()发出断开连接请求,在收到A端的确认回复之后,断开连接,一共需要四次挥手。

MSL是 最长报文段寿命，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

2MSL等待状态：它是任何报文段被丢弃前在网络内的最长时间。

（1）保证客户端发送的最后一个ACK报文段能够到达服务端。

（2）防止“已失效的连接请求报文段”出现在本连接中。

客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况，

具体流程如下图：

参考资料：

一篇文章带你熟悉 TCP/IP 协议

「计算机网络」前端必备知识，看到就是赚到系列（上）

什么是三次握手、四次挥手

面试官，不要再问我三次握手和四次挥手

三次握手四次挥手通俗解释

一、三次握手

目的是确保通信双发具有收发数据的能力

现在假如客户端A向服务端B发送建立连接的请求，如果B收到了，那么对于B来说，就会知道A发送数据的能力是没有问题的，同时也知道自己接受数据的能力是没有问题的。

此时B会给A发送一个响应请求，如果A收到了，那么对于A来说，就会知道B发送数据的能力是没有问题的，同时也会知道B接受数据的能力是没有问题的，因为A知道只有自己发送建立连接的请求被B接受， B才会响应的。

到这为止，我们已经经过两次握手了！！！。总结一下，这个时候A知道B发送和接受数据的能力，B只知道A发送数据的能力。因此我们还需证明A接受数据的能力才行！！！。所以还需要经过第三次握手。

A发送确认建立连接的请求，如果B收到了，那么说明A接受数据的能力是没有问题的，因为B知道，只有A在收到B的响应请求后才会发送确认建立连接的请求。这个时候，双方都证明了对方收发数据的能力是没有问题的。

二、四次挥手

目的是断开连接

举个例子，客户端A（女生）、服务端B(男生)

A：分手（发出取消连接的请求）

B：哦，我知道了（收到了A的请求，这个时候B会在后台处理数据，处理完数据后会再次发送响应信息，询问是否真的要取消）

B:? 真的要分手吗（再次发送响应信息）

A:? 嗯，拉倒吧！

经过这四次，A和B彻底的分手了，也就是彻底的断开连接了

三次握手、四次挥手及相对应面试题

第一次，客户端CLOSE状态，服务端LISTEN状态。客户端向服务端发送SYN（同步序列编号）报文，客户端变成SYN_SEND

第二次，服务端收到SYN之后，以自己的SYN应答，指定初始序列号ISN，ACK= SYN+1，发送ACK，服务器SYN_REVD状态

第三次，客户端收到SYN，发送ACK，再把服务端的ACK = ISN + 1 表示已经收到报文发送给服务端，两端状态都变为ESTABLISHED

??????很多人可能会认为三次握手都不能携带数据，其实第三次握手的时候，是可以携带数据的。也就是说，第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。

为什么这样呢？大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。也就是说，第一次握手可以放数据的话，其中一个简单的原因就是会让服务器更加容易受到攻击了。

而对于第三次的话，此时客户端已经处于 established 状态，也就是说，对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据页没啥毛病。

两次的话，会出现这种情况，A发出的第一次连接请求报文段没有丢失，而是在某些网络节点长时间滞留，本来是早已失效的报文段，但B收到后误以为A发送的一次新的请求，如果是三次握手则会向A确认报文段，同意建立连接，两次握手则直接建立连接，这样就会导致新的连接建立，B的许多资源白白浪费。

1. 第一次挥手：客户端发送一个 FIN 报文段，FIN报文段表示断开连接的意思，报文中会指定一个序列号K。此时客户端处于?FIN_WAIT1?状态

2. 服务端将序列号K值加1作为ACK确认号返回值，表明接受到客户端报文。这时上层的应用程序会被告知另一端发起了关闭操作，上层进行关闭操作。此时服务端处于?CLOSE_WAIT?状态。客户端进入FIN_WAIT2（终止等待2）状态

3. 服务端发起自己的FIN报文段，ACK=K+1, Seq=L,seq是序号，此时服务端处于?LAST_ACK?的状态。

4. 客户端返回确认号ACK=L+1给服务端,客户端处于?CLOSED?状态，TCP连接断开。

因为服务端收到FIN，发送ACK只是应答，并不代表服务端希望关闭连接。

当服务端把所有报文都发送完了，才发送FIN，告诉客户端可以关闭连接了。

PHP面试题：什么是TCP“3次握手，4次挥手”

TCP是一种面向连接的单播协议，在发送数据前，通信双方必须在彼此间建立一条连接。所谓的“连接”，其实是客户端和服务器的内存里保存的一份关于对方的信息，如ip地址、端口号等。

TCP可以看成是一种字节流，它会处理IP层或以下的层的丢包、重复以及错误问题。在连接的建立过程中，双方需要交换一些连接的参数。这些参数可以放在TCP头部。

TCP提供了一种可靠、面向连接、字节流、传输层的服务，采用三次握手建立一个连接。采用4次挥手来关闭一个连接。

对于一个已经建立的连接，TCP使用改进的四次握手来释放连接（使用一个带有FIN附加标记的报文段）。TCP关闭连接的步骤如下：