三次握手
简单描述
首先,简单的三次握手过程如下所示:
-
第一次握手:客户端给服务器发送一个 SYN 报文。
-
第二次握手:服务器收到 SYN 报文之后,会应答一个 SYN+ACK 报文。
-
第三次握手:客户端收到 SYN+ACK 报文之后,会回应一个 ACK 报文。
-
服务器收到 ACK 报文之后,三次握手建立完成。
详细描述
刚开始的时候,客户端处于closed的状态,服务端处于listen状态,然后:
- 第一次握手:客户端给服务端发送一个SYN报文,并且指明客户端的初始化序列号为ISN©,此时客户端处于SYN_Send
- 第二次握手:服务端收到客户端的SYN报文之后,会以自己的SYN报文作为应答,并且也是指定了服务端的初始化序列号为ISN(s),还会将 客户端的序列号(ISN©)+ 1 作为ACK的值,表示自己已经收到了客户端的SYN报文,此时服务端的状态为SYN_REVD
- 第三次握手:客户端收到服务端的SYN报文之后,会发送一个ACK报文,会把服务端的序列号(ISN(s)) + 1 作为ACK的值,表示自己已经收到了服务端的SYN报文,此时客户端的状态为establised
- 最后,服务端收到了客户端的ACK报文,也会处于establised状态,此时,双方已经建立了连接,三次握手结束。
作用
-
确认双方(客户端,服务器端)的接受能力、发送能力是否正常。
-
指定自己的初始化序列号,为后面的可靠传送做准备。
-
如果是 https 协议的话,三次握手这个过程,还会进行数字证书的验证以及加密密钥的生成。
衍生问题
- 为什么三次握手不可以变成两次?
第一次握手:客户端发送网络包,服务端收到了。这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。
第二次握手:服务端发包,客户端收到了。这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手:客户端发包,服务端收到了。这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。
所以需要三次握手,才可以确保客户端和服务端的接收、发送能力正常。 - ISN是什么?(ISN)是固定的吗?
三次握手的一个重要功能是客户端和服务端交换ISN(Initial Sequence Number), 以便让对方知道接下来接收数据的时候如何按序列号组装数据。
如果ISN是固定的,攻击者很容易猜出后续的确认号,因此 ,ISN 是动态生成的。 - 什么是半连接队列?什么是全连接队列?
- 半连接队列:服务器第一次收到客户端的 SYN 之后,就会处于 SYN_RCVD 状态,此时双方还没有完全建立其连接,服务器会把此种状态下请求连接放在一个队列里,我们把这种队列称之为半连接队列。
- 全连接队列:已经完成三次握手后,建立起来的连接就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
- SYN-ACK重传次数的机制
服务器发送完SYN-ACK包,如果未收到客户确认包,服务器进行首次重传,等待一段时间仍未收到客户确认包,进行第二次重传,如果重传次数超 过系统规定的最大重传次数,系统将该连接信息从半连接队列中删除。注意,每次重传等待的时间不一定相同,一般会是指数增长,例如间隔时间为 1s, 2s, 4s, 8s, …. - 三次握手过程中可以携带数据吗
第一次、第二次握手不可以携带数据,而第三次握手是可以携带数据的。
假如第一次握手可以携带数据的话,如果有人要恶意攻击服务器,那他每次都在第一次握手中的 SYN 报文中放入大量的数据,因为攻击者根本就不理服务器的接收、发送能力是否正常,然后疯狂着重复发送 SYN 报文的话,这会让服务器花费很多时间、内存空间来接收这些报文。也就是说,第一次握手可以放数据的话,其中一个简单的原因就是会让服务器更加容易受到攻击了。
而对于第三次的话,此时客户端已经处于 established 状态,也就是说,对于客户端来说,它已经建立起连接了,并且也已经知道服务器的接收、发送能力是正常的了,所以能携带数据也没什么问题。
四次挥手
详细描述
刚开始的时候,客户端和服务端均处于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 报文,如果没有收到的话,服务器会重新发 FIN 报文给客户端,客户端再次收到 FIN 报文之后,就知道之前的 ACK 报文丢失了,然后再次发送 ACK 报文。
至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时,如果过了这个计时没有再次收到 FIN 报文,则代表对方成功就是 ACK 报文,此时处于 CLOSED 状态。