计算机网络(11)和流量控制补充

这一篇对数据链路层中的和流量控制进行详细学习

流量控制(Flow Control)是计算机网络中确保数据流平稳传输的技术,旨在防止数据发送方发送过多数据,导致接收方的缓冲区溢出,进而造成数据丢失或传输失败。流量控制通常通过调整发送方的数据发送速率,确保接收方能有效地处理和存储接收到的数据。

流量控制的目的:

  1. 防止缓冲区溢出:接收方的缓冲区有限,若发送方发送数据过快,接收方无法及时处理,可能会导致缓冲区溢出,造成数据丢失。
  2. 提高传输效率:通过合适的流量控制机制,避免过快或过慢的数据流动,从而实现高效、可靠的数据传输。
  3. 动态调整发送速度:根据网络状态和接收方的处理能力,动态地调整发送方的发送速率,确保数据传输的平稳性。

流量控制的类型

流量控制有多种方法,主要可以分为两类:端到端流量控制 (End-to-End Flow Control)和链路层流量控制(Link-Level Flow Control)。

1. 端到端流量控制

端到端流量控制是在源设备和目标设备之间实现的流量控制。常见的协议有:

  • TCP流量控制(基于滑动窗口机制)

    TCP(传输控制协议)是端到端流量控制的典型例子。TCP流量控制的核心机制是滑动窗口,即接收方通过控制窗口大小(Window Size)来限制发送方可以发送的数据量。

    • 窗口大小:表示接收方的缓冲区能够接收的最大字节数。

    • 滑动窗口机制:发送方根据接收方的窗口大小控制发送数据的量。每次接收到确认(ACK)后,窗口会"滑动"并更新,允许发送更多的数据。

    • 发送方操作:当发送方发送数据时,它会根据接收到的窗口大小决定可以发送的数据量。发送的数据量不能超过接收方指定的窗口大小。

    • 接收方操作:接收方会告知发送方当前窗口的大小,并根据自身的缓冲区状态来动态调整该窗口大小。

    例子: 如果接收方的缓冲区有1000字节的可用空间,那么它会通过ACK报文告知发送方,发送方此时最多可以发送1000字节的数据。一旦接收方处理完这些数据,它会更新窗口大小,允许发送更多的数据。

2. 链路层流量控制

链路层流量控制是指在数据链路层(如以太网、PPP等)实现的流量控制。它主要用于控制相邻设备之间的数据传输速率。常见的链路层流量控制方法包括:

  • 基于停止-等待协议(Stop-and-Wait):这种方法要求发送方每发送一帧数据后,都等待接收方的确认信号(ACK)才可以发送下一帧。这种方法在低速网络中比较常见,适合简单的流量控制。

  • XON/XOFF协议:这是一种基于字符的流量控制协议,通常用于串行通信中。发送方通过发送XOFF(停止发送)或XON(恢复发送)字符来控制数据的发送。接收方当接收到XOFF字符时会停止接收数据,直到接收到XON字符才恢复接收。

3. 拥塞控制与流量控制的区别

流量控制和拥塞控制是两个不同的概念,虽然它们在目的上有所重叠,但有不同的实现方式:

  • 流量控制:是确保数据发送速率与接收方处理能力相匹配,避免接收方的缓冲区溢出。
  • 拥塞控制:是防止网络中出现过多的数据流导致网络节点(如路由器)过载,并且确保网络的整体流量不会超出其承载能力。

流量控制的常见方法

  1. 滑动窗口机制(Sliding Window):主要用于TCP协议。接收方通过指示一个窗口大小,发送方根据窗口大小限制其发送的数据量。随着接收方确认数据,窗口会滑动,允许发送更多数据。

  2. 停止-等待协议(Stop-and-Wait):一种简单的流量控制方法。发送方每发送一个数据帧都必须等待接收方的确认(ACK)才能发送下一个数据帧。这种方法效率较低,但适用于低带宽和低延迟的环境。

  3. XON/XOFF协议:一种字符级的流量控制协议,广泛用于串行通信和基于流的协议(如Telnet)。发送方通过发送XON字符(恢复发送)和XOFF字符(停止发送)来控制数据流。

  4. 基于令牌的流量控制(Token-based Flow Control):在这种方式下,发送方必须获得一个"令牌"才能发送数据。令牌的控制方式确保了数据的流量不会过大,通常用于分布式系统和多路复用技术中。

  5. 缓冲区管理:接收方会为每个连接分配一个缓冲区,并根据缓冲区的空闲情况通知发送方适当的发送速率。通常,接收方通过滑动窗口或发送窗口大小来进行流量控制。

