目录

 

​关于三次握手与四次挥手面试官想考我们什么?​

​三次握手​

​四次挥手​

​TCP连接为什么是三次握手?断开为什么是四次挥手?​

​TCP三次握手过程​

​4次断开​

​解释原因:​

​TCP的状态变迁图:​



TCP报文格式

【三次握手四次断开】TCP三次握手过程和四次断开_服务端

 

关于三次握手与四次挥手面试官想考我们什么?

在面试中,三次握手和四次挥手可以说是问的最频繁的一个知识点,下面是比较重要的点,是比较被面试官给问到:

 

三次握手

当面试官问你为什么需要有三次握手、三次握手的作用、讲讲三次三次握手的时候,我想很多人会这样回答:

首先很多人会先讲下握手的过程:

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

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

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

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

作用是为了 确认双方的接收与发送能力是否正常 + 同步序列号。

这里我顺便解释一下为啥只有三次握手才能确认双方的接受与发送能力是否正常,而两次却不可以: 第一次握手:客户端发送网络包,服务端收到了。这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。 第二次握手:服务端发包,客户端收到了。这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。 第三次握手:客户端发包,服务端收到了。这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。

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

这样回答其实也是可以的,但我觉得,这个过程的我们应该要描述的更详细一点,因为三次握手的过程中,双方是由很多状态的改变的,而这些状态,也是面试官可能会问的点。所以我觉得在回答三次握手的时候,我们应该要描述的详细一点,而且描述的详细一点意味着可以扯久一点。加分的描述我觉得应该是这样:

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

1、第一次握手:客户端给服务端发一个 SYN 报文,并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_Send 状态。

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

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

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

 

【三次握手四次断开】TCP三次握手过程和四次断开_客户端_02

 

【三次握手四次断开】TCP三次握手过程和四次断开_三次握手_03

三次握手的作用

 

三次握手的作用也是有好多的,多记住几个,保证不亏。例如:

1、确认双方收发能力正常。

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

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

 

三次握手建立连接的首要目的是(SYN)同步序列号。只有同步了序列号才有可靠的传输,TCP 协议的许多特性都是依赖序列号实现的,比如流量控制重传等等,这也是三次握手中的报文被称为 SYN 的原因,因为 SYN 的全称就叫做 Synchronize SequenceNumbers。

链接:https://www.jianshu.com/p/74c19f436c2d

 

单单这样还不足以应付三次握手,面试官可能还会问一些其他的问题,例如:

1、(ISN)是固定的吗

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

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

2、什么是半连接队列

服务器第一次收到客户端的 SYN 之后,就会处于 SYN_RCVD 状态,此时双方还没有完全建立其连接,服务器会把此种状态下请求连接放在一个队列里,我们把这种队列称之为半连接队列。当然还有一个全连接队列,就是已经完成三次握手,建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

这里在补充一点关于 SYN-ACK 重传次数的问题: 服务器发送完SYN-ACK包,如果未收到客户确认包,服务器进行首次重传,等待一段时间仍未收到客户确认包,进行第二次重传,如果重传次数超 过系统规定的最大重传次数,系统将该连接信息从半连接队列中删除。注意,每次重传等待的时间不一定相同,一般会是指数增长,例如间隔时间为 1s, 2s, 4s, 8s, ....

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

其实第三次握手的时候,是可以携带数据的。也就是说,第一次、第二次握手不可以携带数据,而第三次握手是可以携带数据的。

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

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

关于三次握手的,https 的认证过程能知道一下最好,不过我就不说了,留着写 http 面试相关时的文章再说。

 

四次挥手

四次挥手也一样,千万不要对方一个 FIN 报文,我方一个 ACK 报文,再我方一个 FIN 报文,我方一个 ACK 报文。然后结束,最好是说的详细一点,要把每个阶段的状态记好,我上次面试就被问了几个了:

 

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

1、第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时服务端处于CLOSED_WAIT1状态。

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

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

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

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

 

