计算机网络基础–TCP 三次握手过程


假设有一个发送方计算机和一个接收方计算机,纵向为时间轴

image-20220329173828978

第一次握手

假设首先是发送方主动和接收方建立连接,所以,发送方会第一次发送一个报文(此时SYN=1,表示这是一个连接请求的报文,seq=x是同步发送方自己的序列号)

第二次握手

接收方在接收到连接请求后,也打开TCP连接,同时它也会发送一个报文,这个报文是第二次握手。报文信息中有

  • SYN=1:表示是一个连接请求

  • ACK=1:表示对序列号的确认

  • ack=x+1:小写的ack表示的是确认号。这里的ack=x+1,表示接受方期望收到的是x+1这个序列号的值

  • seq=y:同时接收方发送的报文中也会携带自己的序列号,也就是seq=y

第三次握手

发送方接收到报文之后,会进行回应,回应中的报文内容

  • ACK=1:表示这个报文的确认号是有效的

  • seq=x+1:发送方所携带的序列号,表示的是,当前发送方发送的数据序列号是x+1

  • ack=y+1:确认号是y+1,表示发送方期望接收到接收方的序列号是y+1的数据

通过这三次的握手,TCP的连接就建立起来了

在三次握手的时间轴中,不同的时间,接收方和发送方有不同的状态

  • 在接收方没有接收到数据之前,它一直处于监听状态(Listen)

  • 发送方在第一个报文发送出去,到接收到第一个报文的响应之间,属于同步已发送状态(SYNC-SENT),表示已经将SYN发送出去了,并且等待对方的SYN信息

  • 从接收方发送第一个报文,到接收到第二个报文之间,属于同步已接收状态(SYNC-RCVD),表示发送方发送给我的SYN信息,我已经收到了

  • 然后发送方就进入建立连接(ESTABLISHED)的状态了

  • 对发送方来说,只要第二次握手成功之后,发送方就建立起连接了。但是对接收方来说,只有接收到发送方的第三次握手之后,才是建立连接的状态(ESTABLISHED)

preview

双方对于建立连接状态的时间是不一样的,发送方只要在第二次握手成功之后,就变成了建立连接的状态。但是对接收方来说,只有接收到发送方的第三次握手之后,才是建立连接的状态。双方都进入建立连接的状态之后就可以进行数据的传输了

为什么发送方要发出第三个确认报文呢?为什么两次不行?

结论:避免已经失效的连接请求报文传送到对方,引起错误

假设此时有一个发送方计算机和一个接收方计算机。首先发送方需要发送一个建立连接的请求报文(第一次握手),假设第一次握手的报文在网络中传输很久才到达接收方,因为发送了很久,所以,发送方很久都没有收到接收方的确认消息。发送方就会认为第一个报文已经超时了,所以,发送方就会第二次发送同样的报文

img

假设第二次发送的报文,很快就到达了对方,接收方在收到第二次的连接请求报文之后,就会进行回应,并且建立起它们之间的连接。那么,对于发送方发送的第一次的请求报文,就应该是一个失效的请求报文,因为它的功能已经被第二次的连接请求所完成了。所以,对于第一次发送的请求连接报文,在网络中游荡了很久,其实就是一个失效的请求报文了,没有作用了

img

如果发送方发送的两次连接请求都建立起连接了会怎么样?

先考虑第二次请求的报文,这个报文是提前到达接收方的,接收方会对它进行一个回应,回应确认之后,就建立起连接了(因为我们是假设两次握手就建立起连接

现在考虑第一次发送的连接请求,如果两次握手就建立连接的话,对于失效的请求,它也会建立起连接,因为只要接收方回应了,就表示连接已经建立了

img

这样就会导致,同样的请求发送了两次,就会建立两个TCP连接的情况。这种情况是错误的,所以说,两次握手是不正确的

三次握手是如何解决两次握手导致的问题?

对于两次握手,只要接收方回应了,就表示连接建立了。而对于三次握手来说,第一个确认报文会首先到达发送方,然后发送方再发送一个确认报文(第三次握手),此时才算建立起连接

img

现在来考虑那个比较慢到达接收方的连接请求报文,这个报文,接收方也会发送一个确认报文给发送方(第二次握手)。但是发送方已经进行第三次握手了,因此发送方对于第二次的确认消息会忽略掉,并不会进行任何的操作。这样,第一次比较慢到达的连接请求就不会建立起连接,这就避免了两次握手所导致的错误

 

参考:https://zhuanlan.zhihu.com/p/191198530

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/281255.html

(0)
上一篇 2022年8月20日
下一篇 2022年8月20日

相关推荐

发表回复

登录后才能评论