流量控制的应用场景

  • 高带宽、低延迟网络:如光纤网络、卫星通信,流量控制帮助调整发送方的速率以防止接收方的缓冲区溢出。
  • 实时传输:例如,视频流和语音通话等应用需要非常精细的流量控制,确保数据流的平稳,避免丢包或时延过高。
  • 有限资源的网络:如低功耗的物联网设备(IoT)中,流量控制帮助节省带宽和减少功耗。

二.流量控制协议:

流量控制协议可以根据通信信道的噪声情况分为两类:无噪声信道和有噪声信道。不同的信道噪声情况会影响流量控制的实现方式。

1. 无噪声信道(Noiseless Channel)

在无噪声信道中,假设传输过程中不会出现数据错误和丢包的情况。由于信道质量好,流量控制的重点在于协调发送方和接收方的速度,而不是数据的重传和纠错。无噪声信道的流量控制协议通常较为简单,高效性较强。

  • 典型协议
    • 停止-等待协议(Stop-and-Wait Protocol):发送方每次发送一个数据帧,然后等待接收方的确认(ACK)。在无噪声信道中,接收方总是能收到正确的数据帧,因此只需在每次数据发送后等待确认即可。

2. 有噪声信道(Noisy Channel)

在有噪声信道中,数据可能因传输错误或干扰而发生丢失或损坏。流量控制协议在解决速率匹配问题的同时,还需要处理错误控制,确保接收方接收到的都是正确的数据帧。

  • 典型协议
    • 停止-等待ARQ(Stop-and-Wait Automatic Repeat Request):这是带自动重传请求的停止-等待协议。在数据帧丢失或损坏时,接收方不会发送确认(ACK),从而触发发送方的重传。发送方会在超时后重发数据,以保证数据的可靠到达。

回退N帧ARQ和选择重传ARQ都是属于滑动窗口协议:

    • 回退N帧ARQ(Go Back-N ARQ):发送方可以连续发送多个帧,但如果检测到某一帧出错,接收方会丢弃之后所有的帧发送发需从错误帧开始重新传输
    • 选择重传ARQ,发送方也可以连续发送多帧数据,但当某一帧出错时,接收方只请求重传出错的帧,而不是全部重传。

停等协议(Stop-and-Wait ARQ)详解

停等协议(Stop-and-Wait ARQ) 是一种最简单的自动重传请求(ARQ)协议,用于在数据链路层实现可靠的数据传输。该协议通过确认每一帧的接收情况来确保数据的正确传递。当发送方发送一帧数据后,它会等待接收方的确认(ACK)信号,直到收到确认才会发送下一帧。此过程每次仅传输一帧数据,因此称为"停等"。

工作原理

  1. 发送方操作

    • 发送方发送一帧数据(称为数据帧)给接收方。
    • 发送方停下,等待接收方发送一个确认帧(ACK)来确认数据帧的接收。
    • 一旦收到确认帧(ACK),发送方继续发送下一帧数据。
    • 如果在超时之前没有收到确认帧(ACK),则发送方会重新发送当前数据帧。
  2. 接收方操作

    • 接收方接收到数据帧后,如果数据正确无误,就返回一个确认帧(ACK)给发送方。
    • 如果接收方检测到数据帧有错误(如校验错误),它将丢弃该数据帧,并不会发送确认帧。发送方会在超时后重新发送该数据帧。
  3. 超时与重传

    • 在发送数据帧后,发送方会启动一个定时器。如果在定时器到期前未收到确认帧,发送方会重传该数据帧。
    • 定时器的长度必须设置合理,以避免过早的重传或延迟过长的重传。

停等协议的流程示意

  1. 发送方 发送数据帧 Data1接收方
  2. 接收方 正确接收 Data1 后,发送确认帧 ACK1 回到 发送方
  3. 发送方 收到 ACK1 后,继续发送下一帧 Data2
  4. 如果 接收方 在接收数据帧时发现错误(如 CRC 错误),则丢弃该帧,并不发送确认帧。发送方 将等待超时并重新发送该帧。

停等协议的优缺点

