首页 计算机科学 计算机网络

# 数据平面（Data Plane）

# 1. 数据平面的功能：

数据平面在每个路由器上本地执行，负责将进入路由器的分组从输入端口转发到正确的输出端口。核心任务是根据路由表决定每个数据包的转发路径​。

# 2. 转发表（Forwarding Table）：

每个路由器的转发表决定了数据包的转发规则。数据平面根据数据包头中的字段值（如目的IP地址）匹配相应规则，并执行相应的操作，如转发到特定端口或丢弃​。

# 3. OpenFlow 和流表：

在SDN架构中，数据平面使用OpenFlow等协议支持的流表（Flow Table），可以灵活定义转发规则。流表包含匹配字段、操作（例如转发、丢弃、修改）和计数器。控制器根据网络状态动态下发这些规则，以适应网络需求​.



如上图我们可以看到

  1. Destination-based forwarding（基于目标地址的转发）
  • 匹配条件：
    • 目标 IP 地址为 51.6.0.8 。
    • 其他字段使用通配符 * ，表示任何值。
  • 操作：
    • 动作是将符合条件的数据包转发到端口 port6 。
  • 解释：这个规则的作用是，当数据包的目标地址为 51.6.0.8 时，将该数据包转发到交换机的端口 6。这样可以确保发往该地址的数据包沿着预设路径传输，通常用于路由数据包到特定的目的地。
  1. Firewall（防火墙规则）

  • 规则 1：

    • 匹配条件：TCP 的目标端口为 22 （通常用于 SSH 连接）。
    • 其他字段使用通配符 * 。
    • 操作：丢弃数据包（drop）。
    • 解释：这个规则的目的是阻止所有目标端口为 22 的数据包，起到屏蔽 SSH 流量的作用。这种规则通常用于限制对特定服务的访问，以增强网络的安全性。

  • 规则 2：

    • 匹配条件：源 IP 地址为 128.119.1.1 。
    • 其他字段使用通配符 * 。
    • 操作：丢弃数据包（drop）。
    • 解释：此规则阻止所有来自 128.119.1.1 主机的流量。可能用于封锁特定设备或网络源的访问，防止来自该源的恶意流量。

# 4. 通用转发（Generalized Forwarding）：

通用转发允许更细粒度的规则定义，例如基于源/目的IP地址、端口号等字段来处理数据包。这一机制使得数据平面可以灵活地执行各种操作，不仅限于简单的IP转发​。

# 控制平面（Control Plane）

在 SDN（软件定义网络）中，** 控制平面（Control Plane）** 负责网络的逻辑控制和管理决策，是 SDN 架构的核心部分。它与数据平面（Data Plane）分离，使网络管理更加灵活和集中化。以下是控制平面的主要内容：

# 1. 控制平面的功能

  • 路由决策：控制平面负责计算最佳路径，将路径信息下发给数据平面。例如，它决定不同数据包通过的路径，以达到最优的流量管理和资源利用。
  • 策略管理：控制平面可以根据业务需求或策略规定数据包的处理方式。例如，它可以定义哪些数据包需要优先处理、哪些流量要进行限制。
  • 集中控制：在 SDN 中，控制平面通常由一个集中控制器（如 OpenDaylight、ONOS 等）实现。这个集中控制器管理整个网络的规则和策略，为各个交换机和路由器提供统一的控制。

# 2. 控制器与数据平面的交互

  • OpenFlow 协议：控制平面通常通过 OpenFlow 协议与数据平面交换机和路由器通信。控制器通过下发流表规则，告知交换机如何处理不同的数据包。
  • 流表规则的下发与更新：控制平面根据实时网络状态下发或更新流表规则，控制数据包的转发路径。例如，当检测到拥塞时，控制器可以重新配置流表，将流量分配到其他路径上。

