2023春计网期末

二

解答

问题1：从t0到t1期间，H1除了HTTP之外还运行了哪个应用层协议？从应用层到数据链路层，该应用层协议报文是通过哪些协议进行逐层封装的？

  • 还运行的应用层协议：DNS（域名系统）。因为H1需要通过域名www.abc.com访问Web服务器，必须先解析域名对应的IP地址，DNS用于此目的。

  • DNS协议报文的逐层封装：

    • 应用层：DNS协议报文（包含查询www.abc.com的请求）。
    • 传输层：封装在UDP协议中。UDP头部包括源端口（H1随机选择的端口）和目的端口（53，DNS标准端口）。
    • 网络层：封装在IP协议中。IP头部包括源IP地址（H1的192.168.1.3）和目的IP地址（本地域名服务器的192.168.1.2）。
    • 数据链路层：封装在以太网协议中。以太网帧头部包括源MAC地址（H1的00-11-22-33-44-cc）和目的MAC地址（本地域名服务器的00-11-22-33-44-bb，该地址在DNS查询前已通过ARP协议获得）。

封装过程总结：
DNS报文 → UDP数据报 → IP数据报 → 以太网帧。

问题2：若S的交换表结构为<MAC地址，端口>，则t1时刻S交换表的内容是什么？

  • t1时刻S交换表的内容：
    在t1时刻，S第一次收到封装HTTP请求报文的以太网帧（即发送给路由器R的帧）。在此之前，从t0到t1期间，S已通过帧转发过程学习了相关MAC地址和端口的映射。交换表包含以下三个条目（假设端口分配如下：端口1连接H1、端口2连接H2、端口3连接本地域名服务器、端口4连接路由器R；实际端口号可能因拓扑而异，但内容基于MAC地址和逻辑端口）：

    • <00-11-22-33-44-cc, 端口1> // H1的MAC地址，连接H1的端口
    • <00-11-22-33-44-bb, 端口3> // 本地域名服务器的MAC地址，连接本地域名服务器的端口
    • <00-11-22-33-44-aa, 端口4> // 路由器R的MAC地址，连接路由器R的端口

    解释：

    • H2的MAC地址（00-11-22-33-44-dd）未被学习，因为H2在此期间未发送任何帧（仅接收广播帧，未主动发送）。
    • 学习过程：
      • H1发送ARP请求广播时，S学习H1的MAC地址（00-11-22-33-44-cc）及其端口。
      • 本地域名服务器发送ARP响应和DNS响应时，S学习其MAC地址（00-11-22-33-44-bb）及其端口。
      • 路由器R发送ARP响应时，S学习其MAC地址（00-11-22-33-44-aa）及其端口。

问题3：从t0到t1期间，H2至少会接收到几个与此次Web访问相关的帧？接收到的是什么帧？帧的目的MAC地址是什么？

  • H2接收到的帧数量和类型：
    H2至少会接收到2个与此次Web访问相关的帧。这些帧均为ARP请求广播帧。

  • 帧的目的MAC地址：
    所有接收到的帧的目的MAC地址均为广播地址（FF-FF-FF-FF-FF-FF）。

    解释：

    • 在t0到t1期间，H1进行了两次ARP请求广播：
      1. 第一次ARP请求：查询本地域名服务器IP地址（192.168.1.2）对应的MAC地址。
      2. 第二次ARP请求：查询默认网关（路由器R接口IP地址192.168.1.126）对应的MAC地址。
    • 由于交换机S的交换表初始为空，这些广播帧被泛洪到所有端口（包括H2连接的端口），因此H2会接收到这两帧。
    • H2未发送任何帧（题目假设无无关通信），因此只接收到这些广播帧，未接收单播帧（如DNS查询或HTTP请求）。

三

解答

根据提供的网络拓扑和问题描述，以下是针对题47的完整解答。网络拓扑关键点如下：

  • 路由器R2和R3均具备NAT功能。
  • R2的接口：
    • WAN接口：203.10.2.2/30（连接Internet）
    • LAN接口：192.168.1.1/24（连接Web服务器和H1）
  • R3的接口：
    • WAN接口：203.10.2.5/30（连接Internet）
    • LAN接口：192.168.1.1/24（连接H2和H3，与R2的LAN子网地址重叠，但通过NAT隔离）
  • Web服务器：IP地址192.168.1.2（位于R2的LAN），使用HTTP默认端口80。
  • H1：IP地址192.168.1.3（位于R2的LAN）。
  • H2：IP地址192.168.1.2（位于R3的LAN）。
  • H3：IP地址192.168.1.3（位于R3的LAN）。
  • NAT转换表结构为：
    | 外网IP地址 | 外网端口号 | 内网IP地址 | 内网端口号 |