优点:
  1. 实现简单:停等协议的实现相对简单,发送方只需要发送一帧数据并等待确认,接收方只需返回一个确认帧。
  2. 保证可靠性:通过等待确认和重传机制,停等协议可以保证数据的可靠传输,即使在存在传输错误的情况下,也能确保数据最终被正确传递。
  3. 适用于低误码率的环境:在误码率较低或网络延迟较小的情况下,停等协议可以有效地完成数据传输。
缺点:
  1. 效率低 :由于每次只能发送一帧数据,且发送方必须等待确认才能继续发送下一帧,因此其带宽利用率较低。每传输一帧数据都需要等待确认,因此长时间的等待会影响效率。

  2. 延迟较高:每帧数据的确认都需要等待往返时间(RTT)。在高延迟的网络中,停等协议的效率会显著下降,尤其是在长距离传输中。

  3. 带宽利用不充分:停等协议每次只发送一帧数据,导致网络带宽的使用不充分,尤其在传输速率较高时,带宽的浪费尤为明显。

适用场景

  1. 低速率或低误码的环境:在网络延迟较低、传输速率较低或错误率较低的场景下,停等协议能够以简单高效的方式提供可靠的数据传输。

  2. 资源受限的系统:在一些资源受限的系统(如简单的嵌入式系统)中,停等协议由于其实现简单,往往是最适合的选择。

  3. 信道质量好的情况:如果信道的误码率很低,且丢包率也较低,停等协议能够提供较为可靠的服务。

停等协议的例子

假设发送方和接收方之间存在一个简单的通信链路,数据帧由8位的二进制数据构成。

  1. 发送方 :发送方传输的数据帧为 10101010,并等待接收方的确认。
  2. 接收方 :接收方正确接收到数据帧后,返回一个确认帧 ACK,告诉发送方已成功接收到数据。
  3. 如果接收方在收到数据时发现错误,例如数据帧为 10101001,它将丢弃该数据帧,不返回确认帧。发送方超时后会重新发送数据帧。

回退N帧 ARQ(Go-Back-N ARQ)详解

回退N帧 ARQ(Go-Back-N ARQ) 是一种自动重传请求(ARQ)协议,它用于在数据链路层实现可靠的数据传输。与 停等协议(Stop-and-Wait ARQ) 不同,回退N帧 ARQ 允许发送方一次发送多帧数据(最多为 N 帧),但接收方只按顺序确认接收到的帧。

工作原理

  1. 发送方操作

    • 发送方可以在等待确认之前连续发送多帧数据。它会为每一帧数据分配一个序列号(通常是一个循环的序列号,范围从 0 到 N-1),并将数据帧发送到接收方。
    • 发送方维护一个发送窗口,窗口大小为 N。窗口内的帧可以同时发送。
    • 每发送一帧数据,发送方启动一个定时器,并等待该帧的确认(ACK)。如果超时未收到确认,发送方将重新发送当前帧以及所有后续帧(即回退 N 帧)。
  2. 接收方操作

    • 接收方按顺序接收数据帧。当接收方正确接收到数据帧时,它会向发送方发送一个 累积确认帧(Cumulative ACK),该确认帧表示接收到的数据帧的最大序列号。
    • 如果接收方收到的帧的序列号不连续(即前面的帧丢失或错误),接收方会丢弃当前帧并不会向发送方发送确认,直到接收到缺失的帧。
  3. 超时与重传

    • 如果发送方在等待确认期间超时,它会重新发送从当前未确认帧开始的所有后续帧。这是所谓的"回退"操作,因为发送方会回到最后一个确认帧之后的所有帧并重发。
    • 重传时,所有未被确认的帧都需要重新发送,而不仅仅是丢失或错误的帧。

回退N帧 ARQ 的工作示意图

假设窗口大小为 N = 4,发送方和接收方按以下步骤工作:

  1. 发送方 发送帧 0, 1, 2, 3,并为每个帧设置定时器。
  2. 接收方 正确接收到帧 0, 1,然后返回一个确认帧 ACK 1,表示帧 01 已经被成功接收。
  3. 发送方 接收到 ACK 1 后,滑动窗口,并发送新的帧 4567
  4. 如果 接收方 错误地接收到帧 4,它会丢弃该帧并不发送任何确认帧。直到它收到帧 3 后,才会返回一个确认帧 ACK 3
  5. 发送方 在超时后会重新发送帧 4567,直到接收到正确的确认。

