TCP为什么是三次握手,不是四次或两次,终于理解了

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/qq_36865108/article/details/84885506

过往

我很久以前就看过三次握手和四次挥手的博客,但根本没懂,直到最近为了面试再看,也是仅仅知道过程,至于面试中的为什么需要三次握手,而不是四次或两次?,网上的博客千千万,国内外的,我还是一直没有理解,知道今天看了学校发的教科书上的解释,这才理解了.

解惑

我写下这些,仅供我自己和有缘和我有一样想法的人看懂

网上关于三次握手和四次挥手的图太多了,我懒得copy一份了,就文字说一说
前两次握手很好理解,就是发送端先发一个SYN=1,seq=x(SYN和seq等等字段自行查找TCP首部字段详解),表示我发送端要和你接受端建立连接,接收端在接受到这个请求报文段时,为了表示我接收端接收到了,要给发送端一个表示我接收到了的消息,发送的是SYN=1,ACK=1,seq=y,ack=x+1这里就有的说了.

我的书上说,三次握手这个比喻并不恰当,准确的说,应该是三报文握手,因为书的作者认为,这个过程其实是一次握手中进行了三次报文交换,而不是三次握手,硬要用握手来说,也是两个人见面握住手,摇晃了三下,这也符合现实.

接着前一段说,接收端发给接收端的消息,其实也可以分为两段,一个是ACK=1,ack=x+1,另一个是SYN=1,seq=y,前一个是确认报文段,是告诉发送端,我接收到你的消息了,后者则是同步报文段,是接收端发给发送端的建立连接的报文,但是这两个报文段在一个tcp首部并不冲突,所以可以一次发过去.

再来,发送端接收到接收端发送的报文,知道接收端刚才接收到了自己的消息,按理说,这个时候连接就建立了,该发数据了啊,为什么还要再确定一次呢?

这里我们用一个现实的例子来解释.就拿大家都喜欢的约会来解释.发送端相当一个男生,接收端是一个女生.一开始,男生发送一条微信告诉女生,今天晚上九点在公园见面呗,然后这条消息因为不可抗力,没有发送到女生的手机上,这时,这条消息有两个去路,一个是彻底消失,另一个是它迷失在网络中,没有找到方向.回来继续说,男生看女生没有回应,就又发了一条一样的微信,这次微信顺利的发过去了,男生女生也顺利的见面了,这一天也就这么过去了.到了第二天,那条迷失在网络中的微信重新找到了方向(真正的网络信息不可能滞留这么久,例子而已),发到了女生的手机上,女生一看,很高兴,毕竟昨天玩的很开心,以为今天又可以开心一次,就又去了,男生昨天玩了一晚上,身体跟不上,就在家躺着,也早忘了那条迷失的微信.就这样,女生在公园等了很久,很难受.

其实上面的例子已经说的很明白了,保险起见,再在具体连接里说一下.如果是两次连接,很可能发生上面的问题,如果有消息在一次tcp连接完成后才到达接收端,那么接收端以为是新的连接,就会发确认报文到接收端确认并建立连接,但发送端可能已经关闭,即使没关闭,在没有到达SYN-SENT状态时,也不会响应接收端的确认信息,接收端可能就这样等待,这在网络中就浪费了资源.

但是有了第三次报文确定就不一样了,第三次,发送端在此发送确认报文包接收端,接收端接收到后,也就知道了发送端接收到自己的确认信息了,如果在此发生上面的问题,接收端再次接收到了滞留在网络中的信息,发送确认信息给发送端,但是当发送端没有理会的时候,接收端也就知道这是错误信息,就不会等待,也就没有资源浪费了.

说句题外话,即使是三次握手也不能保证百分百的连接确定,想象一下这样的场景,两军对阵,A军分两部分位于两个山头,B军在两山之间,只有两个A军联合才能战胜B军,但是两个A军之间的路径就只有经过B军的一条线路.任何送信人都有可能被拦截杀掉.

这个时候,如果两A军想联合出击,必须派出密探传送进军指令,这就有一个问题存在,假设第一次送信成功,A2知道了A1的计划,那他必须再发一一封信告诉A1自己知道了,不然A1怎么知道A2收没收到,万一信被拦截了,自己明天一个人去,不是找死.再假设A2给A1的表明自己收到信息的信也顺利发到A1了,那就安全了吗,这个时候A2就担心自己的信送没送到,万一没送到,那明天自己去,不也是找死.显然A1也知道这个问题,所以又要发送第三封信,告诉A2自己收到信了,我们再一次假设,A2收到了这第三封信,但是同样的问题又发生了,A1还是担心这第三封信送没送到,毕竟关乎生死,A2当然也知道,就只能再送信,
可以看到,这样其实是没有止境的,也是无解的,在TCP协议中,我们不使用四次,五次握手,是因为达到的效果是一样的,但是消耗更多的资源,得不偿失

展开阅读全文

没有更多推荐了,返回首页