tcp三次握手四次挥手详解_tcp为什么是四次挥手

tcp三次握手四次挥手详解_tcp为什么是四次挥手一直都知道TCP建立连接时需要三次握手,释放连接时需要四次挥手,也大概能说出整个过程,但是一直对其中的设计思想理解不深,停留在“只可意会,不可言传”的阶段。这次写一篇博客尝试将其中的思想表达出来。TCP建连三次握手首先解释一下每个步骤的作用:1、a时刻,A准备就绪,发送SYN包给B,尝试建立连接2、b时刻,B收到A发来的SYN包,知道A要请求建连,回…

大家好,又见面了,我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺

一直都知道 TCP 建立连接时需要三次握手,释放连接时需要四次挥手,也大概能说出整个过程,但是一直对其中的设计思想理解不深,停留在“只可意会,不可言传”的阶段。这次写一篇博客尝试将其中的思想表达出来。

TCP 建连三次握手

tcp三次握手四次挥手详解_tcp为什么是四次挥手

首先解释一下每个步骤的作用:
1、a 时刻,A 准备就绪,发送 SYN 包给 B,尝试建立连接
2、b 时刻,B 收到 A 发来的 SYN 包,知道 A 要请求建连,回 SYN ACK 包,告诉 A 自己收到了建连请求,可以建连了
3、c 时刻,A 收到了 B 的回复,知道 B 准备好了,链路通畅,可以发送数据了。回  ACK 告知 B 收到了 B 的回复,下面要开始发送该数据了
4、d 时刻,B 收到了 A 的回复,知道 A 接下来要发数据了。至此,AB 双方都确认整个链路已经可靠了,接下来可以发送数据了。

 

为什么要多次确认呢?为什么不可以 A 上来就直接发送数据给 B 呢?
这里首先要明确一点,TCP 是传输层的协议,是建立在物理层、数据链路层、网络层之上的协议,而底层的网络是不可靠的,可能路由出问题,可能网关出问题,可能网线出问题,A 没法保证自己发出来的消息 B 一定能收到,所以一定要反馈机制,即 ACK,这样才能在不可靠的网络层智商构建可靠的传输层。

 

类比一下生活中的例子,可以帮助我们理解
示例1,假设我们在火车上打电话,通话质量很差,我们的通话过程可能会是下面这样:

tcp三次握手四次挥手详解_tcp为什么是四次挥手

AB 双方首先需要确认彼此都能挺到对方的声音,也就是保证电话通道是可靠的,之后才会开始说正事。如果一上来就直接说正事,可能 A 说完之后 B 根本就没有听到。
实际打电话过程中,如果遇到了断线的情况,双方可能需要进行多次“握手”确认。

 

示例2,假设我们给刚认识的人第一次打电话,通话过程可能是下面这样:

tcp三次握手四次挥手详解_tcp为什么是四次挥手

AB 双方都要确认对方的身份,也就是保证通话是在跟自己人进行,确保电话通道是可靠的,不是跟骗子通话,然后才会开始说正事。如果一上来没有确认身份,不能保证通道是跟自己人进行的,那直接说出重要的事,很可能就泄漏了机密。

 

总之,握手过程的最终目的就是保证双方都准备就绪,通路是可靠的,之后就可以放心的发送重要数据了。

 

那为什么一定是三次呢,为什么不是两次或者四次呢?
先来说一下为什么不能少。
一次可以吗?不可以。设想一下,A 对 B 说:我要给你发数据。然后不等 B 的回复,接下来就开始发数据了。这时候根本不能保证 B 已经准备好了,那 A 发出来的数据就没法保证 B 一定能收到。联想生活中的场景,你隔着很远的距离向对方喊话:我要把苹果扔给你。然后不关心对方有没有听到,就直接扔了,那最终的结果通常就是对方接不到苹果,因为对方可能根本没有收到消息。
两次可以吗?不可以。设想一下,A 对 B 说:我要给你发数据,然后 B 收到消息后给 A 回复:收到,A 在收到 B 的回复后开始发送数据。这时候 A 端是可以准备就绪的,但是 B 端不知道 A 端当前的状态。因为 B 在收到 A 的消息的时候,可能已经过去了很长时间,B 在回消息的时候,A 可能已经不在线了,此时 B 是不能直接发数据的。如果 A 再给 B 回一个 ACK,B 就可以确认当前链路状态了,这就变成了三次握手。

接下来说一下为什么不是四次。既然三次已经可以保证建立可靠通信,就不需要额外的一次交互了。

 

下面是几个生活中相关的示例:

tcp三次握手四次挥手详解_tcp为什么是四次挥手

tcp三次握手四次挥手详解_tcp为什么是四次挥手