# 3. 网络拓扑的发现和监控

  • 拓扑发现：控制平面可以监控网络中设备的连接关系，自动生成和更新网络拓扑图。这使得控制器可以实时了解网络的结构，并在路径规划时考虑网络设备的物理位置和连接情况。
  • 性能监控和故障检测：控制平面可以采集网络中各设备的状态信息（如流量负载、延迟），并根据监控数据检测故障。例如，如果某条路径出现故障，控制平面可以迅速重新规划路径，将流量重新路由到其他可用路径。

# 4. 控制平面的优势

  • 集中化管理：控制平面将网络的控制逻辑集中在控制器上，使网络管理和策略应用变得更加统一和简便。
  • 动态适应性：控制平面可以根据实时数据和业务需求，动态调整网络配置和流量分配。比如，它可以自动调整流量优先级，以确保关键应用的带宽需求。
  • 易扩展性：通过控制平面，网络管理员可以灵活地添加新规则，满足不断变化的网络需求，适应大规模和复杂的网络环境。

# 5. 典型应用场景

  • 流量工程：控制平面可以根据网络负载情况，动态调整数据包的转发路径，平衡流量负载，优化资源使用。
  • 网络安全：控制器可以检测异常流量或攻击行为，快速应用安全策略（如阻断恶意流量或隔离受感染设备）。
  • 服务质量（QoS）管理：控制平面可以确保高优先级业务（如视频会议）的带宽需求，同时限制低优先级业务，以提供更好的服务质量。

# 示例解读

  1. 链路故障检测：

    • 在图中， S1 交换机检测到与 S2 之间的链路发生故障（红色链接）。通过 OpenFlow 协议， S1 发送一个端口状态消息（port status message）给 SDN 控制器，通知链路状态的变化。

  2. 控制器接收故障消息：

    • SDN 控制器收到来自 S1 的 OpenFlow 消息，并更新链路状态信息。控制器在内存中维护网络拓扑和链路状态，这样它可以根据最新的网络状态做出决策。

  3. 触发路由算法：

    • 在控制器中，Dijkstra’s link-state Routing（Dijkstra 链路状态路由算法）应用程序已经预先注册，以便在链路状态变化时被调用。当控制器更新链路状态后，自动调用该路由算法。

  4. 重新计算路由：

    • Dijkstra 路由算法访问控制器中的网络图信息和链路状态信息，并计算新的路由。该算法会考虑网络中其他节点和链路的状态，以找到从源到目的地的最优路径。

  5. 更新流表：

    • 新的路由计算完成后，控制器会生成更新后的流表，并通过 OpenFlow 协议下发到各个相关交换机（如 S1 、 S2 、 S3 等）。这些交换机会根据新的流表规则调整数据包的转发路径。

  6. 数据恢复：

    • 一旦流表更新完成，网络中的流量将按照新路径进行传输，确保数据流在故障恢复后的最短时间内继续传输，从而实现网络的动态修复和负载均衡。

关键要点

  • OpenFlow 协议：控制器和交换机之间的通信依赖 OpenFlow 协议。交换机将链路故障等事件上报给控制器，控制器下发新的流表规则。
  • 链路状态路由：Dijkstra 算法是一种链路状态路由算法，可以快速计算最优路径。控制器利用该算法在网络故障时重新计算路径，确保网络的高效运行。
  • 集中控制：在 SDN 架构中，控制器充当了网络的 “中枢神经”，统一管理和协调网络的各个设备，实现了传统网络难以实现的快速恢复和灵活路由。

# Transport Services（传输服务）

# 1. 传输层的主要功能

  • 进程到进程的通信：传输层提供应用进程之间的通信服务。不同于网络层提供的主机到主机的通信，传输层能够识别主机上具体的应用进程（如通过端口号），从而实现进程间的直接通信。
  • 多路复用与多路分解：通过端口号，传输层可以支持多个应用程序在同一主机上同时使用网络通信。这使得来自不同应用的数据可以被正确地分解并发送给合适的进程。

# 2. 传输层的核心服务

