|
|
51CTO旗下网站
|
|
移步端
  • 三次握手+四次挥手,一文搞定所有!

    TCP 三次握手和四次挥手的题材在面试中是最为常见的突破点之一。有的是读者都晓得三次和四次,但是如果问深入一些,她们往往都无法做到准确回答。本文就来详解 TCP 联网的三次握手与四次挥手。

    笔者:AhuntSun 来源:博客园| 2020-01-09 09:31

    TCP 三次握手和四次挥手的题材在面试中是最为常见的突破点之一。有的是读者都晓得三次和四次,但是如果问深入一些,她们往往都无法做到准确回答。本文就来详解 TCP 联网的三次握手与四次挥手。


    图表来自 Pexels

    TCP Connection

    客户端与服务器之间数据的发送和返回的经过当中需要创造一个叫 TCP Connection 的东西。

    出于 TCP 不存在连接的定义,只存在请求和响应,呼吁和响应都是数据包,它们之间都是经由由 TCP 创造的一个下客户端发起,传感器接收的类似连接的大道,其一连接可以一直保持,HTTP 呼吁是在这个连接的基础上发送的。

    在一番 TCP 联网上是可以发送多个 HTTP 呼吁的,不同之本子这个模式不一样。

    在 HTTP/1.0 官方这个 TCP 联网是在 HTTP 呼吁创建的时节同步创建的,HTTP 呼吁发送到服务器端,服务器端响应了今后,其一 TCP 联网就关闭了。

    HTTP/1.1 官方得以以某种方式声明这个连接一直保持,一度请求传输完后,另一番请求可以接着传输。

    这样的功利是:在创造一个 TCP 联网的经过中要求“三次握手”的损耗,“三次握手”代表有三次网络传输。

    如果 TCP 联网保持,其次个请求发送就没有这“三次握手”的损耗。HTTP/2 官方同一个 TCP 联网里还可以并发地传输 HTTP 呼吁。

    TCP 报文格式简介

    其中比较重要的字段有:

  • 序号(sequence number):Seq 序号,占 32 位,用于标识从 TCP 源端向目的端发送的字节流,倡导方发送数据时对此进行标记。
  • 确认号(acknowledgement number):Ack 序号,占 32 位,只有 ACK 标志位为 1 时,确认序号字段才使得,Ack=Seq+1。
  • 标志位(Flags):共 6 个,即 URG、ACK、PSH、RST、SYN、FIN 等。
  • 六个标志位具体含义如下:

  • URG:紧急指针(urgent pointer)使得。
  • ACK:确认序号有效。
  • PSH:接受方应当尽快将以此报文交给应用层。
  • RST:重置连接。
  • SYN:倡导一个新连接。
  • FIN:自由一个连接。
  • 要求注意的是:

  • 不要将确认序号 Ack 与标志位中的 ACK 搞混了。
  • 确认方 Ack=倡导方 Seq+1,两岸配对。
  • TCP 的三次握手

    “三次握手”的详解

    所谓的三次握手即 TCP 联网的成立。其一连接必须是一方主动打开,另一方被动打开的。

    以下为客户端主动发起连接的图解:

    拉手之前主动打开连接的客户端结束 CLOSED 阶段,消极打开的服务器端也结束 CLOSED 阶段,并进入 LISTEN 阶段,之后开始“三次握手”。

    ①第一客户端向服务器端发送一段 TCP 报文。

    其中:标志位为 SYN,表示“呼吁建立新连接”;序号为 Seq=x(x 普通为 1);之后客户端进入 SYN-SENT 阶段。

    ②服务器端接收到来自客户端的 TCP 报文之下,结束 LISTEN 阶段。并返回一段 TCP 报文。

    其中:标志位为 SYN 和 ACK,表示“确认客户端的报文 Seq 序号有效,传感器能健康接收客户端发送的多寡,并允许创建新连接”(即告诉客户端,传感器收到了你的多寡)。

    序号为 Seq=y;确认号为 Ack=x+1,表示接受客户端的序号 Seq 并将他值加 1 表现协调确认号 Ack 的值;之后服务器端进入 SYN-RCVD 阶段。

    ③客户端接收到来自服务器端的承认收到数据的 TCP 报文之下,显然了副客户端到铁器的数据传输是健康的,结束 SYN-SENT 阶段。并返回最后一段 TCP 报文。

    其中:标志位为 ACK,表示“确认收到服务器端同意连接的信号”(即告诉服务器,我明白你收到我发的多寡了)。

    序号为 Seq=x+1,表示接受服务器端的承认号 Ack,并将他值作为协调之序号值。

    确认号为 Ack=y+1,表示接受服务器端序号 Seq,并将他值加 1 表现协调之承认号 Ack 的值;之后客户端进入 ESTABLISHED 阶段。

    传感器收到来自客户端的“确认收到服务器数据”的 TCP 报文之下,显然了副服务器到客户端的数据传输是健康的。结束 SYN-SENT 阶段,进去 ESTABLISHED 阶段。

    在客户端与服务器端传输的 TCP 报文中,两岸的承认号 Ack 和序号 Seq 的值,都是在双方 Ack 和 Seq 值的基础上进行计算的,这样做保证了 TCP 报文传输的连贯性。

    一旦出现某一方发出的 TCP 报文丢失,便无法继续"握手",这个确保了"三次握手"的胜利完成。

    后来客户端和服务器端进行例行的数据传输。这就是“三次握手”的经过。

    “三次握手”的常态过程

    “三次握手”的初步理解

    举个栗子:把客户端比作男孩,传感器比作女孩。

    用他们的来往来阐明“三次握手”经过:

  • 女性喜欢女孩,于是乎写了一封信告诉女孩:我爱你,请和我走吧!;写完信后,女性焦急地等候,因为不知晓信能否如愿传达给女孩。
  • 女性收到男孩的联名信后,心花怒放,原本我们是两情相悦呀!于是乎给男孩写了一封回信:我接受你的联名信了,也理解了你的意志,其实,我也爱不释手你!我愿和你走!
  • 写完信后,女性也急忙地等候,因为不知晓回信能否能胜利传达给男孩。

  • 女性收到回信之后很开心,因为发出的联名信女孩收到了,并且附有回信中领略了女孩喜欢自己,并且愿意和融洽走。
  • 下一场男孩又写了一封信告诉女孩:你的意志和信我都吸纳了,谢谢你,还有我爱你!

    女性收到男孩的回信之后,也很开心,因为发出的联名信男孩收到了。由此男孩女孩双方都晓得了双方的意志,后就高兴地交流起来了~~

    这就是初步版的“三次握手”,期间一共往来了三封信也就是“三次握手”,这个确认两个方向上之数据传输通道是否健康。

    为什么要开展第三次握手

    为了防止服务器端开启一些无用的过渡增加服务器开销以及防止已失效的过渡请求报文段突然又扩散给到了劳动端,故此产生错误。

    出于网络传输是有延时的(要通过网络光纤和各族中间代理服务器),在传输的经过中,比如客户端发起了 SYN=1 创造连接的呼吁(着重次握手)。

    如果服务器端就直接创建了这个连接并返回包含 SYN、ACK 和 Seq 等内容的数据包给客户端,其一数据包因为网络传输的由来丢失了,丢掉之后客户端就一直没有接到到铁器返回的数据包。

    客户端可能设置了一番超时时间,时光到了就关闭了交接创建的呼吁。

    再重新发出创建连接的呼吁,而服务器端是不知晓的,如果没有第三次握手告诉服务器端客户端收的到服务器端传输的多寡的话,服务器端是不知晓客户端有没有接收到服务器端返回的消息的。

    其一过程可知道为:

    这样没有给服务器端一个创建还是关闭连接端口的呼吁,服务器端的端口就一直开着,等到客户端因超时重新发出呼吁时,传感器就会重新开始一个端口连接。

    这就是说服务器端上没有接到到请求数据的上一度端口就一直开着,旷日持久,这样的端口多了,就会造成服务器端开销的不得了浪费。

    还有一种情景是已经失效的客户端发出的呼吁信息,出于某种原因传输到了服务器端,服务器端以为是客户端发出的得力请求,接受后产生错误。

    故此我们需要“先后三次握手”来确认这个过程,让客户端和服务器端能够及时地察觉到因为网络等部分问题导致的过渡创建失败,这样服务器端的端口就足以关闭了,无需一直等待。

    也得以这样理解:“先后三次握手”是客户端向服务器端发送数据,其一数目就是要告诉服务器,客户端有没有收到服务器“其次次握手”时传病逝的多寡。

    若发送的这个数目是“接受了”的消息,接受后服务器就正常建立 TCP 联网,否则建立 TCP 联网失败,传感器关闭连接端口。由此减少服务器开销和接受到失效请求发生之错误。

    抓包验证

    下是用抓包工具抓到的组成部分数据包,租用来分析 TCP 的三次握手:

    希冀中表现的就是完全的 TCP 联网的”三次握手”经过。在 52528→80 官方,52528 是当地(客户端)端口,80 是服务器的端口。80 端口和 52528 端口之间的三次往返就是"三次握手"经过。

    注意到“着重次握手”客户端发送的 TCP 报文中以[SYN]表现标志位,并且客户端序号 Seq=0。

    然后”其次次握手”传感器返回的 TCP 报文中以[SYN,ACK]表现标志位;并且服务器端序号 Seq=0;确认号 Ack=1(“着重次握手”官方客户端序号 Seq 的值+1)。

    说到底”先后三次握手”客户端再向服务器端发送的 TCP 报文中以[ACK]表现标志位;其中客户端序号 Seq=1(“其次次握手”官方服务器端确认号 Ack 的值);确认号 Ack=1(“其次次握手”官方服务器端序号 Seq 的值 +1)。

    这就完事了”三次握手”的经过,符合前面分析的结果。

    TCP 的四次挥手

    对于"三次握手"咱们熟悉,因为他相对的简短。但是,咱们却不常听到“四次挥手”,就算听过也未必能详细地说清楚它的切实可行过程。下就为大家详尽,宏观,完全地介绍“四次挥手”的经过。

    “四次挥手”的详解

    所谓的四次挥手即 TCP 联网的自由(解除)。联网的自由必须是一方主动释放,另一方被动释放。

    以下为客户端主动发起释放连接的图解:

    挥手之前主动释放连接的客户端结束 ESTABLISHED 阶段。之后开始“四次挥手”。

    ①第一客户端想要释放连接,向服务器端发送一段 TCP 报文。

    其中:标志位为 FIN,表示“呼吁释放连接“;序号为 Seq=U。

    之后客户端进入 FIN-WAIT-1 阶段,即半关闭阶段。并且停止在客户端到服务器端方向上发送数据,但是客户端仍然能接到从服务器端传输过来的多寡。

    瞩目:此地不发送的是健康连接时传输的多寡(非确认报文),而不是所有数据,故此客户端仍然能发送 ACK 确认报文。

    ②服务器端接收到副客户端发出的 TCP 报文之下,确认了客户端想要释放连接,之后服务器端结束 ESTABLISHED 阶段,进去 CLOSE-WAIT 阶段(半关闭状态)并返回一段 TCP 报文。

    其中:标志位为 ACK,表示“接受到客户端发送的自由连接的呼吁”。

    序号为 Seq=V,确认号为 Ack=U+1,表示是在接受客户端报文之基础上,名将他序号 Seq 值加 1 表现资本段报文确认号 Ack 的值;之后服务器端开始准备释放服务器端到客户端方向上的过渡。

    客户端收到从服务器端发出的 TCP 报文之下,确认了服务器收到了客户端发出的自由连接请求,之后客户端结束 FIN-WAIT-1 阶段,进去 FIN-WAIT-2 阶段。

    明天"两次挥手"既让服务器端知道了客户端想要释放连接,也让客户端知道了服务器端了解了上下一心想要释放连接的呼吁。于是乎,可以肯定关闭客户端到服务器端方向上的过渡了。

    ③服务器端自从发出 ACK 确认报文之下,历经 CLOSED-WAIT 阶段,搞好了释放服务器端到客户端方向上的过渡准备,再次向客户端发出一段 TCP 报文。

    其中:标志位为 FIN,ACK,表示“已经准备好释放连接了”。瞩目:此地的 ACK 并不是确认收到服务器端报文之承认报文。

    序号为 Seq=W,确认号为 Ack=U+1,表示是在接受客户端报文之基础上,名将他序号 Seq 值加 1 表现资本段报文确认号 Ack 的值。

    之后服务器端结束 CLOSE-WAIT 阶段,进去 LAST-ACK 阶段。并且停止在服务器端到客户端的方向上发送数据,但是服务器端仍然能够接受从客户端传输过来的多寡。

    ④客户端收到从服务器端发出的 TCP 报文,确认了服务器端已做好释放连接的准备,结束 FIN-WAIT-2 阶段,进去 TIME-WAIT 阶段,并向服务器端发送一段报文。

    其中:标志位为 ACK,表示“接受到铁器准备好释放连接的信号”。

    序号为 Seq=u+1;表示是在接受了服务器端报文之基础上,名将他确认号 Ack 值作为资本段报文序号的值。

    确认号为 Ack=w+1;表示是在接受了服务器端报文之基础上,名将他序号 Seq 值作为资本段报文确认号的值。之后客户端开始在 TIME-WAIT 阶段等待 2MSL。

    服务器端收到从客户端发出的 TCP 报文之下结束 LAST-ACK 阶段,进去 CLOSED 阶段。由此正式承认关闭服务器端到客户端方向上的过渡。

    客户端等待完 2MSL 后,结束 TIME-WAIT 阶段,进去 CLOSED 阶段,由此形成“四次挥手”。

    此后“两次挥手”既让客户端知道了服务器端准备好释放连接了,也让服务器端知道了客户端了解了上下一心准备好释放连接了。

    于是乎,可以肯定关闭服务器端到客户端方向上的过渡了,由此形成“四次挥手”。

    与“三次挥手”一样,在客户端与服务器端传输的 TCP 报文中,两岸的承认号 Ack 和序号 Seq 的值,都是在双方 Ack 和 Seq 值的基础上进行计算的。

    这样保证了 TCP 报文传输的连贯性,一旦出现某一方发出的 TCP 报文丢失,便无法继续"挥手",这个确保了"四次挥手"的胜利完成。

    “四次挥手”的常态过程

    “四次挥手”的初步理解

    举个栗子:把客户端比作男孩,传感器比作女孩。

    穿过他们的分别来阐明“四次挥手”经过:

  • "着重次挥手":日久见人心,女性发现女孩变成了上下一心讨厌的规范,忍无可忍,于是乎决定分手,随即写了一封信告诉女孩。
  • “其次次挥手”:女性收到信后,了解了男孩要和融洽分手,怒火中烧,衷心暗骂:你算什么东西,那时你可以是其一样子的!于是乎立马给男孩写了一封回信:离别就分别,送我点时间,我要把你的东西整理好,全方位还送你!
  • 女性收到女孩的首要封信之后,了解了女孩知道自己要和他分手。之后等待女孩把自己之东西收拾好。

  • “先后三次挥手”:过了几角,女性把男孩送的东西都收拾好了,于是乎再次写信给男孩:你的东西我整理好了,快把它们拿走,今后你我恩断义绝!
  • “先后四次挥手”:女性收到女孩第二封信之后,了解了女孩收拾好东西了,可以正式分手了,于是乎再次写信告知女孩:我明白了,这就去拿回来!
  • 此地双方都有各自的坚持:

  • 女性自发出第二封信开始,限定一角内收不到男孩回信,就会再发一封信催促男孩来取东西!
  • 女性自发出第二封信开始,限定两角内没有再次收到女孩的信就以为,女性收到了上下一心之第二封信;若两角内再次收到女孩的通信,就以为自己之第二封信女孩没收到,要求再写一封信,再等两角…..
  • 倘若双方信都能健康收到,最少只用四封信就能彻底分手!这就是“四次挥手”。

    为啥握手是三次,挥手却要四次

    TCP 确立连接时之所以只要求"三次握手",是因为在第二次"握手"经过中,服务器端发送给客户端的 TCP 报文是以 SYN 与 ACK 表现标志位的。

    SYN 是呼吁连接标志,表示服务器端同意成立连接;ACK 是确认报文,表示告诉客户端,服务器端收到了他的呼吁报文。

    即 SYN 确立连接报文与 ACK 确认接收报文是在同一次"握手"当中传输的,故此"三次握手"不多也不少,相当让双方明确彼此信息互通。

    TCP 自由连接时之所以需要“四次挥手”,鉴于 FIN 自由连接报文与 ACK 确认接收报文是分别由第二次和程序三次"握手"传输的。

    为何建立连接时一起传输,自由连接时却要分开传输?

  • 确立连接时,消极方服务器端结束 CLOSED 阶段进入“握手”阶段并不需要任何准备,可以直接返回 SYN 和 ACK 报文,起来建立连接。
  • 自由连接时,消极方服务器,突然收到主动方客户端释放连接的呼吁时并不许立即释放连接。
  • 因为还有必不可少的多寡需要处理,故此服务器先返回 ACK 确认收到报文,历经 CLOSE-WAIT 阶段准备好释放连接之后,才能返回 FIN 自由连接报文。

    故此是“三次握手”,“四次挥手”。

    为啥客户端在TIME-WAIT阶段要等2MSL

    为之是确认服务器端是否收取客户端发出的 ACK 确认报文,顶客户端发出最后的 ACK 确认报文时,并未能确定服务器端能够接受该段报文。

    故此客户端在殡葬完 ACK 确认报文之下,会设置一个时长为 2MSL 的计时器。

    MSL 指的是 Maximum Segment Lifetime:一段 TCP 报文在传输过程中的最大生命周期。

    2MSL 即是服务器端发出为 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长。

    服务器端在 1MSL 内没有收到客户端发出的 ACK 确认报文,就会再次向客户端发出 FIN 报文:

  • 如果客户端在 2MSL 内,再次收到了来自服务器端的 FIN 报文,表明服务器端由于各种原因没有接到到客户端发出的 ACK 确认报文。
  • 客户端再次向服务器端发出 ACK 确认报文,计时器重置,重新开始 2MSL 的计价。

  • 否则客户端在 2MSL 内没有再次收到来自服务器端的 FIN 报文,表明服务器端正常接收了 ACK 确认报文,客户端可以进入 CLOSED 阶段,形成“四次挥手”。
  • 故此,客户端要经历时长为 2SML 的 TIME-WAIT 阶段;这也是为什么客户端比服务器端晚进入 CLOSED 阶段的由来。

    抓包验证

    希冀中表现的就是完全的 TCP 联网释放的”四次挥手”经过。在 80→55389 官方,假设 80 是当地(客户端)端口,55389 是服务器端口。

    80 端口与 55389 之间的四次往返就是"四次挥手"经过:

  • “着重次挥手”客户端发送的 FIN 呼吁释放连接报文以[FIN,ACK]表现标志位,他中报文序号 Seq=2445;确认号 Ack=558。瞩目:此地与“先后三次握手”的 ACK 并不是表示肯定的 ACK 报文。
  • “其次次挥手”服务器端返回的 ACK 确认报文以[ACK]表现标志位;他中报文序号 Seq=558;确认号 Ack=2246。
  • “先后三次挥手”服务器端继续返回的 FIN 允许释放连接报文以[FIN,ACK]表现标志位;他中报文序号 Seq=558;确认号 Ack=2246。
  • “先后四次挥手”客户端发出的 ACK 确认接收报文以[ACK]表现标志位;他中报文序号 Seq=2446;确认号 Ack=559。
  • 此后一次“挥手”传输报文中的序号 Seq 值等于前一次"握手"传输报文中的确认号 Ack 值。

    此后一次“挥手”传输报文中的确认号 Ack 值等于前一次"握手"传输报文中的序号 Seq 值。

    故这是继续的“四次挥手”经过,与前面的剖析相符。

    【编纂推荐】

    1. 3000字讲讲TCP协和,拉手挥手不是你想的那么简单
    2. 图集:TCP/IP协和集和安全
    3. 4000字详解TCP逾期与重传,看完没收获算我输
    4. 采用Netty打电话时,赶上TCP粘包拆包问题如何解决?答案如此简单
    5. TCP 三次握手背的滚瓜乱熟,那意外情况呢?丢包了呢?故意不回答 ACK 呢?
    【义务编辑: 武晓燕 TEL:(010)68476606】

    点赞 0
  • 三次握手  四次挥手   TCP
  • 分享:
    大家都在看
    猜你喜欢
  • 订阅专栏+更多

    Python使用场景实战手册

    Python使用场景实战手册

    Python使用场景实战手册
    共3章 | KaliArch

    115人口订阅学习

    一步到位玩儿透Ansible

    一步到位玩儿透Ansible

    Ansible
    共17章 | 骏马金龙1

    182人口订阅学习

    云架构师修炼手册

    云架构师修炼手册

    云架构师之必不可少技能
    共3章 | Allen在路上

    131人口订阅学习

    读 书 +更多

    Cisco CCNA 640-801

    Cisco 640-801 Cisco® Certified Network Associate (CCNA®) Q&A with explanations Version 93.0...

    订阅51CTO邮刊

    点击这里查看样刊

    订阅51CTO邮刊

    51CTO劳务号

    51CTO官微


      <big id="93276eae"></big>