在面试中，三次握手和四次挥手能够说是问的最频繁的一个知识点了，我相信你们也都看过不少关于三次握手与四次挥手的文章，今天的这篇文章，重点是围绕着面试，咱们应该掌握哪些比较重要的点，哪些是比较被面试官给问到的，我以为若是你能把我下面列举的一些点都记住、理解，我想就差很少了。web
三次握手
当面试官问你为何须要有三次握手、三次握手的做用、讲讲三次三次握手的时候，我想不少人会这样回答：面试
首先不少人会先讲下握手的过程：服务器
一、第一次握手：客户端给服务器发送一个 SYN 报文。网络
二、第二次握手：服务器收到 SYN 报文以后，会应答一个 SYN+ACK 报文。加密
三、第三次握手：客户端收到 SYN+ACK 报文以后，会回应一个 ACK 报文。orm
四、服务器收到 ACK 报文以后，三次握手创建完成。cdn
做用是为了确认双方的接收与发送能力是否正常。队列
这里我顺便解释一下为啥只有三次握手才能确认双方的接受与发送能力是否正常，而两次却不能够：
第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器本身的发送、接收能力也正常。内存
所以，须要三次握手才能确认双方的接收与发送能力是否正常。it
这样回答其实也是能够的，但我以为，这个过程的咱们应该要描述的更详细一点，由于三次握手的过程当中，双方是由不少状态的改变的，而这些状态，也是面试官可能会问的点。因此我以为在回答三次握手的时候，咱们应该要描述的详细一点，并且描述的详细一点意味着能够扯久一点。加分的描述我以为应该是这样：
刚开始客户端处于 closed 的状态，服务端处于 listen 状态。而后
一、第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_Send 状态。
二、第二次握手：服务器收到客户端的 SYN 报文以后，会以本身的 SYN 报文做为应答，而且也是指定了本身的初始化序列号 ISN(s)，同时会把客户端的 ISN + 1 做为 ACK 的值，表示本身已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。
三、第三次握手：客户端收到 SYN 报文以后，会发送一个 ACK 报文，固然，也是同样把服务器的 ISN + 1 做为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 establised 状态。
四、服务器收到 ACK 报文以后，也处于 establised 状态，此时，双方以创建起了连接。
三次握手的做用
三次握手的做用也是有好多的，多记住几个，保证不亏。例如：
一、确认双方的接受能力、发送能力是否正常。
二、指定本身的初始化序列号，为后面的可靠传送作准备。
三、若是是 https 协议的话，三次握手这个过程，还会进行数字证书的验证以及加密密钥的生成到。
单单这样还不足以应付三次握手，面试官可能还会问一些其余的问题，例如：
一、(ISN)是固定的吗
三次握手的一个重要功能是客户端和服务端交换ISN(Initial Sequence Number), 以便让对方知道接下来接收数据的时候如何按序列号组装数据。
若是ISN是固定的，攻击者很容易猜出后续的确认号，所以 ISN 是动态生成的。
二、什么是半链接队列
服务器第一次收到客户端的 SYN 以后，就会处于 SYN_RCVD 状态，此时双方尚未彻底创建其链接，服务器会把此种状态下请求链接放在一个队列里，咱们把这种队列称之为半链接队列。固然还有一个全链接队列，就是已经完成三次握手，创建起链接的就会放在全链接队列中。若是队列满了就有可能会出现丢包现象。
这里在补充一点关于SYN-ACK 重传次数的问题： 服务器发送完SYN－ACK包，若是未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，若是重传次数超 过系统规定的最大重传次数，系统将该链接信息从半链接队列中删除。注意，每次重传等待的时间不必定相同，通常会是指数增加，例如间隔时间为 1s, 2s, 4s, 8s, ....
三、三次握手过程当中能够携带数据吗
不少人可能会认为三次握手都不能携带数据，其实第三次握手的时候，是能够携带数据的。也就是说，第一次、第二次握手不能够携带数据，而第三次握手是能够携带数据的。
为何这样呢？你们能够想一个问题，假如第一次握手能够携带数据的话，若是有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，由于攻击者根本就不理服务器的接收、发送能力是否正常，而后疯狂着重复发 SYN 报文的话，这会让服务器花费不少时间、内存空间来接收这些报文。也就是说，第一次握手能够放数据的话，其中一个简单的缘由就是会让服务器更加容易受到攻击了。
而对于第三次的话，此时客户端已经处于 established 状态，也就是说，对于客户端来讲，他已经创建起链接了，而且也已经知道服务器的接收、发送能力是正常的了，因此能携带数据页没啥毛病。
关于三次握手的，https 的认证过程能知道一下最好，不过我就不说了，留着写 http 面试相关时的文章再说。
四次挥手
四次挥手也同样，千万不要对方一个 FIN 报文，我方一个 ACK 报文，再我方一个 FIN 报文，我方一个 ACK 报文。而后结束，最好是说的详细一点，例如想下面这样就差很少了，要把每一个阶段的状态记好，我上次面试就被问了几个了，呵呵。我答错了，还觉得本身答对了，当时还解释的头头是道，呵呵。
刚开始双方都处于 establised 状态，假如是客户端先发起关闭请求，则：
一、第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于CLOSED_WAIT1状态。
二、第二次握手：服务端收到 FIN 以后，会发送 ACK 报文，且把客户端的序列号值 + 1 做为 ACK 报文的序列号值，代表已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT2状态。
三、第三次挥手：若是服务端也想断开链接了，和客户端的第一次挥手同样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
四、第四次挥手：客户端收到 FIN 以后，同样发送一个 ACK 报文做为应答，且把服务端的序列号值 + 1 做为本身 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。须要过一阵子以确保服务端收到本身的 ACK 报文以后才会进入 CLOSED 状态
五、服务端收到 ACK 报文以后，就处于关闭链接了，处于 CLOSED 状态。
这里特别须要主要的就是TIME_WAIT这个状态了，这个是面试的高频考点，就是要理解，为何客户端发送 ACK 以后不直接关闭，而是要等一阵子才关闭。这其中的缘由就是，要确保服务器是否已经收到了咱们的 ACK 报文，若是没有收到的话，服务器会从新发 FIN 报文给客户端，客户端再次收到 ACK 报文以后，就知道以前的 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接收到链接中断请求的确认；
CLOSED - 没有任何链接状态；
最后，在放在三次握手与四次挥手的图
扫一扫
997
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