传输层提供了两种主要的服务类型：

  • 面向连接的服务（例如 TCP）：

    • 可靠数据传输：TCP 通过确认（ACK）、重传（retransmission）等机制确保数据包在传输中不丢失、不重复、按顺序到达。
    • 流量控制：TCP 实现流量控制，以防止发送方发送的数据过多，超出接收方的处理能力。
    • 拥塞控制：TCP 还提供拥塞控制功能，监测网络拥塞状态，动态调整发送速率，以避免网络拥堵。
    • 连接管理：在数据传输前，TCP 使用三次握手建立连接，并在传输完成后使用四次挥手释放连接，确保端到端的可靠连接。

  • 无连接的服务（例如 UDP）：

    • 尽最大努力交付：UDP 不保证数据包的可靠传输，不使用重传机制，数据可能丢失、重复或乱序到达。
    • 低延迟：UDP 因为不保证可靠性和顺序性，传输过程简单，因此传输延迟较低，适合对实时性要求较高的应用，如视频流和在线游戏。
    • 无连接传输：UDP 不建立连接，数据包可直接发送给目标，减少了连接建立的开销。

# 3. 传输服务的典型应用场景

  • TCP 的应用场景：适用于对数据完整性和可靠性有较高要求的应用，如网页浏览（HTTP）、电子邮件（SMTP）、文件传输（FTP）等。
  • UDP 的应用场景：适用于实时性更高的应用，如视频会议、在线游戏、DNS 查询等。

# 4. QoS（服务质量）支持

  • 传输服务还可以在一定程度上支持 QoS 需求，例如，通过设置不同的优先级或带宽控制来满足不同应用的传输要求。
  • 对于实时应用，UDP 通常优于 TCP，因为它减少了传输开销和延迟，但无法提供可靠性保障。TCP 则通过其可靠性和流量控制特性，适合需要数据完整性的应用。

# UDP

# 1. UDP 的主要特性

  • 无连接：UDP 是无连接的传输协议，发送数据前无需建立连接，接收方也无需确认。发送方可以直接将数据报发送到目标端口。
  • 不可靠传输：UDP 不保证数据报的可靠性，即数据可能丢失、重复、或乱序到达。
  • 无重传机制：UDP 不实现重传机制，丢失的数据不会再次发送，这减少了延迟和开销。
  • 简单的头部结构：UDP 的数据包头部很简单，仅包含源端口、目的端口、数据长度和校验和等少量信息，使得它的开销小、处理快。

# 2. UDP 头部结构

  • 源端口（Source Port）：可选项，表示数据包的发送端口，方便接收端识别数据的来源。
  • 目的端口（Destination Port）：必选项，表示数据包的接收端口，接收方根据此端口号将数据包分发到相应的应用进程。
  • 长度（Length）：UDP 报文的总长度，包括头部和数据部分。
  • 校验和（Checksum）：用于检验数据的完整性，但不提供纠错功能。

# 3. UDP 的多路复用和多路分解

  • 多路复用（Multiplexing）：多个应用程序在同一主机上可以使用不同的 UDP 端口号向网络发送数据。每个数据包通过一个特定的 UDP 端口发送，确保发送端的数据流可以正确地传输到接收方。
  • 多路分解（Demultiplexing）：接收方的传输层通过数据包的目的端口号，将收到的数据包分配给相应的应用进程。
  • 基于端口的分解：UDP 的多路分解仅依赖于目的端口号，而不考虑源 IP 或源端口。这意味着不同的源可以通过相同的目的端口号将数据发送给同一个接收进程。

# 4. UDP 的典型应用场景

  • 实时应用：如视频会议、IP 电话、在线游戏等应用。它们对延迟敏感且要求数据尽快到达，丢包不会严重影响体验，因此更适合使用 UDP。
  • 广播和多播：UDP 支持广播和多播，可以将数据同时发送给多个接收方，适合用于局域网中的发现服务（如 DHCP、UPnP 等）。
  • 简化的传输需求：如 DNS 查询、SNMP 等应用，只需发送小数据量且无需重传。丢包对这些应用影响较小，因此它们更适合使用 UDP。