【三次握手四次断开】TCP三次握手过程和四次断开_服务器_04

【三次握手四次断开】TCP三次握手过程和四次断开_服务器_05

(主动关闭(active close)的一方,被动关闭(passive close)的一方,网络上类似的图有很多,但是有的细节不够,有的存在误导。有的会把两条线分别标记成Client和Server。给读者造成困惑。)

 

这里特别需要主要的就是TIME_WAIT这个状态了,这个是面试的高频考点,就是要理解,为什么客户端发送 ACK 之后不直接关闭,而是要等一阵子才关闭。这其中的原因就是,要确保服务器是否已经收到了我们的 ACK 报文,如果没有收到的话,服务器会重新发 FIN 报文给客户端,客户端再次收到 ACK 报文之后,就知道之前的 ACK 报文丢失了,然后再次发送 ACK 报文。

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

最后,在放在三次握手与四次挥手的图

【三次握手四次断开】TCP三次握手过程和四次断开_三次握手_06

【三次握手四次断开】TCP三次握手过程和四次断开_三次握手_07

这里我给出每个状态所包含的含义,有兴趣的可以看看。

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 - 没有任何连接状态;
TCP连接为什么是三次握手?断开为什么是四次挥手?

 

1.三次握手

TCP连接换成四次握手行不行?为什么?换成两次握手行不行?为什么? 这是我面试时遇到的原题

首先来说一下三次握手,为什么需要三次握手呢?因为TCP提供的是可靠传输服务,因此它在传输之前必须要进行传输的可靠性测试和一些信息的同步,反观UDP就不用这些握手操作。三次握手正好使双方都能测试传输的可靠性,同时也能进行信息同步,三次握手过程如下:

【三次握手四次断开】TCP三次握手过程和四次断开_服务器_08

那么三次握手到底是在握什么呢?抓包测试一下:

【三次握手四次断开】TCP三次握手过程和四次断开_服务端_09

三次握手的作用

第一次握手:client同步自己的发送序号seq和接收窗口win(还有其他可选信息),同时测试自己的发送能力是否正常

第二次握手:server发送确认号ack,证明了client发送正常。同时同步自己的发送信息seq和win,还要测试自己的发送能力是否正常

第三次握手:client发送确认号ack,证明了server发送正常

至此,发送信息同步完成,可靠性测试完成

两次握手是否可以

可以发现,前两次握手都需要发送同步信息,因此前两次肯定是必不可少的,唯一有可能的就是第三次,但是从上面的分析来看,如果少了第三次握手,那么client知道自己的发送能力正常,发送信息也同步完成,但是server不能确定自己的发送能力是否正常,也不知道自己的发送信息是否同步完成,因此第三次握手也是必不可少的。

PS:SYN泛洪攻击原理就是恶意终端故意不发送第三个握手包,操作系统在发送完第二次握手包后,会分配一些资源给这个半连接,同时将这个半连接放入半连接队列,半连接过多时会导致server半连接队列满,正常用户的请求得不到相应,同时过多的半连接占用过多的资源还会影响server性能。

四次握手是否可以

有的人可能会想,第三次握手万一丢失了呢?是不是需要第四次握手来对第三次进行确认?第三次握手确实可能会丢失,假如采用第四次来对第三次进行确认,那么第四次需要第五次来确人… …可以发现无论是四次五次或是更多次效果都是一样的,这样的协议既不可能实现也没有任何的效率可言。于是TCP采用了超时重传的策略来保证传输的可靠性,server在发送完第二次握手包之后,就会开启一个定时器,超时后如果没有收到第三次握手包,它就会重新发送SYN+ACK,重复以上步骤,如果失败三次后则说明连接失败,数据传输时采用同样的策略。

四次挥手

TCP四次挥手流程:

【三次握手四次断开】TCP三次握手过程和四次断开_三次握手_10

抓包测试:

