乐趣区

关于前端:TCP的三次握手和四次挥手

jiezi

目录

  • 名词解释

  • TCP 的三次握手

    • TCP 建设链接的步骤
    • TCP 的三次握手步骤
    • 思考：TCP 握手为什么不是两次 or 四次？

  • TCP 的四次挥手

    • TCP 断开链接的步骤
    • TCP 的四次挥手步骤
    • 思考：为什么断开链接的时候要多一个步骤 2 呢？
    • 思考：为什么最初客户端确认断开链接之后还要期待 2WSL 呢？
  • 面试题：TCP 为什么是 3 次握手，4 次挥手？

这是一个计算机网络中一个很热门，很根底的问题，也是面试常考的一个题，如果你会那不稀奇，如果你不会，那就会凉凉。我这里来对我学的货色做一个整顿，看完时候对这里的常识应该会很清晰。首先先来名词解释，如果遇到不清晰的名词，记得反过头来看。

名词解释

  • TCP：TCP在计算机网络模型的传输层，对应的是主机到主机的传输，为利用间通信提供能力。TCP 是一个双工协定，数据任何时候都能够双向传输，这就意味着客户端和服务端能够平等地发送、接管信息。
  • 链接 ：是传输层的概念，链接是一种传输数据的行为，是网络行为状态的记录。在传输之前，建设一个链接，就是在数据收发单方的内存中都建设一个用于保护数据传输状态的对象，外面记录了单方的IP 和端口号，状态是怎么，传输速度是如何等。
  • 双工 / 单工：
名称 概念 线路数量
单工 在任何一个时刻，如果数据只能单向发送 只需 1 条（=1）
半双工 在某个时刻数据能够向一个方向传输，也能够向另一个方向反方向传输，而且交替进行 至多 1 条（>= 1）
全双工 任何时刻数据都能够双向收发 大于 1 条（>1）
  • 握手 ：TCP 的握手目标是为了建设稳固的链接通道。
  • 挥手 ：TCP 的挥手目标是为了断开链接。
  • WSL（Maximum Segment Lifetime）：报文最大生存工夫，TCP 容许不同的实现能够设置不同的 WSL 值。
  • seq序号 ：用来标识从TCP 源端向目标端发送的字节流，发起方发送数据时对此进行标记📌。
  • ack确定序号 ：只有ACK 标记为 1 时，确认序号字段才无效，ack = seq + 1

  • 标记位：

    • SYN（Synchronization）：一个 Host被动向另一个 Host 发动连贯，申请同步。
    • ACK（Acknowledgement）：因为要放弃连贯和可靠性束缚，TCP 协定要保障每一条收回的数据必须给返回。接管方收到数据后，都须要给发送方一个响应确认序号有序。
    • RST（Reset）：重置链接
    • FIN（Finish）：一个 Host 被动断开申请，申请实现
    • PSH（Push）：一个 Host 给另一个 Host 发送数据，数据推送
    • …

TCP 的三次握手

TCP的三次握手，相对来说是一个比拟残缺的机制，旨在建设稳固的传输通道。

TCP 建设链接的步骤

上面来看一下 TCP 建设链接的 6 个步骤：

  1. 客户端发消息给服务端（SYN）
  2. 服务端筹备好进行连贯
  3. 服务端针对客户端的 （SYN） 给一个（ACK）
  4. 服务端发送一个 （SYN） 给客户端
  5. 客户端准备就绪
  6. 客户端给服务端发送一个（ACK）

其中，2 和 5 步骤是不须要进行握手的，3 和 4 是能够合并到一起的。所以尽管建设链接要 6 步然而只须要三次握手，别离是 1，3+4，6。

TCP 的三次握手步骤

上面咱们把三次握手的过程还原一下：

  • 开始客户端和服务端都处于 CLOSED 的状态，客户端发送 SYN=1 给服务端示意要求建设链接，并且发送了一个 seq 序号，这个时候客户端的状态变成SYN-SEND。
  • 服务端收到音讯返回一个 ACK=1 示意确认收到，还有 ack 确定序号，是上一个 seq 序号 +1，即x+1，还有本次的seq 序号 y，还有一个SYN=1 建设链接，这个时候服务端状态变成SYN-REVD。
  • 客户端收到音讯之后向服务端发送一个 ACK=1 示意确认收到，还有一个新的 seq 序号是 x+1，还有一个ack 确定序号是上一个 seq 序号+1，即y+1。实现之后客户端的状态编程ESTABLISHED。
  • 服务端接管到音讯之后状态也变成ESTABLISHED，链接通道建设。

简要总结就是：

  1. 客户端 -> SYN -> 服务端
  2. 客户端 <- SYN+ACK <- 服务端
  3. 客户端 -> ACK -> 服务端

思考：TCP 握手为什么不是两次 or 四次？

构想一下，如果只有两次，服务端还没有确定客户端是否筹备好了，这样是无奈稳固的进行数据传输的。如果四次，服务端依据客户端的 ACK 再给客户端回复一个ACK，没有什么很大的作用还造成资源节约，那就是很没有必要的事件了。三次正好既能够保障牢靠传输，也能够进步传输效率，

TCP 的四次挥手

TCP的挥手旨在把链接状态断开