# 5. UDP 的优缺点

  • 优点：
    • 低延迟：无连接、无重传的特性使得 UDP 传输延迟低，适合实时应用。
    • 简单高效：头部结构简单，数据处理开销小。
    • 支持广播 / 多播：便于在局域网中进行资源发现。
  • 缺点：
    • 不可靠：无重传和确认机制，数据可能丢失或乱序。
    • 无流量控制和拥塞控制：可能导致网络拥堵或过载。

# 6. UDP 和 TCP 的对比

  • 可靠性：TCP 提供可靠传输和重传机制，而 UDP 不保证数据的传输可靠性。
  • 延迟：UDP 延迟更低，因为它无需建立连接和等待确认。
  • 数据顺序：TCP 保证数据按序到达，UDP 则不保证顺序。
  • 适用场景：TCP 适用于需要可靠性、数据完整性的应用，如文件传输、网页浏览；UDP 适用于对实时性要求高、允许丢包的应用，如视频流和 DNS 查询。

# TCP

在传输层协议中，**TCP（Transmission Control Protocol，传输控制协议）** 是一种面向连接、可靠的传输协议。与 UDP 相比，TCP 提供了数据的可靠传输、流量控制和拥塞控制，是大多数对数据完整性要求较高的应用的首选协议。以下是 TCP 部分的核心内容：

# 1. TCP 的主要特性

  • 面向连接：TCP 是面向连接的协议，数据传输前需要建立连接。TCP 通过三次握手建立连接，并通过四次挥手断开连接。
  • 可靠传输：TCP 通过确认（ACK）、重传机制确保数据不丢失、不重复、按顺序到达接收方。
  • 有序传输：TCP 对数据包进行编号（序列号），接收方根据序列号将数据包按正确的顺序排列，从而保证数据的有序性。
  • 全双工通信：TCP 支持全双工通信，允许通信双方在同一时间内发送和接收数据。
  • 流量控制：TCP 使用滑动窗口机制进行流量控制，确保发送方的发送速率不会超出接收方的接收能力。
  • 拥塞控制：TCP 具有拥塞控制机制，通过动态调整发送速率来防止网络拥塞。

# 2. TCP 连接的建立和断开

  • 三次握手（Three-Way Handshake）：
    • 连接建立时，TCP 使用三次握手协议。
    • 第一步：客户端向服务器发送 SYN（同步）请求。
    • 第二步：服务器收到 SYN 后，返回一个 SYN-ACK（同步确认）。
    • 第三步：客户端收到 SYN-ACK 后，再发送一个 ACK，连接正式建立。
  • 四次挥手（Four-Way Teardown）：
    • 连接断开时，TCP 使用四次挥手协议。
    • 第一步：客户端向服务器发送 FIN（终止）请求。
    • 第二步：服务器收到 FIN 后，返回一个 ACK，表示收到。
    • 第三步：服务器在处理完数据后，发送 FIN 请求。
    • 第四步：客户端返回 ACK，连接正式断开。

# 3. TCP 的可靠性机制

  • 序列号（Sequence Number）：TCP 为每个字节分配一个序列号，以确保数据按顺序到达。
  • 确认应答（ACK）：接收方在接收到数据后，向发送方发送确认信息（ACK），告知发送方数据已成功接收。
  • 重传机制：如果发送方在超时时间内未收到 ACK，则会重传数据。TCP 根据网络状态调整超时时间，确保数据可靠传输。
  • 窗口机制：TCP 通过窗口机制一次可以发送多个字节的数据，窗口大小取决于接收方的接收能力和网络状况。