回退N帧 ARQ 例子

假设发送方的窗口大小为 N = 4 ,接收方正确接收到的数据帧序列为 0, 1, 2, 3, 4, 5, 6, 7,并且窗口序列号范围从 03

场景 1:正常数据传输
  1. 发送方 发送数据帧 0, 1, 2, 3(窗口大小为4)。
  2. 接收方 接收到帧 0, 1,并发送 ACK 1(表示帧 01 已经成功接收)。
  3. 发送方 收到 ACK 1 后,发送新的帧 4, 5, 6, 7,同时滑动窗口。
  4. 接收方 确认收到所有数据帧,直到 7
  5. 发送方 接收到 ACK 7,数据传输完成。
场景 2:丢帧重传

假设窗口大小仍为 N = 4 ,但 接收方 丢失了帧 4

  1. 发送方 发送数据帧 0, 1, 2, 34, 5, 6, 7
  2. 接收方 确认接收到 0, 1, 2, 3,并发送 ACK 3,但帧 4 被丢失。
  3. 发送方 收到 ACK 3 后,继续发送新的帧 4, 5, 6, 7,直到超时。
  4. 在超时后,发送方 会重发 所有未确认的帧 ,即帧 4, 5, 6, 7
  5. 接收方 在接收到帧 4, 5, 6, 7 后,返回 ACK 7,完成数据传输。

回退N帧 ARQ 的优缺点

优点:
  1. 提高效率:相比于停等协议(Stop-and-Wait ARQ),回退N帧 ARQ 允许在等待确认的同时发送多帧数据,从而提高了传输效率。
  2. 适应较长延迟的网络:回退N帧 ARQ 允许发送方在等待确认期间发送更多的帧,因此减少了等待时间,提高了数据传输速率。
缺点:
  1. 重传的开销较大:当某一帧丢失或出错时,发送方不仅需要重传丢失的帧,还需要重传所有后续帧。这导致了带宽的浪费,尤其是在丢失的数据帧较少的情况下。
  2. 窗口大小的限制:回退N帧 ARQ 的效率与窗口大小密切相关,窗口太小会导致效率低,窗口太大会增加发送方和接收方的负担,因此需要根据具体网络环境来调整窗口大小。

选择重传 ARQ(Selective Repeat ARQ)详解

选择重传 ARQ(Selective Repeat ARQ) 是一种自动重传请求(ARQ)协议,旨在提供高效的可靠数据传输,尤其是在不稳定的网络环境中。与 回退N帧 ARQ(Go-Back-N ARQ) 相比,选择重传 ARQ 更加高效,它允许发送方和接收方仅重传那些丢失或损坏的帧,而不是回退所有后续帧。

工作原理

  1. 发送方操作
    • 窗口大小 :发送方一次可以发送多个数据帧,但它们的数量受发送窗口大小(N)的限制。每个帧都有一个唯一的序列号。
    • 连续发送数据帧:发送方可以连续发送多个数据帧,直到达到窗口大小为止,但不会等待确认。
    • 定时器:每个帧在发送时都会启动一个定时器,超时未收到确认时才会重传。
  2. 接收方操作
    • 接收确认(ACK):接收方会对接收到的帧进行确认,单个帧的确认不会影响其他帧的确认。接收方会对每个正确接收到的帧发送一个独立的确认。
    • 乱序接收:接收方可以接收到乱序的数据帧(即某些帧丢失或错误)。如果接收方接收到的数据帧有缺失,它会缓存这些乱序帧,并等待缺失的帧到达。
    • 确认机制 :接收方向发送方发送 选择性确认(Selective ACK)。只有那些成功接收到并顺序的帧才会被确认。
  3. 超时与重传
    • 超时重传:如果发送方未收到帧的确认,它会重传该帧,而不是回退所有后续帧。
    • 仅重传丢失或损坏的帧:在选择重传 ARQ 中,发送方和接收方仅会重传那些丢失或损坏的帧,而不是所有的帧。因此,减少了带宽浪费。

选择重传 ARQ 的工作示意图