TCP 断开链接的步骤

  1. 客户端发消息要求断开链接（FIN）。
  2. 服务端接管到申请后，会先对本人是否收到申请回应（ACK）。
  3. 服务端解决残余的事件，例如服务端还有没有发送完的音讯，服务端可能还有发送进来的音讯没有失去 ACK；也有可能服务端本人有资源要开释等。
  4. 服务端解决完本人的事件，通知客户端能够敞开链接了（FIN）。
  5. 客户端收到 FIN，解决本人实现的事件，比方客户端有发送给服务端没有收到 ACK 的申请等。
  6. 客户端解决实现本人的事件，通知服务端能够敞开（ACK）。

其中 3 和 5 是不须要进行挥手的，然而留神这里，2 和 4 是无奈合并的。所以这里须要四次挥手，别离是 1，2，4，6。

TCP 的四次挥手步骤

  • 开始客户端向服务端发送 FIN=1 要断开链接，并且发送了一个 seq 序号=u，这个时候客户端变成FIN-WAIT1。
  • 服务端接管到音讯之后，返回一个 ACK=1 确定音讯，还有 ack 确认序号，是上一个 seq 序号 +1，即u+1，还有一个新的seq 序号为v，此时服务端的状态变成CLOSE-WAIT，客户端收到音讯之后，状态会变成FIN-WAIT2。
  • 等服务端筹备好所有的货色能够敞开链接的时候，向客户端发送 ACK=1，还要发送ack 确认序号，上一个 seq 序号 +1，即u+1，还有一个新的seq 序号为w，还要发送一个FIN=1。如果有之前没有发送完的数据，会跟着这次申请一并发送给客户端。此时服务端的状态变成LASE-ACK。
  • 客户端收到音讯之后，把本人这里的货色都实现向服务端发送 ACK=1 确认音讯，还发送了 ack 确认序号，上一个 seq 序号 +1，即w+1，还有一个新的seq 序号为 u+1，而后客户端的状态就变成了TIME-WAIT，这种状态会继续2WSL，如果期待的这段时间不再收到后端的音讯，2WSL 之后会变成CLOSED。服务端接管到音讯之后，状态也变成CLOSED。

简要总结就是：

  1. 客户端 -> FIN -> 服务端
  2. 客户端 <- ACK <- 服务端
  3. 客户端 <- FIN <- 服务端
  4. 客户端 -> ACK -> 服务端

思考：为什么断开链接的时候要多一个步骤 2 呢？

因为断开链接服务端接管到 FIN 时，断开连接要解决的问题比拟多，不能间接敞开链接，这个时候如果不发送 ACK 回应说是内容收到了，客户端是无奈判断这个音讯服务端收到没有，不能让客户端在这种状况下等太久，所以应该先回复一个 ACK 报文说是收到了，你等会我这里还有事件要解决。等到服务端的事件都处理完毕了，再发送一个FIN，确定能够断开链接了。

思考：为什么最初客户端确认断开链接之后还要期待 2WSL 呢？

  • 第一用于保障客户端发送的最初一个 ACK 报文能够达到服务器，如果这个 ACK 报文失落，服务器会感觉客户端没有收到我发的申请断开报文，于是服务器就会重发一次，如果客户端在这个 2MSL 时间段内收到重传的报文，就会从新给出回应报文，还会重启 2MSL 计时器。
  • 第二是在这个 2WSL 工夫中，能够使本链接持续时间内产生的所有报文段从网络中隐没，这样新的 TCP 三次握手的时候就不会呈现旧链接中生效的申请报文。

面试题：TCP 为什么是 3 次握手，4 次挥手？

TCP在传输层，对应主机到主机的传输，为利用通信提供能力，且 TCP 是一个双工协定，为了保障单方都建设稳固而高效的数据传输，应用三次握手和四次挥手的工作机制。

三次握手的步骤是：

  1. 客户端向服务端发送 SYN 建设链接的申请（大哥，能建设链接吗？）
  2. 服务端要将 ACK+SYN 打包为一条音讯回复（老妹儿，我收到你的音讯了，能够进行链接，你收到了吗？）
  3. 客户端接管到音讯之后给服务端发送 ACK 作为回复（好嘞，走起~），这个时候数据传输通道建设。

为什么不是两次，是因为客户端不返回 ACK，那么服务端不晓得客户端有没有接管到音讯，如果是四次，依据ACK 再返回一次ACK，节约带宽且没有必要。

四次挥手的步骤是：

  1. 客户端向服务端发送 FIN 断开链接的申请(大哥，我这边货色都发完了，断开链接吧~)
  2. 服务端接管到信息，给客户端发送一个 ACK 进行回复(老妹儿？要断开链接？我晓得了，你稍等会儿啊)
  3. 服务端解决完须要解决的事件，返回 FIN 给客户端(我这边完事儿了，断开链接吧~)
  4. 客户端收到音讯，解决完本人的事件，返回 ACK 给服务端(好嘞，掰掰~)，这个时候数据传输通道断开。

为什么这里是四次，是因为断开链接服务端收到 FIN 的时候，还有一些事件要解决，须要一些工夫，这个时候不能让客户端等太久，所以先回复一个 ACK 示意音讯曾经收到了，这边有货色要解决略微等一下。等到事件解决完，再给客户端发送 FIN 批准断开链接。

其实这个很好了解，在生活中，咱们收到对方发送的一个文件或者一个视频，这个时候他们须要咱们依据内容进行回复或者点评。咱们应该先说一句内容收到了，我看看给你回复，这样不会让对方有疑难半天没有回复是没有收到还是收到了正在看。等咱们看完之后再通知对方他们要的后果。

退出移动版