由于R2和R3的LAN均使用相同的私有IP地址空间（192.168.1.0/24），需要通过NAT解决地址冲突，并确保路由可达。以下是针对各问题的解答。

1) 为使H2和H3能够访问Web服务器（使用默认端口号），需要进行什么配置？

为使H2和H3能够访问Web服务器，需要进行以下配置：

  • 在R2上配置目的NAT（端口转发）：
    • 添加一条静态NAT条目，将到达R2 WAN接口IP（203.10.2.2）的HTTP流量（端口80）转发到Web服务器的私有IP（192.168.1.2）和端口80。
    • NAT转换表条目示例：
      外网IP地址 外网端口号 内网IP地址 内网端口号
      203.10.2.2 80 192.168.1.2 80
    • 理由：Web服务器位于R2的私有LAN，外部访问需要通过R2的WAN IP进行端口转发。
  • 在R3上配置源NAT（动态NAT）：
    • 启用源NAT（NAPT），使H2和H3的出站流量能够被转换为R3的WAN IP（203.10.2.5）。动态NAT条目会在H2或H3发起连接时自动创建，无需静态配置。
    • 理由：H2和H3位于私有LAN，访问Internet时需要源IP转换，以解决地址冲突和路由问题。
  • 在H2和H3上配置Web服务器的访问地址：
    • H2和H3必须使用Web服务器的公网IP地址（203.10.2.2）进行访问，而不是私有IP（192.168.1.2），以避免本地子网路由冲突（因为H2和H3的本地网络也是192.168.1.0/24，直接访问192.168.1.2会被误认为本地主机）。
    • 可选：如果使用域名（如www.abc.com），需在本地DNS服务器或H2/H3的DNS设置中将www.abc.com解析为203.10.2.2。

总结配置步骤：

  1. 在R2上设置静态NAT端口转发：WAN IP 203.10.2.2:80 → Web服务器 192.168.1.2:80。
  2. 在R3上启用源NAT（动态NAPT）功能，允许出站流量转换。
  3. 在H2和H3的浏览器或主机设置中，指定Web服务器地址为203.10.2.2（或通过DNS解析）。

2) 若H2主动访问Web服务器时，将HTTP请求报文封装到IP数据报P中发送，则：

假设H2已配置为访问Web服务器的公网IP（203.10.2.2），HTTP请求使用默认端口80。IP数据报P的封装和转换过程如下：

  • H2发送P时：
    • 源IP地址：H2的私有IP，192.168.1.2
    • 目的IP地址：Web服务器的公网IP（R2的WAN IP），203.10.2.2
    • 理由：H2在R3的LAN内，目的IP（203.10.2.2）不在本地子网，因此P被发送到默认网关R3（192.168.1.1）。
  • 经过R3转发后：
    • 源IP地址：R3的WAN IP，203.10.2.5（R3执行源NAT，将源IP从192.168.1.2转换为203.10.2.5）
    • 目的IP地址：不变，203.10.2.2
    • 理由：R3的NAT功能修改源IP以实现出站流量转换；目的IP仍是Web服务器的公网地址。
  • 经过R2转发后：
    • 源IP地址：不变，203.10.2.5（R3的WAN IP）
    • 目的IP地址：Web服务器的私有IP，192.168.1.2（R2执行目的NAT，将目的IP从203.10.2.2转换为192.168.1.2）
    • 理由：R2的NAT端口转发功能根据预配置的静态条目修改目的IP，将流量导向Web服务器。

IP地址变化总结：

阶段 源IP地址 目的IP地址
H2发送 192.168.1.2 203.10.2.2
经R3转发后 203.10.2.5 203.10.2.2
经R2转发后 203.10.2.5 192.168.1.2

注意：以上仅关注IP层地址；传输层端口（如TCP端口80）也会在NAT中被修改，但问题未要求端口细节。

