本文主要是介绍tcp三次握手及其必要性,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接,如下图所示。
主机A为客户机,主机B为服务器
确认号:其数值等于发送方的发送序号 +1(即接收方期望接收的下一个序列号)。
(1)第一次握手:建立连接时,客户端A发送SYN包(SYN=j)到服务器B,并进入SYN_SEND状态,等待服务器B确认。
(2)第二次握手:服务器B收到SYN包,必须确认客户A的SYN(ACK=j+1),同时自己也发送一个SYN包(SYN=k),即SYN+ACK包,此时服务器B进入SYN_RECV状态。
(3)第三次握手:客户端A收到服务器B的SYN+ACK包,向服务器B发送确认包ACK(ACK=k+1),此包发送完毕,客户端A和服务器B进入ESTABLISHED状态,完成三次握手。
必要性:
这两天一直在考虑一个问题,就是两者为何要三次握手呢,一次或者两次不行吗
考虑一次的问题,首先tcp是面向连接,一次握手肯定建立不了连接,因为客户机给服务器发出请求信息却没有得到回应,客户机是没法判定是否发送成功然后建立连接的。
再看两次,假设只有两次握手,比如图中的1,2步,当A想要建立连接时发送一个SYN,然后等待ACK,结果这个SYN因为网络问题没有及时到达B,所以A在一段时间内没收到ACK后,再发送一个SYN,这次B顺利收到,接着A也收到ACK,这时A发送的第一个SYN终于到了B,对于B来说这是一个新连接请求,然后B又为这个连接申请资源,返回ACK,然而这个SYN是个无效的请求,A收到这个SYN的ACK后也并不会理会它,而B却不知道,B会一直为这个连接维持着资源,造成资源的浪费。
三次连接就没毛病了??是的
两次握手的问题在于服务器端不知道一个SYN是否是无效的,而三次握手机制因为客户端会给服务器回复第二次握手,也意味着服务器会等待客户端的第三次握手,如果第三次握手迟迟不来,服务器便会认为这个SYN是无效的,释放相关资源。但这时有个问题就是客户端完成第二次握手便认为连接已建立,而第三次握手可能在传输中丢失,服务端会认为连接是无效的,这时如果Client端向Server写数据,Server端将以RST包响应,这时便感知到Server的错误。
总之,三次握手可以保证任何一次握手的失败都是可感知的,不会浪费资源
三次握手出现错误时的应对措施
第一次握手A发送SYN传输失败,A,B都不会申请资源,连接失败。如果一段时间内发出多个SYN连接请求,那么A只会接受它最后发送的那个SYN的SYN+ACK回应,忽略其他回应全部回应,B中多申请的资源也会释放
第二次握手B发送SYN+ACK传输失败,A不会申请资源,B申请了资源,但收不到A的ACK,过一段时间释放资源。如果是收到了多个A的SYN请求,B都会回复SYN+ACK,但A只会承认其中它最早发送的那个SYN的回应,并回复最后一次握手的ACK
第三次握手ACK传输失败,B没有收到ACK,释放资源,对于后序的A的传输数据返回RST。实际上B会因为没有收到A的ACK会多次发送SYN+ACK,次数是可以设置的,如果最后还是没有收到A的ACK,则释放资源,对A的数据传输返回RST
这篇关于tcp三次握手及其必要性的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!