【三次握手四次断开】TCP三次握手过程和四次断开_服务端_11

为什么断开连接需要四次挥手

我们都知道,TCP连接是全双工通信的,而断开时双方都需要确定两个问题:自己是否还有数据要发送,对端是否还有数据要发送,而四次挥手正好在双方同步了这两个问题。

第一次挥手:client告诉server自己的数据已全部发送,client可以回收发送缓冲区,server可以回收接收缓冲区

第二次挥手:server告诉client自己收到了关闭信息

第三次挥手:server告诉client自己的数据已全部发送,server可以回收发送缓冲区,client可以回收接收缓冲区

第四次挥手:client告诉server自己收到了关闭信息

可以发现,四次挥手同样一次都不能少,如果少了其中任何一次,总有一方不能可靠的通知对方自己的数据已发送完毕,因此,连接不可能可靠的断开,TCP也就成了不可靠的协议。


 

#################################################################################################

 

TCP三次握手过程

1 主机A通过向主机B 发送一个含有同步序列号的标志位的数据段给主机B ,向主机B 请求建立连接,通过这个数据段,

主机A告诉主机B 两件事:我想要和你通信;你可以用哪个序列号作为起始数据段来回应我.

2 主机B 收到主机A的请求后,用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A,也告诉主机A两件事:

我已经收到你的请求了,你可以传输数据了;你要用哪个序列号作为起始数据段来回应我

3 主机A收到这个数据段后,再发送一个确认应答,确认已收到主机B 的数据段:"我已收到回复,我现在要开始传输实际数据了

【三次握手四次断开】TCP三次握手过程和四次断开_服务器_12

这样3次握手就完成了,主机A和主机B 就可以传输数据了.
3次握手的特点
没有应用层的数据
SYN这个标志位只有在TCP建产连接时才会被置1
握手完成后SYN标志位被置0

4次断开

1 当主机A完成数据传输后,将控制位FIN置1,提出停止TCP连接的请求

2 主机B收到FIN后对其作出响应,确认这一方向上的TCP连接将关闭,将ACK置1

3 由B 端再提出反方向的关闭请求,将FIN置1

4 主机A对主机B的请求进行确认,将ACK置1,双方向的关闭结束.

由TCP的三次握手和四次断开可以看出,TCP使用面向连接的通信方式,大大提高了数据通信的可靠性,使发送数据端

和接收端在数据正式传输前就有了交互,为数据正式传输打下了可靠的基础

【三次握手四次断开】TCP三次握手过程和四次断开_三次握手_13

名词解释
ACK TCP报头的控制位之一,对数据进行确认.确认由目的端发出,用它来告诉发送端这个序列号之前的数据段
都收到了.比如,确认号为X,则表示前X-1个数据段都收到了,只有当ACK=1时,确认号才有效,当ACK=0时,确认号无效,这时会要求重传数据,保证数据的完整性.
SYN 同步序列号,TCP建立连接时将这个位置1
FIN 发送端完成发送任务位,当TCP完成数据传输需要断开时,提出断开连接的一方将这位置1

解释原因:

TCP建立连接要进行3次握手,而断开连接要进行4次,这是由于TCP的半关闭造成的,因为TCP连接是全双工的(

即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭,这个单方向的关闭就叫半关闭.

关闭的方法是一方完成它的数据传输后,就发送一个FIN来向另一方通告将要终止这个方向的连接.当一端收到一个FIN,它必须

通知应用层TCP连接已终止了这个方向的数据传送,发送FIN通常是应用层进行关闭的结果.

 

为什么不能两次握手能进行连接?

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

 

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 的资源浪费

 

 

TCP的状态变迁图:

【三次握手四次断开】TCP三次握手过程和四次断开_三次握手_14

 

【三次握手四次断开】TCP三次握手过程和四次断开_客户端_15

请问如何提升TCP三次握手的性能?

​https://www.jianshu.com/p/74c19f436c2d​