假设发送方的窗口大小为 N = 4,接收方可以接收到乱序的数据帧,具体过程如下:

  1. 发送方 发送数据帧 0, 1, 2, 3,并为每个帧设置定时器。
  2. 接收方 正确接收到帧 0, 2,并返回确认 ACK 0ACK 2(表示接收到的最大序列号)。
  3. 发送方 收到 ACK 0ACK 2 后,继续发送新的帧 4, 5, 6
  4. 如果 接收方 错误地接收到帧 1,它会请求重新发送帧 1。发送方仅重传帧 1,而不必重新发送帧 2, 3

选择重传 ARQ 的特点

  1. 发送窗口与接收窗口

    • 发送窗口:与回退N帧 ARQ 相同,发送窗口是由发送方控制的,窗口大小为 N,发送方可以一次发送 N 个数据帧。
    • 接收窗口:与回退N帧 ARQ 不同,接收方也有一个接收窗口,允许接收方缓存顺序错乱的数据帧。
  2. 独立确认

    • 每个数据帧都会单独确认,接收方即使接收到乱序帧,也会缓存它们并发送针对这些帧的确认。
    • 发送方只需要重传丢失或错误的帧,而不是重传所有后续帧
  3. 缓存机制

    • 接收方可以缓存那些按顺序接收的数据帧,同时缓存未按顺序接收的数据帧,等待丢失的帧到达后按顺序交付给上层。
  4. 减少带宽浪费

    • 选择重传 ARQ 通过只重传丢失或损坏的帧而不是整个窗口的帧,减少了重传的带宽开销,尤其是在丢失帧较少时。

选择重传 ARQ 的优缺点

优点:
  1. 高效的带宽利用:相比回退N帧 ARQ,选择重传 ARQ 仅重传丢失或损坏的帧,减少了不必要的重传,从而提高了带宽利用率。
  2. 支持乱序接收:接收方可以接收乱序帧,并在收到丢失的帧后将这些乱序帧按顺序交付给上层,提高了数据传输的灵活性。
  3. 适用于高延迟和高丢包率的网络:在丢包较高或者网络延迟较大的环境中,选择重传 ARQ 可以减少因丢包导致的频繁重传,优化了传输性能。
缺点:
  1. 复杂度较高:由于需要缓存乱序数据帧并进行选择性确认,选择重传 ARQ 的实现比回退N帧 ARQ 要复杂。
  2. 接收方缓存开销:接收方需要有足够的缓存来存储乱序到达的数据帧。如果缓存不够,接收方可能无法正确接收数据。
  3. 传输延迟增加:由于发送方与接收方需要等待更多的确认,选择重传 ARQ 可能会增加传输延迟,尤其是在高延迟网络环境中。

选择重传 ARQ 的例子

假设发送方的窗口大小为 N = 4,接收方可以乱序接收帧,且每个帧都通过独立确认:

  1. 发送方 发送数据帧 0, 1, 2, 3
  2. 接收方 正确接收到帧 0, 2,并返回确认 ACK 0ACK 2
  3. 发送方 继续发送新的帧 4, 5, 6
  4. 接收方 收到帧 1 后,确认 ACK 1
  5. 如果接收方有丢失的帧,发送方仅重传丢失的帧,避免重传所有帧。

滑动窗口协议(Sliding Window Protocol)详解

滑动窗口协议是一种用于可靠数据传输的协议,广泛应用于数据链路层和传输层。它通过使用一个"窗口"来控制数据的流动,实现流量控制和保证数据的可靠性。滑动窗口协议既可以用于全双工通信,也可以用于半双工通信。其核心思想是允许发送方在未接收到确认的情况下,连续发送多个数据帧,而接收方则按顺序接收这些数据帧并发送确认。

基本概念

在滑动窗口协议中,发送方和接收方都维护一个窗口。这个窗口在数据传输过程中"滑动",允许在发送方与接收方之间并行传输多个数据包。窗口的大小(称为窗口大小)决定了发送方可以发送多少个未确认的数据包。

滑动窗口协议的组成部分

  1. 发送方窗口(Sender Window):发送方窗口控制发送方可以同时发送多少个未确认的数据包。窗口的大小通常是由协议中的流量控制机制决定的。

  2. 接收方窗口(Receiver Window):接收方窗口控制接收方可以接收多少个数据包。它确保接收方能按照顺序接收并处理数据。

  3. 序列号:每个数据包都被赋予一个唯一的序列号,用于区分不同的数据包。

  4. 确认(ACK):接收方确认已成功接收数据包,通常使用累计确认(Cumulative ACK)方式,即确认某一序列号及之前所有数据包。

  5. 滑动窗口机制:随着数据包的确认,发送方和接收方的窗口向前滑动,从而使新的数据包进入窗口进行发送或接收。