针对额外问题（用户提供的第3、4、5部分）

问题描述涉及H2向H1发送TCP数据包（H2位于R3的LAN，H1位于R2的LAN），假设TCP连接已建立，序列号以字节为单位。以下是解答：

3) H2发给H1的三个包序号分别为90、120、150，求第一个包和第二个包的大小，收到第二个包后H1发的ACK序号是多少？

  • 第一个包（序列号90）的大小：
    • 序列号90表示数据起始字节号；下一个包序列号为120，因此第一个包的数据大小为120 - 90 = 30字节。
  • 第二个包（序列号120）的大小：
    • 序列号120表示数据起始字节号；下一个包序列号为150，因此第二个包的数据大小为150 - 120 = 30字节。
  • H1收到第二个包后发送的ACK序号：
    • 第二个包携带字节120至149（大小30字节），H1正确接收后，期望下一个字节序号为150。
    • TCP ACK序号是累积确认，表示下一个期望接收的字节序号，因此ACK序号为150。

答案：

  • 第一个包大小：30字节
  • 第二个包大小：30字节
  • ACK序号：150

4) 若第二个包丢包，H1收到第三个包后发的ACK序号是多少？

  • 场景：第二个包（序列号120，大小30字节）丢失，H1未收到。H1先收到第一个包（序列号90，字节90-119），然后收到第三个包（序列号150，字节150开始）。
  • H1的处理：
    • H1收到第三个包（序列号150）时，检测到序列号不连续：期望序列号120，但收到150（非期望序号）。
    • TCP使用累积ACK，因此H1会发送重复ACK（duplicate ACK），确认已连续接收的最大字节序号（即第一个包的字节90-119）。
    • ACK序号表示下一个期望的字节序号，即120。
  • 答案：ACK序号为120（请求重传从120开始的字节）。

5) 校外主机P想要访问校内主机H3，如何实现？

  • 背景：H3位于R3的LAN，私有IP为192.168.1.3；校外主机P在Internet上（公网IP未知）。需要穿越NAT访问H3的服务（未指定具体服务，假设通用访问）。
  • 配置方法：
    • 在R3上配置静态NAT端口转发：
      • 添加一条静态NAT条目，将到达R3 WAN接口IP（203.10.2.5）的特定端口流量转发到H3的私有IP和端口。
      • 例如，如果访问H3的HTTP服务（端口80），则配置：
        外网IP地址 外网端口号 内网IP地址 内网端口号
        203.10.2.5 80 192.168.1.3 80
      • 如果服务未知，需指定一个公网端口（如8080）映射到H3的私有端口。
    • 校外主机P的访问方式：
      • P必须访问R3的WAN IP（203.10.2.5）和配置的端口（例如80或自定义端口）。
      • 例如，在浏览器中输入 http://203.10.2.5（如果映射到H3的80端口）。
    • 注意事项：
      • 确保R3的安全策略允许外部访问（如防火墙规则）。
      • 如果H3运行多个服务，需为每个服务配置独立的端口转发。
  • 总结步骤：
    1. 在R3的NAT表中添加静态端口转发规则（外网IP:端口 → H3私有IP:端口）。
    2. 校外主机P使用R3的WAN IP（203.10.2.5）和指定端口访问H3。

示例：若P访问H3的SSH服务（端口22），配置R3将外网端口2222映射到192.168.1.3:22，则P使用 ssh -p 2222 user@203.10.2.5。

四

协议行为分析

该协议的行为特点是：

  1. 延迟发送小报文：当待发送的报文小于特定大小时，不会立即发送
  2. 等待所有ACK：直到当前已发送的所有报文都收到ACK确认
  3. 合并发送：将等待期间积累的小报文合并为一个较大的报文发送

设计目的

  1. 减少网络拥塞

    • 避免发送大量小报文（如每个报文只有几个字节的有效载荷）
    • 小报文头部开销大（如TCP/IP头部至少40字节），合并后显著提高有效载荷占比
    • 例：发送10个1字节报文需400字节头部，合并为1个10字节报文只需40字节头部

  2. 提高网络利用率

    • 减少报文数量可降低网络设备（路由器/交换机）的处理负担
    • 避免网络被小报文淹没导致排队延迟和丢包

  3. 优化ACK机制

    • 减少需要确认的报文数量（1个ACK确认多个数据）
    • 避免ACK风暴（大量小报文触发大量ACK）

  4. 降低协议开销

    • 减少总头部开销（如TCP/IP、以太网帧头等）
    • 避免频繁的上下文切换和系统调用

