526互联

TCP之三次握手四次挥手与UDP区别

发布时间 2024-01-13 18:39:08作者: 上善若泪

目录

1 TCP三次握手四次挥手

TCP 在传输之前会进行三次沟通，一般称为三次握手，传完数据断开的时候要进行四次挥手

1.1 数据包说明

1.1.1 TCP数据包

在这里插入图片描述
数据包说明:

  1. 源端口号(16 位)：它(连同源主机 IP 地址)标识源主机的一个应用进程
  2. 目的端口号(16 位)：它(连同目的主机 IP 地址)标识目的主机的一个应用进程。这两个值加上 IP 报头中的源主机 IP 地址和目的主机 IP 地址确定唯一一个 TCP 连接
  3. 顺序号seq(32 位)： 用来标识从 TCP 源端向 TCP 目的端发送的数据字节流，它表示在这个报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则TCP用顺序号对每个字节进行计数。序号是 32bit 的无符号数， 序号到达 2^32-1后又从 0 开始。 当建立一个新的连接时， SYN 标志变1，顺序号字段包含 由这个主机选择的 该连接的初始顺序号 ISN (Initial Sequence Number )
  4. 确认号 ack(32 位)： 包含发送确认的一端所期望收到的下一个顺序号。因此，确认序号应当是上次已成功收到数据字节顺序号加 1 。 只有 ACK 标志为 1 时确认序号字段才有效。
    TCP 为应用层提供全双工服务，这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据顺序号。
  5. TCP 报头长度(4 位)：给出报头中 32bit 字的数目， 它实际上指明数据从哪里开始。 需要这个值是因为任选字段的长度是可变的。这个字段占 4bit ，因此 TCP 最多有 60 字节的首部。然而，没有任选字段，正常的长度是 20字节
  6. 保留位(6 位)：保留给将来使用，目前必须置为 0 。
  7. 控制位(control flags ， 6 位)：在TCP报头中有 6 个标志比特，它们中的多个可同时被设置为 1 。依次为：
    URG ：为 1 表示紧急指针有效，为 0 则忽略紧急指针值。
    ACK ：为 1 表示确认号有效，为 0 表示报文中不包含确认信息，忽略确认号字段。
    PSH ：为 1 表示是带有 PUSH 标志的数据， 指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满。
    RST ： 用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报文段和拒绝连接请求。一般情况下，如果收到一个 RST 为 1 的报文，那么一定发生了某些问题。
    SYN ：同步序号， 为 1 表示连接请求，用于建立连接和使顺序号同步synchronize
    FIN ： 用于释放连接，为 1 表示发送方已经没有数据发送了，即关闭本方数据流。
  8. 窗口大小(16 位)：数据字节数，表示从确认号开始，本报文的源方可以接收的字节数，即源方接收窗口大小。窗口大小是一个 16bit 字段，因而窗口大小最大为 65535 字节。
  9. 校验和(16 位)：此校验和是对整个的 TCP 报文段， 包括 TCP 头部和 TCP 数据，以 16 位字进行计算所得。这是一个强制性的字段，一定是由发送端计算和存储， 并由接收端进行验证。
  10. 紧急指针(16 位)：只有当 URG 标志置 1 时紧急指针才有效。TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式
  11. 选项：最常见的可选字段是最长报文大小，又称为 MSS(Maximum Segment Size) 。每个连接方通常都在通信的第一个报文段(为建立连接而设置 SYN 标志的那个段)中指明这个选项，它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍，所以要加填充位，使得报头长度成为整字数。
  12. 数据：TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段

1.1.2 UDP数据包

在这里插入图片描述

  • 源端口号(Source Port):这个字段占据 UDP 报文头的前 16 位，通常包含发送数据报的应用程序所使用的UDP端口。接收端的应用程序利用这个字段的值作为发送响应的目的地址。这个字段是可选项，有时不会设置源端口号。没有源端口号就默认为 0 ，通常用于不需要返回消息的通信中。
  • 目标端口号(Destination Port): 表示接收端端口，字段长为 16 位。
  • 长度(Length): 该字段占据 16 位，表示 UDP 数据报长度，包含 UDP 报文头和 UDP 数据长度。因为 UDP 报文头长度是 8 个字节，所以这个值最小为 8，最大长度为 2 ^ 16 = 65535 字节（即报文长度为64K）
  • 校验和(Checksum)：UDP使用校验和来保证数据安全性，UDP 的校验和也提供了差错检测功能，差错检测用于校验报文段从源到目标主机的过程中，数据的完整性是否发生了改变

转载于：https://mp.weixin.qq.com/s/aAAZQh8r7eCsIR9GsSvauw