滑动窗口协议的工作原理

  1. 初始化阶段

    • 发送方和接收方初始化各自的窗口。假设窗口大小为 N,那么发送方可以在没有等待确认的情况下连续发送 N 个数据包。
  2. 数据传输阶段

    • 发送方通过滑动窗口机制发送多个数据包。发送方发送的每个数据包都会带有一个序列号,发送方在发送数据时不会等待每个数据包的确认,而是可以连续发送多个数据包。
    • 接收方接收到数据包后,会根据序列号对数据包进行排序,并按顺序进行处理。
    • 接收方对每个成功接收到的数据包发送确认(ACK)。一般情况下,接收方会发送累计确认(即确认最后一个按顺序接收到的数据包),表示所有之前的数据包都已正确接收。
  3. 窗口滑动

    • 一旦发送方接收到接收方的确认,它就可以"滑动"窗口,将窗口向前移动,继续发送新的数据包。
    • 接收方接收到确认时,也会滑动其接收窗口,准备接收新的数据包。

滑动窗口的两种类型

  1. Go-Back-N ARQ(回退N帧 ARQ):

    • 在回退N帧 ARQ 协议中,发送方可以连续发送多个数据帧,但接收方必须按顺序接收。如果接收方发现丢失或损坏的数据帧,它会丢弃该帧,并要求发送方重新发送所有之后的帧。
    • 发送方窗口的大小为 N,接收方只允许按顺序接收数据帧。
  2. Selective Repeat ARQ(选择重传 ARQ):

    • 在选择重传 ARQ 协议中,发送方可以连续发送多个数据帧,接收方按顺序接收,并对每个接收到的数据帧进行单独确认。
    • 发送方仅重传丢失或损坏的数据帧,而不是所有帧。这比回退N帧 ARQ 更加高效。

滑动窗口协议的优缺点

优点
  1. 高效的数据传输:通过允许发送多个数据包而不等待确认,滑动窗口协议减少了传输延迟。
  2. 流量控制:发送方和接收方可以通过调整窗口大小来控制数据流量,防止接收方因缓存溢出而丢失数据。
  3. 容错能力强:尤其在选择重传 ARQ 协议中,丢失的帧仅需要重传,减少了带宽的浪费。
缺点
  1. 复杂度较高:相比于简单的停止等待协议,滑动窗口协议的实现较为复杂,尤其是在接收方需要缓存和排序帧的情况下。
  2. 延迟较大:在高延迟的网络中,滑动窗口协议的效果可能受到影响,因为窗口的滑动需要依赖于数据包的确认。
  3. 窗口管理:对于发送方和接收方来说,维护一个大的窗口可能会导致内存开销较大,尤其是在大量数据传输的情况下。

应用场景

  1. 高带宽延迟产品(BDP)环境:滑动窗口协议尤其适合用于高带宽和高延迟的网络环境,例如卫星网络、长途光纤连接等。
  2. TCP协议 :滑动窗口协议是 TCP协议 的核心部分。TCP通过滑动窗口实现流量控制,并保证数据可靠传输。
  3. 实时应用:比如视频流、音频流等实时应用,也可以采用滑动窗口机制,以保证流畅的传输。
相关推荐
正在走向自律6 分钟前
阿里云ESC服务器一次性全部迁移到另一个ESC
服务器·阿里云·云计算
gywl31 分钟前
openEuler VM虚拟机操作(期末考试)
linux·服务器·网络·windows·http·centos
WTT00111 小时前
2024楚慧杯WP
大数据·运维·网络·安全·web安全·ctf
了一li2 小时前
Qt中的QProcess与Boost.Interprocess:实现多进程编程
服务器·数据库·qt
杨德杰2 小时前
QT网络(一):主机信息查询
网络·qt
日记跟新中2 小时前
Ubuntu20.04 修改root密码
linux·运维·服务器
唐小旭2 小时前
服务器建立-错误:pyenv环境建立后python版本不对
运维·服务器·python
明 庭2 小时前
Ubuntu下通过Docker部署NGINX服务器
服务器·ubuntu·docker
BUG 4042 小时前
Linux——Shell
linux·运维·服务器