在采访中，三个握手和四个摇摆可以说是最常见的问题。我相信每个人都看过很多关于三次握手和四次摇摆的文章。今天的文章主要关注这篇文章。在采访中，我们应该掌握哪些要点，面试官更有可能提出哪些要点？我想如果你能记住并理解下面列出的一些观点，我认为它几乎是一样的。
三次握手
当面试官问你为什么需要三次握手，三次握手和三次三握手时，我想很多人会回答这个问题：
首先，很多人会先谈论握手的过程：
1.第一次握手：客户端向服务器发送SYN数据包。
2.第二次握手：收到SYN报文后，服务器将响应SYN + ACK报文。
3.第三次握手：客户端收到SYN + ACK报文后，将回复ACK报文。
4.服务器收到ACK报文后，建立三次握手。
其作用是确认双方的接收和发送能力是否正常。
在这里，我解释一下，只有三次握手可以确认双方的接受和传输能力是否正常，而不是两次：
第一次握手：客户端发送网络数据包，服务器接收它。通过这种方式，服务器可以断定客户端的发送能力和服务器的接收能力是正常的。
第二次握手：服务器发送数据包，客户端接收数据包。通过这种方式，客户端可以得出服务器的接收和发送能力以及客户端的接收和发送能力是正常的。但是，此时服务器无法确认客户端的接收能力是否正常。
第三次握手：客户端发送数据包，服务器接收数据包。通过这种方式，服务器可以断定客户端的接收和发送功能正常，服务器自己的发送和接收功能也正常。因此，需要三次握手来确认双方的接收和发送能力是否正常。
这个答案实际上是可以的，但我认为我们应该更详细地描述这个过程，因为在三次握手的过程中，双方都被许多州改变了，这些状态也是采访者可能会问的。点。所以我认为当我们回答三次握手时，我们应该详细描述细节，详细描述意味着它可以再长一点。我认为加分的描述应该是这样的：
filled一filled，客户端处于关vehicle状态，且服务器处于listen质wallpapers状态。然后
1.第一次握手：客户端向服务器发送SYN消息，并指示客户端的初始化序列号ISN（c）。此时客户端处于SYN_Send状态。
2.第二次握手：服务器收到客户端发来的SYN报文后，用自己的SYN报文进行响应，并指定自己的初始化序列号ISN。同时，使用客户端的ISN + 1。 ACK的值表示它已收到客户端的SYN，并且服务器处于SYN_REVD状态。
3.第三次握手：客户端收到SYN报文后，发送ACK报文。当然，服务器的ISN + 1用作ACK值，表示服务器已收到SYN数据包。客户处于建立状态。
4.服务器收到ACK数据包后，也处于建立状态。此时，双方建立了联系。
三次握手的作用
三次握手的作用也很多，记住几个，确保没有损失。例如：
1.确认双方的接受能力和传输能力是否正常。
2.指定您自己的初始化序列号，以准备随后的可靠传输。
3.如果是https协议，则三次握手过程也将验证数字证书并生成加密密钥。
仅这一点还不足以应对三次握手。面试官可能会问其他问题，例如：
1.（ISN）是否已修复？
三次握手的一个重要功能是客户端和服务器交换ISN（初始序列号），以便另一方知道如何在接收数据时按序列号组装数据。
如果ISN是固定的，攻击者很容易猜出后续的确认号，因此ISN是动态生成的。
2，什么是半连接队列
服务器第一次收到客户端的SYN后，它将处于SYN_RCVD状态。这时，双方还没有完全建立联系。服务器将请求连接置于队列中。我们将此队列称为半连接队列。当然，还有一个完整的连接队列，也就是说，三次握手已经完成，并且建立了连接并将其置于完整的连接队列中。如果队列已满，则可能发生丢包。这是关于SYN-ACK重传次数的问题：服务器发送SYN-ACK数据包。如果未接收到客户端确认分组，则服务器执行第一次重传并等待接收客户端确认分组之前的一段时间。二次重传，如果重传次数超过系统指定的最大重传次数，则系统从半连接队列中删除连接信息。注意，每个重传等待时间不一定相同，一般呈指数增长，例如间隔为1s，2s，4s，8s，....
3.我可以在三次握手期间携带数据吗？
很多人可能认为三次握手无法携带数据。实际上，当第三次握手完成时，它可以携带数据。也就是说，第一次和第二次握手不能携带数据，第三次握手可以携带数据。
为什么是这样？你可以想到一个问题。如果第一次握手可以携带数据，如果有人想要恶意攻击服务器，那么他每次都会在第一次握手中将大量数据放入SYN消息中，因为攻击者只是忽略了服务器的接收和发送能力是否正常，然后疯狂地关注重复出现的SYN消息，这会导致服务器花费大量的时间和内存空间来接收这些消息。换句话说，如果第一次握手可以放置数据，其中一个简单的原因是服务器将更容易受到攻击。
客户已经第三次处于既定状态。也就是说，对于客户端，他已经建立了连接，并且已经知道服务器的接收和发送能力是正常的，因此携带数据页面没有任何问题。
关于三次握手，https认证过程可以知道最好，但我不会说，并保留关于http访谈的文章。
挥了四次
四个摇摆器也是如此。切勿使用来自对方的FIN消息。我们有一条ACK消息，然后我们有一条FIN消息，我们有一条ACK消息。然后结束，最好多说一点细节，例如，想想以下几乎是一样的，要记住每个阶段的状态，我在上次采访中被问过几次，呵呵。我弄错了，以为我是对的。我当时解释的头是Dao，呵呵。
一开始，双方都处于建立状态。如果客户端首先发出关闭请求，则：
1.第一波：客户端发送FIN消息，并在消息中指定序列号。此时客户端处于CLOSED_WAIT1状态。
2.第二次握手：服务器收到FIN后，发送ACK报文，客户端的序列号+ 1作为ACK报文的序列号，表示客户端收到了报文。服务器处于CLOSE_WAIT2状态。3.第三波：如果服务器想要断开连接，与客户端的第一波相同，则发送FIN消息并指定序列号。此时服务器处于LAST_ACK状态。
4.第四波：客户端收到FIN后，发送ACK消息作为响应，服务器的序列号值为+ 1，作为ACK消息的序列号值。客户端处于TIME_WAIT状态。在进入CLOSED状态之前，确保服务器收到自己的ACK消息需要一段时间。
5.收到ACK数据包后，服务器关闭并处于CLOSED状态。
这里需要做的主要事情是TIME_WAIT的状态。这是采访的高频测试点。这是为了理解为什么客户端在发送ACK后不直接关闭，而是等待一段时间才能关闭。这样做的原因是为了确保服务器已收到我们的ACK消息。如果未收到，服务器将重新发送FIN消息给客户端。客户端再次收到FIN消息后，它知道前一个消息。 ACK数据包丢失，然后再次发送ACK数据包。
至于TIME_WAIT的持续时间，它至少是消息的往返时间。通常，设置计时器。如果在此时间之后没有再次接收到FIN消息，则另一方的成功是ACK消息，并且它处于CLOSED状态。
在这里我给出每个州的含义，如果你有兴趣，你可以看一下。
LISTEN  - 侦听来自远程TCP端口的连接请求；
SYN-SENT  - 发送连接请求后等待匹配的连接请求；
SYN-RECEIVED  - 接收和发送连接请求后等待确认连接请求；
ESTABLISHED-代表一个开放的连接，数据可以传递给用户；
FIN-WAIT-1  - 等待远程TCP连接中断请求，或确认先前的连接中断请求；
FIN-WAIT-2  - 等待来自远程TCP的连接中断请求；
CLOSE-WAIT  - 等待来自本地用户的连接中断请求；
CLOSING  - 等待远程TCP确认连接中断；
LAST-ACK  - 确认最初发送到远程TCP的连接中断请求；
TIME-WAIT  - 等待足够的时间以确保远程TCP收到连接中断请求的确认；

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: 使用自签名证书实施Nginx HTTPS

• 分享到：