负面影响

  1. 增加传输延迟

    • 小报文需等待之前所有ACK到达才能发送
    • 对实时应用影响显著（如远程控制、游戏、音视频通话）
    • 例：键盘输入需等待100ms+才能发出

  2. 导致缓冲区膨胀

    • 发送端需维护待合并的小报文缓冲区
    • 可能导致内存占用过高或缓冲区溢出

  3. 加剧队头阻塞

    • 若某个报文丢失/延迟导致ACK未到
    • 后续所有小报文都被阻塞无法发送
    • 即使这些报文与丢失报文无关

  4. 降低交互响应性

    • 交互式应用体验下降（如SSH/Telnet输入卡顿）
    • 用户感知延迟明显增加

  5. 公平性问题

    • 合并大报文可能长时间占用带宽
    • 影响其他数据流的及时传输

典型应用与改进

  • 类似协议：TCP的Nagle算法（RFC 896）
  • 优化方案：
    • 设置最大等待时间（避免无限延迟）
    • 对特定应用禁用（如实时游戏）
    • 动态调整合并阈值（根据网络状况）
    • 区分优先级（高优先级报文立即发送）

这种设计本质上是吞吐量与延迟的权衡：牺牲单次传输的及时性，换取整体网络效率和吞吐量的提升。在网络环境复杂、带宽受限的场景下利大于弊，但对延迟敏感的应用需谨慎使用。

五

TCP-CUBIC 和 TCP-Reno 的核心差异在于拥塞窗口（cwnd）的增长函数设计和丢包响应机制。相较于 Reno 的线性增长和激进退避，CUBIC 通过三次函数模型和更智能的恢复策略显著提升了高带宽、高延迟网络（如现代互联网）的性能。以下是具体优势分析：

1. 拥塞避免机制的优势

TCP-Reno 的缺陷（AIMD 模型）：

  • 线性增长（Additive Increase）：
    每 RTT 时间 cwnd 固定增加 1 MSS（Max Segment Size）。
    → 问题：在高速网络中恢复速度极慢（如 10Gbps 链路需数十分钟恢复）。
  • 乘性减少（Multiplicative Decrease）：
    发生丢包时，cwnd 直接减半（cwnd = cwnd × 0.5）。
    → 问题：频繁丢包导致吞吐量断崖式下降。

TCP-CUBIC 的改进（三次函数模型）：

  • 基于时间的增长函数：
    cwnd 增长由函数 \(W(t) = C \times (t - K)^3 + W_{\text{max}}\) 决定，其中：
    • \(C\)：缩放因子（默认 0.4）
    • \(t\)：距离上一次拥塞事件的时间
    • \(W_{\text{max}}\)：上一次丢包时的 cwnd 值
    • \(K = \sqrt[3]{\frac{W_{\text{max}} \times \beta}{C}}\)（\(\beta\) 为乘性减少因子，默认 0.7）
      → 优势：
    • 快速逼近历史最大窗口：在 \(t = K\) 时达到 \(W_{\text{max}}\)（凹增长阶段），随后平缓探索带宽（凸增长阶段）。
    • RTT 公平性：增长独立于 RTT，避免长 RTT 流被短 RTT 流压制。
    • 高带宽利用率：在高速网络中可快速填充空闲带宽。

2. 快速恢复机制的优势

TCP-Reno 的缺陷：

  • 依赖重复 ACK（DupACK）触发快速重传：
    需收到 3 个 DupACK 才重传丢失报文。
    → 问题：若丢包率较高或窗口较小，可能无法触发快速恢复，退守超时重传（RTO），导致性能崩溃。
  • 恢复后保守：
    快速恢复阶段每收到一个 DupACK 仅微增 cwnd（cwnd += 1 MSS），效率低下。