1.1.3 TCP和UDP差异

  • UDP 没有所谓的序列号和确认号，所以不会对数据进行确认，数据丢失后也不会进行重传，所以 UDP 是一种不可靠的协议
  • TCP具有高可靠性，确保传输数据的正确性，不出现丢失或乱序，传输数据量大，没有限制
  • TCP相对于UDP速度慢一点，效率低，而且要求系统资源较多，每个连接都会占用系统的CPU、内存等硬件资源
  • UDP速度快、操作简单、要求系统资源较少，传输数据少，理论64K
  • UDP不可靠，可能会出现丢包、乱序、数据不完整

1.1.4 TCP可靠性传输机制

为了保持 TCP 的可靠性传输，TCP 协议采用了以下机制：

  • 序号与确认机制：TCP 使用序号 (sequence number)来对数据进行编号，并使用确认（acknowledgment）来确认接收到的数据。发送方将每个数据段分配一个序号，接收方通过发送确认消息来告知发送方已成功接收到数据。如果发送方在一定时间内没有收到确认消息，就会重新发送数据。
  • 数据段校验和：TCP 使用校验和(checksum)来检测数据在传输过程中是否发生了错误。发送方在发送数据前计算校验和，并将其附加到数据段中。接收方在接收到数据后也会计算校验和，并与发送方发送的校验和进行比对。如果校验和不匹配，则表明数据在传输过程中发生了错误，接收方会要求发送方重新发送数据。
  • 确认重传机制：如果发送方在一定时间内没有收到确认消息，就会认为数据丢失，并重新发送数据。接收方在收到重复的数据时会丢弃重复的数据，只发送一个确认消息，以避免重复处理。
  • 滑动窗口机制：TCP 使用滑动窗口（sliding window）机制来控制发送方和接收方之间的数据流量。发送方将数据分成多个数据段，并将其发送给接收方。接收方使用滑动窗口来控制可以接收的数据量。滑动窗口的大小可以根据网络状况动态调整，以确保数据的可靠传输。
  • 流量控制：TCP 使用流量控制机制来避免发送方发送过多的数据，导致接收方无法处理。接收方可以通过发送窗口大小告诉发送方可以接收的数据量。发送方需要根据接收方的窗口大小来控制发送的数据量，以避免数据的拥塞和丢失。
  • 拥塞控制：TCP 使用拥塞控制机制来避免网络拥塞。发送方根据网络状况动态调整发送速率，以避免发送过多的数据导致网络拥塞。TCP 使用拥塞窗口 (congestion window)来控制发送方的发送速率。拥塞窗口的大小可以根据网络状况动态调整，以确保网络的稳定性和可靠性。
  • 最大消息长度：为了防止因数据包过大而导致传输错误，TCP设定了最大消息长度的限制

1.2 三次握手

1.2.1 三次握手定义

客户端向服务器发送建立连接请求
在这里插入图片描述
一开始，客户端和服务端都处于 CLOSE 状态。先是服务端主动监听某个端口，处于 LISTEN 状态

  1. 第一次握手：主机 A 发送位码为 syn＝1,随机产生 seq number=1234567 的数据包到服务器，主机 B 由 SYN=1 知道， A 要求建立联机；该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。
    在这里插入图片描述

  2. 第二次握手：主 机 B 收 到 请 求 后 要 确 认 联 机 信 息 ， 向 A 发 送 ack number=( 主 机 A 的seq+1),SYN=1,ACK=1,随机产生 seq=7654321 的包，把 TCP 首部的确认应答号，把 SYN 和 ACK 标志位置为 1，最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。
    在这里插入图片描述

  3. 第三次握手： 主机 A 收到后检查 ack number 是否正确，即第一次发送的 seq number+1,以及位码ACK 是否为 1，若正确， 主机 A 会再发送 ack number=(主机 B 的 seq+1),ACK=1，主机 B 收到后确认seq 值与 ACK=1 则连接建立成功。最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于 ESTABLISHED 状态。
    在这里插入图片描述
    最后，服务端收到客户端的应答报文后，也进入 ESTABLISHED 状态

1.2.2 三次握手问题

1.2.2.1 问题引入分析

概括起来，是这两个问题：

  • 问：TCP三次握手中，客户端收到的第二次握手中 ack 确认号不是自己期望的，会发生什么？是直接丢弃 or 回 RST 报文？
    答：回 RST 报文
  • 问：什么情况下会收到不正确的 ack（第二次握手中的 ack） 呢
    答：当客户端发起多次 SYN 报文，然后网络拥堵的情况下，旧的 SYN 报文比新的 SYN 报文早抵达服务端，此时服务端就会按照收到的旧的 SYN 报文回复 syn+ack 报文，而此报文的确认号并不是客户端期望收到的，于是客户端就会回 RST 报文