tcp三次握手四次挥手详解_tcp为什么是四次挥手

tcp三次握手四次挥手详解_tcp为什么是四次挥手tcp三次握手四次挥手详解_tcp为什么是四次挥手

tcp三次握手四次挥手详解_tcp为什么是四次挥手tcp三次握手四次挥手详解_tcp为什么是四次挥手

TCP 断链四次挥手

tcp三次握手四次挥手详解_tcp为什么是四次挥手

1、a 时刻,A 向 B 发出 FIN 包,表示自己没有数据要发送了
2、b 时刻,B 收到 FIN 包,回复 FIN ACK,表示收到了 A 的 FIN 包,不会再接收 A 的数据了
3、B 在发完 FIN ACK 后,可能还有数据要发给 A,这个数据是不能停止发送的,有数据还是需要继续发送
4、d 时刻,B 发完了数据,也发出 FIN 包,告诉 A 自己的数据发完了,不再发送数据了
5、e 时刻,A 收到了 B 的 FIN 包,知道 B 也没有数据要发送了,回复 FIN ACK。此时,连接可以断开了

建连只需要交互三次,断连却需要四次,这是为什么呢?其实断开连接和建立连接还是不一样的。建连的时候,只要双方都告知对方自己准备好了就可以,但是断连的时候,一方提出要断开连接,不再发数据,另一方不能立即断开,因为这一方可能还有数据要发送,直到数据全部发送完成后才能确认断开。

 

下面是几个生活中相关的示例:

tcp三次握手四次挥手详解_tcp为什么是四次挥手

 

以上是对于三次握手、四次挥手的简单介绍,里面没有更详细的状态介绍,之后的博客会介绍,这里先放两张图。

TCP 三次握手

tcp三次握手四次挥手详解_tcp为什么是四次挥手

 

TCP 四次挥手

 

tcp三次握手四次挥手详解_tcp为什么是四次挥手

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/189183.html原文链接:https://javaforall.net

(0)
全栈程序员-站长的头像全栈程序员-站长


相关推荐

  • DNS负载均衡

    DNS负载均衡1)DNS负载均衡的介绍对于负载均衡的一个典型应用就是DNS负载均衡。庞大的网络地址和网络域名绝对是负载均衡体现优势的地方。那么它的具体原理是如何的呢?本文就将为大家详细介绍一下相关内容。DNS负载均

    2022年7月1日
    17
  • cmd下无法切换盘符[通俗易懂]

    cmd下无法切换盘符[通俗易懂]在cmd命令提示符窗口无法切换盘符?因为切换盘符不需要使用cd直接盘符加冒号就可以切换盘符

    2022年10月3日
    1
  • 天合光能与阿里云合作取得阶段性成果「建议收藏」

    天合光能与阿里云合作取得阶段性成果

    2022年3月12日
    83
  • 什么是协程_什么时候使用协程和线程

    什么是协程_什么时候使用协程和线程先搞清楚,什么是协程。你可能已经听过『进程』和『线程』这两个概念。进程就是二进制可执行文件在计算机内存里的一个运行实例,就好比你的.exe文件是个类,进程就是new出来的那个实例。进程是计算机系

    2022年8月2日
    5
  • LaTeX(4)——LaTeX插入图片「建议收藏」

    LaTeX(4)——LaTeX插入图片「建议收藏」转载请注明作者和出处:https://blog.csdn.net/qq_28810395运行平台:Windows10环境加编译器:Texlive2020+Texstudio编辑器如有需要IEEE模板文件的可以关注Stefan0704回复IEEE进行获取。前言  在Paper的排版中,对于图片的排版也是重点之一,一篇好的Paper,图片排版的不规范,直接决定了读者对Paper的第一印象,所以下面分享一下图片排版方法。排版方式图片的插入很简单呢,一般就是如下述的代码与结果所示,插入.

    2022年5月18日
    31
  • 服务器加网站防盗链,网站防盗链的设置方法介绍(适用于IIS和Apache)[通俗易懂]

    服务器加网站防盗链,网站防盗链的设置方法介绍(适用于IIS和Apache)[通俗易懂]这篇文章主要为大家详细介绍了网站防盗链的设置方法介绍(适用于IIS和Apache),具有一定的参考价值,感兴趣的小伙伴们可以参考一下,有需要的朋友可以收藏方便以后借鉴。做网站的朋友一般都会遇到这样的一种情况,就是别人的网站经常会调用我们自己网站的图片或者文件,这无形之中会增加我们的服务器的压力,尤其是对于一些服务器带宽并不是十分富裕的网站来说就更是雪上加霜。因此我们需要学会设置防盗链来应对或者说来…

    2022年7月23日
    22

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号