# 4. TCP 的流量控制

  • 滑动窗口（Sliding Window）：TCP 使用滑动窗口机制进行流量控制，窗口大小代表了发送方在未接收到 ACK 前可以发送的最大数据量。
  • 窗口调整：接收方通过通告窗口（Advertised Window）来控制发送方的发送速率。接收方在 ACK 中通告自己的接收窗口大小，发送方根据该窗口调整发送数据的量。
  • 目的：流量控制确保发送方不会淹没接收方的缓冲区，避免接收方因接收速度不足而丢失数据。

# 5. TCP 的拥塞控制

  • 拥塞窗口（Congestion Window，cwnd）：TCP 维护一个拥塞窗口，该窗口根据网络拥塞情况动态变化。
  • 慢启动（Slow Start）：在连接开始时，TCP 使用慢启动算法，逐步增加拥塞窗口，探测可用带宽。
  • 拥塞避免（Congestion Avoidance）：当拥塞窗口达到阈值后，进入拥塞避免阶段，窗口以线性速度增长。
  • 快速重传和快速恢复：
    • 快速重传：当发送方收到三个重复的 ACK 时，认为该数据段丢失，立即重传而不等待超时。
    • 快速恢复：在快速重传后，TCP 直接进入拥塞避免阶段，避免回到慢启动。

# 6. TCP 的典型应用场景

  • 文件传输（如 FTP）：文件传输要求数据的完整性和顺序性，TCP 的可靠性和流量控制确保数据无丢失和按序到达。
  • 网页浏览（如 HTTP/HTTPS）：网页浏览要求数据可靠传输，以确保页面内容完整。TCP 的可靠性和流量控制能够确保用户得到完整的网页内容。
  • 电子邮件（如 SMTP）：电子邮件传输需要数据的完整性和正确性，因此 TCP 的可靠传输特性非常适合。

# 7. TCP 的优缺点

  • 优点：
    • 可靠传输：保证数据按顺序到达且不会丢失。
    • 流量和拥塞控制：适应不同的网络状况，防止网络拥堵。
    • 有序性：数据按顺序到达，适用于大多数需要数据完整性的应用。
  • 缺点：
    • 开销较高：TCP 头部较复杂，且维护连接状态会增加开销。
    • 延迟较高：TCP 的三次握手和确认机制增加了延迟，不适合对实时性要求较高的应用。

# 8. TCP 和 UDP 的对比

  • 可靠性：TCP 提供可靠传输，UDP 不保证可靠性。
  • 延迟：UDP 延迟更低，而 TCP 由于需要建立连接和确认机制，延迟较高。
  • 适用场景：TCP 适用于需要可靠传输的应用，如文件传输和网页浏览；UDP 适用于对实时性要求高的应用，如视频流和 DNS 查询。

# 总结

TCP 提供了一套复杂而强大的机制，确保数据的可靠传输。通过连接管理、确认机制、流量控制和拥塞控制，TCP 在需要数据完整性的场景下发挥了关键作用。TCP 的可靠性使其成为大多数网络应用（如 HTTP、FTP 和 SMTP）的首选协议。

# RDT

# rdt2.0 的关键要点

  1. 比特错误检测：

    • 数据在传输过程中可能会发生比特翻转（bit-flip），导致数据出错。
    • rdt2.0 使用校验和（checksum）来检测数据包中的比特错误。

  2. 确认和否认机制：

    • ACK（Acknowledgements）：当接收方确认数据包没有错误时，会发送 ACK（确认）消息给发送方，告知数据包正确接收。
    • NAK（Negative Acknowledgements）：当接收方检测到数据包出错时，会发送 NAK（否认）消息给发送方，告知该数据包有错误。

  3. 重传机制：

    • 当发送方收到 NAK 时，会重传数据包，以确保数据正确到达接收方。

  4. 新增机制：

    • 错误检测：通过校验和实现比特错误检测。
    • 接收方反馈：接收方通过控制消息（ACK 和 NAK）向发送方反馈接收状态，使发送方能够知道数据包是否需要重传。

