计算机网络 三次握手和四次挥手

三次握手

简单描述

首先,简单的三次握手过程如下所示:

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

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

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

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

详细描述

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

  1. 第一次握手:客户端给服务端发送一个SYN报文,并且指明客户端的初始化序列号为ISN©,此时客户端处于SYN_Send
  2. 第二次握手:服务端收到客户端的SYN报文之后,会以自己的SYN报文作为应答,并且也是指定了服务端的初始化序列号为ISN(s),还会将 客户端的序列号(ISN©)+ 1 作为ACK的值,表示自己已经收到了客户端的SYN报文,此时服务端的状态为SYN_REVD
  3. 第三次握手:客户端收到服务端的SYN报文之后,会发送一个ACK报文,会把服务端的序列号(ISN(s)) + 1 作为ACK的值,表示自己已经收到了服务端的SYN报文,此时客户端的状态为establised
  4. 最后,服务端收到了客户端的ACK报文,也会处于establised状态,此时,双方已经建立了连接,三次握手结束。

作用

  1. 确认双方(客户端,服务器端)的接受能力、发送能力是否正常。

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

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

衍生问题

  1. 为什么三次握手不可以变成两次?
    第一次握手:客户端发送网络包,服务端收到了。这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。
    第二次握手:服务端发包,客户端收到了。这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
    第三次握手:客户端发包,服务端收到了。这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。
    所以需要三次握手,才可以确保客户端和服务端的接收、发送能力正常。
  2. ISN是什么?(ISN)是固定的吗?
    三次握手的一个重要功能是客户端和服务端交换ISN(Initial Sequence Number), 以便让对方知道接下来接收数据的时候如何按序列号组装数据。
    如果ISN是固定的,攻击者很容易猜出后续的确认号,因此 ,ISN 是动态生成的。
  3. 什么是半连接队列?什么是全连接队列?
    • 半连接队列:服务器第一次收到客户端的 SYN 之后,就会处于 SYN_RCVD 状态,此时双方还没有完全建立其连接,服务器会把此种状态下请求连接放在一个队列里,我们把这种队列称之为半连接队列。
    1. 全连接队列:已经完成三次握手后,建立起来的连接就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
  4. SYN-ACK重传次数的机制
    服务器发送完SYN-ACK包,如果未收到客户确认包,服务器进行首次重传,等待一段时间仍未收到客户确认包,进行第二次重传,如果重传次数超 过系统规定的最大重传次数,系统将该连接信息从半连接队列中删除。注意,每次重传等待的时间不一定相同,一般会是指数增长,例如间隔时间为 1s, 2s, 4s, 8s, ….
  5. 三次握手过程中可以携带数据吗
    第一次、第二次握手不可以携带数据,而第三次握手是可以携带数据的。
    假如第一次握手可以携带数据的话,如果有人要恶意攻击服务器,那他每次都在第一次握手中的 SYN 报文中放入大量的数据,因为攻击者根本就不理服务器的接收、发送能力是否正常,然后疯狂着重复发送 SYN 报文的话,这会让服务器花费很多时间、内存空间来接收这些报文。也就是说,第一次握手可以放数据的话,其中一个简单的原因就是会让服务器更加容易受到攻击了。
    而对于第三次的话,此时客户端已经处于 established 状态,也就是说,对于客户端来说,它已经建立起连接了,并且也已经知道服务器的接收、发送能力是正常的了,所以能携带数据也没什么问题。

四次挥手

详细描述

刚开始的时候,客户端和服务端均处于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 状态。

衍生问题

TIME_WAIT状态的意义
要确保服务器是否已经收到了我们的 ACK 报文,如果没有收到的话,服务器会重新发 FIN 报文给客户端,客户端再次收到 FIN 报文之后,就知道之前的 ACK 报文丢失了,然后再次发送 ACK 报文。
至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时,如果过了这个计时没有再次收到 FIN 报文,则代表对方成功就是 ACK 报文,此时处于 CLOSED 状态。

三次握手和四次挥手总览

在这里插入图片描述

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

赈川

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值