TCP协议为了保证数据传输的可靠性,所以发明了几种机制:确认应答、超时重传、连接管理(即三次握手四次挥手)来确保网络通信中进行数据传输的可靠性,本文中我们对连接管理(即三次握手四次挥手)来进行TCP可靠性分析的讲解。

一、三次握手

在TCP协议中,三次握手是用于建立连接的过程。客户端和服务器通过互相发送特定的控制报文来确认彼此的可达性和同意建立连接。这个过程确保了双方的通信能力,并且在开始数据传输之前建立了可靠的连接。
四次挥手则是用于关闭连接的过程。当一方决定关闭连接时,它会发送一个关闭连接的请求给另一方。对方确认接收后,双方分别关闭自己的数据传输,并最终确认关闭连接。这个过程确保了双方在结束通信后,释放资源并关闭连接。

在现实生活中,握手一般用于和对方打招呼,然后再开启后面的话题。网络通信中也是如此,我们通过“握手”来发送一个打招呼的数据(用于触发某些特定的场景,这些数据并不包含业务信息)。

三次握手的意义

  • 第一点:投石问路

三次握手也是TCP保证数据传输可靠性的一种方式:TCP要想保证数据传输的可靠性,就需要以网络传输、网络路径畅通为前提,还可以验证每个主机的发送能力和接收能力是否正常,简单来说三次握手的意义就是投石问路

  • 第二点:消息协商
    TCP通信过程中,有很多信息需要进行协商,协商这个信息是不是属于本次连接的。为什么这么说呢?是因为网络上传输的信息可能是后发先至的,比如说现在有一个信息迟到了,而此时这个信息所属的连接早就关闭了(服务器与客户端已经断开了上一个连接),此时是一个重新建立的连接,这个时候我们就可以通过消息的信号来明显的识别出这个消息是属于上一个连接的,所以直接将这个连接丢掉即可

综上三次握手主要有两个主要意义:意义1(投石问路):通过投石问路可以验证网络是否发生故障,也可以验证通信双方的发送接受能力是否正常。意义2(消息协商):通过协商必要的参数来使客户端和服务器使用相同的参数进行消息传输。

二、四次挥手

四次挥手即断开服务器和客户端之间的连接。我们只要连接的概念就是通信双方各自在内存中保有通向双方对端的信息,如果我们需要断开连接的话,我们就需要及时释放上面内存中的对端信息。

补充:三次挥手一定是客户端主动向服务器发起的请求;但是四次挥手不一定是谁向谁发起的请求,但绝大多数的情况下都是客户端主动向服务器发起请求建立连接的。

三、三次握手四次挥手的丢包问题

三次握手的丢包问题:

  • 第一次握手时,客户端发送SYN数据包到服务器,如果发生丢包则无法建立连接,此时TCP协议就会触发超时重传机制,客户端就会再次发送SYN数据包。
  • 第二次握手时,服务器接收到来自客户端超时重传过来的SYN数据包后,会发送SYN-ACK数据包回应给客户端,当然SYN-ACK数据包有可能丢包,此时就会触发超时重传。如果超时重传多次之后客户端依然没有接收到SYN-ACK数据包,则客户端则任务服务器不可达,并放弃建立连接的尝试
  • 第三次握手时,客户端接收到来自服务器的SYN-ACK数据包(当然可能是超时重传过来的SYN-ACK数据包)之后,此时客户端就会向服务器发送ACK数据包(表示客户端已成功收到来自服务器的 SYN-ACK 应答,可以建立连接。)。如果服务器没有接收到ACK数据包,此时依然会发生超时重传机制。如果发生了丢包,那么服务器并不知道客户端接收到了 SYN-ACK 应答,因此连接无法建立。

四次挥手过程中的丢包:

  • 第一次挥手:客户端向服务器发送FIN数据包,表示要关闭连接。如果发生丢包,则服务器会继续等待客户端发送FIN数据包,如果服务器一直没有接收到FIN数据包的话,TCP协议就会触发超时重传。
  • 第二次挥手:服务器接收到FIN数据包之后,就会向客户端发送ACK数据包,如果发生丢包,则会触发超时重传。
  • 第三次挥手:如果客户端没有接收到ACK的话,则触发超时重传,如果超时重传多次后依然没有ACK数据包,客户端可能任务服务器已经关闭连接,并释放对端的资源。
  • 第四次挥手:。极端情况:在四次挥手过程中,如果第四步中 ACK 数据包被丢失,服务器会认为客户端仍然没有确认连接关闭的请求,因此会认为连接没有完全关闭,会继续等待客户端的确认,并尝试不断发送 FIN 数据包,直到达到超时时间为止。如果 FIN 数据包的重传次数达到上限,服务器会认为连接已经关闭,释放资源。

四、总结

我们现在已经知道TCP协议通过确认应答、超时重传、连接管理来进行保证数据传输的可靠性,其中起到决定性作用的是确认应答,连接管理即三次握手四次挥手在一定程度上可以用来检验网络是否可靠,而确认应答可以则保证每次数据传输都是可靠的。

本文到这里就结束了,希望友友们可以支持一下一键三连哈。嗯,就到这里吧,再见啦!!!

【计算机网络】TCP原理 | 可靠性机制分析(二)-LMLPHP

01-10 06:49