# rdt2.0 的工作流程

  • 发送方发送数据包，数据包中包含校验和。
  • 接收方收到数据包后，检查校验和。
    • 如果校验和匹配，说明数据包无错误，接收方发送 ACK 给发送方。
    • 如果校验和不匹配，说明数据包有错误，接收方发送 NAK，要求发送方重传。
  • 发送方根据接收到的是 ACK 还是 NAK 来决定是否重传数据。

# 示例：发送方状态机解析

  1. 等待上层调用（Wait for call from above）：

    • 初始状态，发送方等待上层应用调用 rdt_send(data) 。
    • 一旦有数据传入，发送方创建数据包（包括数据和校验和） sndpkt = make_pkt(data, checksum) ，并通过 udt_send(sndpkt) 将数据包发送到信道。
    • 发送完数据后，发送方进入等待 ACK 或 NAK 的状态。

  2. 等待 ACK 或 NAK（Wait for ACK or NAK）：

    • 发送方在此状态下等待接收方的反馈。
    • 如果接收到的是 NAK（ isNAK(rcvpkt) ），表示数据包出错，发送方会重传数据包 udt_send(sndpkt) 。
    • 如果接收到的是 ACK（ isACK(rcvpkt) ），表示数据包已正确接收，发送方回到等待上层调用的初始状态。

# 接收方状态机解析

  1. 等待数据包（Wait for call from below）：

    • 初始状态，接收方等待数据包的到来。
    • 当接收到一个数据包 rdt_rcv(rcvpkt) 后，接收方会检查数据包是否损坏。

  2. 数据包损坏或无误：

    • 如果数据包损坏（ corrupt(rcvpkt) ）：接收方发送 NAK（ udt_send(NAK) ）通知发送方重传。
    • 如果数据包无误（ notcorrupt(rcvpkt) ）：接收方提取数据 extract(rcvpkt, data) ，并将其交付给上层 deliver_data(data) ，然后发送 ACK（ udt_send(ACK) ）通知发送方数据已正确接收。

# rdt2.0 的缺陷

  • 问题描述：

    • 如果 ACK 或 NAK 消息在传输过程中被损坏，发送方就无法知道接收方是否正确接收了数据包。
    • 发送方在这种情况下无法确定是否需要重传数据包，因为重传可能会导致接收方收到重复的数据包。

  • 不能直接重传的原因：

    • 如果发送方简单地重传数据包，可能会导致接收方接收到重复的数据，从而影响数据的正确性。
    • 由于发送方无法确定接收方的实际状态，因此简单的重传会导致数据包的冗余和不确定性。

# 处理重复数据包的方法

为了解决 ACK/NAK 损坏的问题，以及可能导致的重复数据包，rdt2.0 需要进行以下改进：

  1. 添加序列号（Sequence Number）：

    • 每个数据包附加一个序列号，以区分数据包的唯一性。
    • 序列号帮助接收方识别出重复的数据包，从而避免重复交付。

  2. 丢弃重复的数据包：

    • 如果接收方检测到数据包的序列号与上一个接收的数据包相同，则丢弃该数据包，不再传递给上层应用。
    • 这样可以确保即使发送方因 ACK/NAK 损坏而重传数据，接收方也不会重复处理相同的数据。

  3. 超时重传：

    • 为了防止无限等待，发送方可以使用超时机制。在未收到 ACK/NAK 的情况下，发送方等待一段时间后自动重传数据包。
    • 超时机制确保数据包能够最终被成功接收，避免了无休止的等待。

# “停止等待” 机制（Stop and Wait）

  • 在这种机制下，发送方每次仅发送一个数据包，然后等待接收方的 ACK 或 NAK 响应。
  • 只有在接收到 ACK 后，发送方才会继续发送下一个数据包。如果未收到 ACK（例如 ACK 损坏或丢失），发送方则会重传当前数据包。
  • 停止等待机制简化了协议的实现，但可能会导致传输效率下降，特别是在网络延迟较大时。