假如 TCP三次握手中，客户端收到的第二次握手中 ack 确认号不是自己期望的过程如下：
在这里插入图片描述
当客户端连续发送多次建立连接的 SYN 报文，然后在网络拥堵的情况，就会发生客户端收到不正确的 ack 的情况。具体过程如下：

  • 客户端先发送了 SYN（seq = 90） 报文，但是被网络阻塞了，服务端并没有收到，接着客户端又重新发送了 SYN（seq = 100）报文，注意不是重传 SYN，重传的 SYN 的序列号是一样的。
  • 旧 SYN 报文比最新的 SYN 报文早到达了服务端，那么此时服务端就会回一个 SYN + ACK 报文给客户端，此报文的确认号是 91（90+1）。
  • 客户端收到后，发行自己期望收到的确认号应该是 100+1，而不是 90 + 1，于是就会回 RST 报文。
  • 服务端收到 RST 报文后，就会中止连接。
  • 后续最新的 SYN 抵达了服务端后，客户端与服务端就可以正常的完成三次握手了。

上述中的旧 SYN 报文称为历史连接，TCP 使用三次握手建立连接的最主要原因就是防止历史连接初始化了连接。

1.2.2.2 历史连接

如果是两次握手连接，就无法阻止历史连接，那为什么TCP 两次握手为什么无法阻止历史连接呢？
先说结论，主要是因为在两次握手的情况下，被动发起方没有中间状态给主动发起方来阻止历史连接，导致被动发起方可能建立一个历史连接，造成资源浪费。

假如在两次握手的情况下，被动发起方在收到 SYN 报文后，就进入 ESTABLISHED 状态，意味着这时可以给对方发送数据给，但是主动发起方此时还没有进入 ESTABLISHED 状态，假设这次是历史连接，主动发起方判断到此次连接为历史连接，那么就会回 RST 报文来断开连接，而被动发起方在第一次握手的时候就进入 ESTABLISHED 状态，所以它可以发送数据的，但是它并不知道这个是历史连接，它只有在收到 RST 报文后，才会断开连接。
在这里插入图片描述

可以看到，上面这种场景下，被动发起方在向主动发起方发送数据前，并没有阻止掉历史连接，导致被动发起方建立了一个历史连接，又白白发送了数据，妥妥地浪费了被动发起方的资源。
因此，要解决这种现象，最好就是在被动发起方发送数据前，也就是建立连接之前，要阻止掉历史连接，这样就不会造成资源浪费，而要实现这个功能，就需要三次握手。

1.2.2.3 同步双方初始序列号

TCP 协议的通信双方， 都必须维护一个序列号， 序列号是可靠传输的一个关键因素，它的作用：

  • 接收方可以去除重复的数据；
  • 接收方可以根据数据包的序列号按序接收；
  • 可以标识发送出去的数据包中， 哪些是已经被对方收到的（通过 ACK 报文中的序列号知道）；

可见，序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带初始序列号的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送初始序列号给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
在这里插入图片描述

四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了 三次握手
而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。

1.2.2.4 避免资源浪费

如果只有两次握手，当客户端发生的 SYN 报文在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务端不清楚客户端是否收到了自己回复的 ACK 报文，所以服务端每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？

如果客户端发送的 SYN 报文在网络中阻塞了，重复发送多次 SYN 报文，那么服务端在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。
在这里插入图片描述

两次握手会造成资源浪费
即两次握手会造成消息滞留情况下，服务端重复接受无用的连接请求 SYN 报文，而造成重复分配资源。

1.3 四次挥手

TCP 建立连接要进行三次握手，而断开连接要进行四次。这是由于 TCP 的半关闭造成的。因为 TCP 连接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭。这个单方向的关闭就叫半关闭。当一方完成它的数据发送任务，就发送一个 FIN 来向另一方通告将要终止这个方向的连接

首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭
在这里插入图片描述

  1. 关闭客户端到服务器的连接：首先客户端 A 发送一个 FIN，用来关闭客户到服务器的数据传送，然后等待服务器的确认。其中终止标志位 FIN=1，序列号 seq=u
  2. 服务器收到这个 FIN，它发回一个 ACK，确认号 ack 为收到的序号加 1
  3. 关闭服务器到客户端的连接：也是发送一个 FIN 给客户端。
  4. 客户段收到 FIN 后，并发回一个 ACK 报文确认，并将确认序号 seq 设置为收到序号加 1

主机 A 发送 FIN 后，进入终止等待状态， 服务器 B 收到主机 A 连接释放报文段后，就立即给主机 A 发送确认，然后服务器 B 就进入 close-wait 状态，此时 TCP 服务器进程就通知高层应用进程，因而从 A 到 B 的连接就释放了。此时是半关闭状态。即 A 不可以发送给B，但是 B 可以发送给 A。此时，若 B 没有数据报要发送给 A 了，其应用进程就通知 TCP 释放连接，然后发送给 A 连接释放报文段，并等待确认。 A 发送确认后，进入 time-wait

注意，此时 TCP 连接还没有释放掉，然后经过时间等待计时器设置的 2MSL 后， A 才进入到close状态
在四次挥手期间，服务端不接收报文而发送RST报文给客户端，客户端收到RST报文会报错(NoHttpResponseException)