TCP-CUBIC 的改进：

  • HyStart 算法（初始慢启动优化）：
    在连接初期使用指数增长，但通过梯度检测提前退出慢启动，避免初始丢包。
    → 减少早期拥塞事件概率。
  • 更宽松的快速重传触发：
    结合 SACK（选择性确认）选项，可更精准识别多个丢包。
  • 恢复阶段窗口调整优化：
    发生丢包时，cwnd 降至 \(W_{\text{max}} \times \beta\)（\(\beta\)=0.7），而非直接减半（Reno \(\beta\)=0.5）。
    → 保留更多发送窗口，加速恢复。

七

解答

1. DNS 主动攻击设计（让 Alice 收到假 Response）

拦截下来，发送一个假的响应

2. 验证签名 (m, Ks⁻(H(m))) 是否来自服务器 s

验证步骤：

  1. 获取公钥：
    • 服务器预先拥有 s 的公开密钥 Kpub_s（通过证书或可信渠道分发）。
  2. 计算哈希：
    • 对收到的消息 m 计算哈希值 H(m)（使用相同的哈希算法）。
  3. 解密签名：
    • 用 Kpub_s 解密签名 Ks⁻(H(m))，得到解密结果 decrypted_hash。
  4. 比对验证：
    • 若 decrypted_hash == H(m)，则签名有效，证明消息由 s 的私钥签发（即来自 s）。
    • 否则签名无效。

原理：

  • 只有 s 的私钥 Ks⁻ 能生成该签名，而 Kpub_s 可公开验证其真实性。

3. 是否可用公钥加密替代私钥签名？

答案：不可行
原因：

  • 私钥签名（当前方案）：
    • 目的：身份认证和完整性保护。
    • 仅 s 能生成 Ks⁻(H(m))，任何持有 Kpub_s 的人均可验证。
  • 若改用公钥加密（如 Kpub_s(m)）：
    • 目的变为保密性（只有 s 能解密）。
    • 但无法证明发送者身份（任何人可用 s 的公钥加密数据）。
    • 缺陷：攻击者可冒充 s 发送 (m, Kpub_s(m))，接收方无法区分发送者。

结论：

  • 私钥签名用于认证，公钥加密用于保密，两者目标不同，不可互换。

4. 该加密算法能否防止第 1 问的 DNS 攻击？

答案：可以防止
原因：

  • 若 DNS 响应使用 数字签名（如 DNSSEC 协议）：
    • 权威服务器对响应 m（如域名-IP 映射）生成签名 Ks⁻(H(m))。
    • Alice 用权威服务器的公钥 Kpub 验证签名。
  • 防御效果：
    • 攻击者无法伪造有效签名（因无权威服务器的私钥 Ks⁻）。
    • 即使发送伪造响应，Alice 验证签名失败后会丢弃该响应。

关键点：

  • DNSSEC 通过数字签名机制防止 DNS 缓存投毒攻击。

5. RSA 私钥计算

给定参数：

  • Alice：N_a = 55, e_a = 3
  • Bob：N_b = 33, e_b = 13

私钥公式：d ≡ e⁻¹ mod φ(N)
步骤：

  1. 分解 N 计算 φ(N)：
    • Alice (N_a=55)：
      • 55 = 5 × 11 → φ(55) = (5-1)×(11-1) = 4×10 = 40
      • 求 d_a ≡ 3⁻¹ mod 40 → 解 3d_a ≡ 1 mod 40
      • 得 d_a = 27（因 3×27=81 ≡ 1 mod 40）
    • Bob (N_b=33)：
      • 33 = 3 × 11 → φ(33) = (3-1)×(11-1) = 2×10 = 20
      • 求 d_b ≡ 13⁻¹ mod 20 → 解 13d_b ≡ 1 mod 20
      • 得 d_b = 17（因 13×17=221 ≡ 1 mod 20）

答案：

  • Alice 私钥 d_a = 27
  • Bob 私钥 d_b = 17

最终答案总结

问题 答案
1. DNS 攻击方法 DNS 缓存投毒：伪造响应匹配事务 ID/端口号，抢先发送至 Alice
2. 签名验证步骤 用 s 的公钥解密签名，比对 H(m)
3. 是否可用公钥加密 不可行（公钥加密用于保密性，无法认证身份）
4. 能否防御 DNS 攻击 可以（数字签名使伪造响应无法通过验证）
5. RSA 私钥 Alice: d_a=27, Bob: d_b=17
posted @ 2025-06-17 11:05  最爱丁珰  阅读(35)  评论(0)    收藏  举报