# 后续版本

# 1. rdt2.1：解决 ACK/NAK 损坏问题

  • 问题：在 rdt2.0 中，如果 ACK 或 NAK 发生损坏，发送方无法判断接收方的状态，从而导致数据包的潜在重复或丢失。

  • 改进：

    • 序列号：引入序列号来标记数据包的唯一性。每个数据包使用 0 或 1 的序列号，以便接收方可以检测到重复的数据包。
    • 冗余 ACK：如果 ACK 或 NAK 损坏，发送方会根据超时机制重发数据包。接收方在接收相同序列号的数据包时会丢弃重复的数据包，但仍会发送冗余 ACK。
    • 状态机调整：发送方和接收方都需要跟踪序列号，发送方根据接收的 ACK 或 NAK 来判断是否需要重传。

  • 工作流程：

    1. 发送方发送带序列号的包，并等待 ACK 或 NAK。
    2. 接收方收到包后，根据校验和检测是否有错误。若无错误，发送 ACK，若有错误，发送 NAK。
    3. 若 ACK/NAK 损坏，发送方超时后会重发数据包。接收方通过序列号来丢弃重复包。

  • 优势：rdt2.1 通过序列号和 ACK 重传解决了 ACK/NAK 损坏的问题。

# 2. rdt2.2：仅使用 ACK，无 NAK

  • 问题：rdt2.1 依赖 ACK 和 NAK 双重反馈，但在实际网络中，使用 NAK 可能会引入额外的复杂性。
  • 改进：
    • 纯 ACK 机制：取消了 NAK，接收方只使用 ACK 来响应。
    • 冗余 ACK 机制：如果接收方检测到数据包有错误（如校验和失败），则不发送 NAK，而是重复发送上一条 ACK。发送方在接收冗余 ACK 后，将重传数据包。
  • 工作流程：
    1. 发送方发送带序列号的包，并等待 ACK。
    2. 接收方若检测到包无错误，则发送 ACK。如果检测到包有错误，发送上一个包的 ACK（即冗余 ACK）。
    3. 发送方在接收到冗余 ACK 时，将当前包重发。
  • 优势：rdt2.2 避免了 NAK 的使用，简化了接收方逻辑。该版本仅依赖 ACK，进一步提高了效率。

# 3. rdt3.0：处理信道丢包问题

  • 问题：rdt2.x 版本解决了比特错误问题，但假设信道不会丢包。然而，在实际网络中，数据包可能会丢失，因此 rdt2.x 无法保证在丢包信道上的可靠性。
  • 改进：
    • 超时重传机制：rdt3.0 在发送方引入了超时重传机制。发送方在发送数据包后，启动一个定时器。如果在超时时间内未收到 ACK，则自动重传数据包。
    • 序列号：继续使用序列号来检测重复包，确保接收方不会交付重复数据。
  • 工作流程：
    1. 发送方发送带序列号的包，并等待 ACK，同时启动定时器。
    2. 接收方收到包后，若无错误，则发送 ACK 并交付数据；若有错误，发送冗余 ACK。
    3. 若发送方在超时时间内未收到 ACK，自动重传数据包。
    4. 接收方通过序列号丢弃重复包，保证数据无重复交付。
  • 优势：rdt3.0 通过超时重传机制解决了丢包问题，能够在信道丢包和比特错误情况下实现可靠传输。

# 总结

  • rdt2.1：在 rdt2.0 的基础上引入序列号，用 ACK 和 NAK 解决确认消息损坏的问题。
  • rdt2.2：去除 NAK，仅使用 ACK 机制，通过冗余 ACK 实现重传，简化了协议。
  • rdt3.0：引入超时重传机制，解决了信道丢包的问题，实现了在丢包和比特错误信道上的可靠数据传输。

rdt3.0 是这几个版本中最可靠的协议，适用于丢包和比特错误的复杂信道环境。