计算机网络(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. 实时应用:比如视频流、音频流等实时应用,也可以采用滑动窗口机制,以保证流畅的传输。
相关推荐
BachelorSC1 小时前
【网络工程师软考版】网络安全
网络·安全·web安全
蝶恋舞者2 小时前
怎样让阿里云服务器(centos)有界面
服务器·阿里云·centos
(Charon)2 小时前
【C语言网络编程】HTTP 客户端请求(基于 Socket 的完整实现)
网络·网络协议·http
Bryce李小白3 小时前
Kotlin实现Retrofit风格的网络请求封装
网络·kotlin·retrofit
Lovyk3 小时前
Linux网络管理
服务器·网络·php
无敌的牛4 小时前
Linux重定向的理解
linux·运维·服务器
MC皮蛋侠客4 小时前
AsyncIOScheduler 使用指南:高效异步任务调度解决方案
网络·python·fastapi
许野平5 小时前
Rust:anyhow::Result 与其他 Result 类型转换
服务器·开发语言·rust·result·anyhow
IT摆渡者5 小时前
Wireshark攻防实战
linux·服务器·经验分享·笔记
DAWN_T176 小时前
关于网络模型的使用和修改/保存和读取
网络·人工智能·pytorch·python·深度学习·神经网络·机器学习