tcp/quic lab and switch lab added

network/tcpquiclab/QUIC_FIX_REPORT.md

@@ -0,0 +1,205 @@
+# QUIC 性能测试修复报告
+
+## 问题描述
+
+在 TCP 与 QUIC 性能对比实验中，QUIC 程序存在严重的性能问题：
+
+| 协议 | 吞吐量 (修复前) |
+|------|----------------|
+| TCP  | ~2200 MB/s     |
+| QUIC | ~6 MB/s        |
+
+QUIC 吞吐量仅为 TCP 的 **0.3%**，这明显不正常。
+
+## 问题分析
+
+### 问题 1：超时处理导致性能低下
+
+**原代码 (quic_perf_client.c 和 quic_perf_server.c)：**
+
+```c
+int64_t timeout_ns = quiche_conn_timeout_as_nanos(conn);
+if (timeout_ns > 0 && !has_outgoing && !finished_sending) {
+    struct timespec ts;
+    ts.tv_sec = timeout_ns / 1000000000;
+    ts.tv_nsec = timeout_ns % 1000000000;
+    nanosleep(&ts, NULL);
+}
+```
+
+**问题：** `quiche_conn_timeout_as_nanos()` 返回的是连接空闲超时时间（配置为 10 秒），而不是下一次需要处理事件的时间。这导致程序在没有数据发送时会等待很长时间，严重降低了事件循环的响应速度。
+
+### 问题 2：客户端过早关闭连接
+
+原代码中客户端发送完数据后只是简单地 `usleep(1000)` 然后继续循环，没有正确处理连接关闭逻辑。
+
+## 修复方案
+
+### 修复 1：优化轮询间隔
+
+**quic_perf_server.c (第 186-191 行)：**
+
+```c
+quiche_conn_on_timeout(conn);
+
+// 使用更短的轮询间隔以提高响应速度
+if (!has_outgoing) {
+    usleep(100);  // 100微秒轮询
+}
+```
+
+**quic_perf_client.c (第 125-130 行)：**
+
+```c
+quiche_conn_on_timeout(conn);
+
+// 使用更短的轮询间隔以提高响应速度
+if (!has_outgoing && !finished_sending) {
+    usleep(100);  // 100微秒轮询
+}
+```
+
+### 修复 2：简化客户端发送完成后的处理
+
+```c
+if (finished_sending && !has_outgoing) {
+    usleep(1000);
+}
+```
+
+## 修复结果
+
+| 协议 | 修复前 | 修复后 | 提升 |
+|------|--------|--------|------|
+| TCP  | ~2200 MB/s | ~1400 MB/s | - |
+| QUIC | ~6 MB/s | ~92 MB/s | **15倍** |
+
+## 测试命令
+
+### 正常网络环境测试
+
+```bash
+# TCP 测试
+./tcp_perf_server &
+sleep 1
+./tcp_perf_client
+wait
+
+# QUIC 测试
+./quic_perf_server &
+sleep 1
+./quic_perf_client
+sleep 3
+```
+
+### 丢包环境测试 (5%)
+
+```bash
+# 添加 5% 丢包
+sudo tc qdisc add dev lo root netem loss 5%
+
+# 运行 TCP 和 QUIC 测试...
+
+# 清除规则
+sudo tc qdisc del dev lo root
+```
+
+### 延迟环境测试 (100ms)
+
+```bash
+# 添加 100ms 延迟
+sudo tc qdisc add dev lo root netem delay 100ms
+
+# 运行 TCP 和 QUIC 测试...
+
+# 清除规则
+sudo tc qdisc del dev lo root
+```
+
+### 检查和清除 tc 规则
+
+```bash
+# 查看当前规则
+tc qdisc show dev lo
+
+# 清除所有规则
+sudo tc qdisc del dev lo root
+```
+
+---
+
+## 为什么 QUIC 吞吐量仍然远小于 TCP？
+
+修复后 QUIC 达到 ~92 MB/s，而 TCP 达到 ~1400 MB/s，QUIC 仍然只有 TCP 的 **6.5%**。这是正常现象，原因如下：
+
+### 1. 协议栈实现位置不同
+
+| 协议 | 实现位置 | 特点 |
+|------|----------|------|
+| TCP  | **内核空间** | 高度优化，零拷贝，硬件卸载 |
+| QUIC | **用户空间** | 需要系统调用，数据拷贝开销大 |
+
+TCP 在 Linux 内核中经过 30+ 年优化，支持：
+- **零拷贝 (Zero-copy)**：`sendfile()`, `splice()` 等
+- **硬件卸载 (TSO/GSO)**：网卡直接分段
+- **内核旁路优化**：减少上下文切换
+
+### 2. 加密开销
+
+QUIC **强制加密**所有数据（使用 TLS 1.3），而本实验中的 TCP 是明文传输：
+
+```
+QUIC 数据路径: 应用数据 → TLS加密 → UDP封装 → 发送
+TCP 数据路径:  应用数据 → TCP封装 → 发送
+```
+
+加密/解密操作消耗大量 CPU 资源。
+
+### 3. UDP vs TCP 的系统调用效率
+
+| 操作 | TCP | QUIC (UDP) |
+|------|-----|------------|
+| 发送 100MB | 少量大块 write() | 大量小包 sendto() |
+| 系统调用次数 | 少 | 多 |
+
+TCP 可以一次 `write()` 发送大块数据，内核自动分段。QUIC 基于 UDP，每个数据包都需要单独的 `sendto()` 调用。
+
+### 4. 数据包大小限制
+
+```c
+#define MAX_DATAGRAM_SIZE 1350  // QUIC 单包最大载荷
+```
+
+QUIC 受 UDP MTU 限制，每个包最多 ~1350 字节。发送 100MB 需要约 **77,000+ 个数据包**。
+
+### 5. 本地回环测试的特殊性
+
+在 `localhost` 测试中，网络延迟几乎为零，TCP 的内核优化优势被放大。QUIC 的优势（如 0-RTT、连接迁移、多路复用）在这种环境下无法体现。
+
+### 6. QUIC 真正的优势场景
+
+QUIC 设计目标不是追求极限吞吐量，而是在**真实网络环境**中提供更好的用户体验：
+
+| 场景 | QUIC 优势 |
+|------|-----------|
+| 高延迟网络 | 0-RTT 快速连接建立 |
+| 丢包环境 | 无队头阻塞，单流丢包不影响其他流 |
+| 移动网络 | 连接迁移，切换 WiFi/4G 不断连 |
+| 多路复用 | 单连接多流，避免 TCP 队头阻塞 |
+
+从你的日志可以看到，在 **100ms 延迟**环境下：
+- TCP: 0.98 MB/s
+- QUIC: 2.41 MB/s
+
+**QUIC 在高延迟环境下性能是 TCP 的 2.5 倍！**
+
+---
+
+## 总结
+
+| 环境 | TCP | QUIC | 胜者 |
+|------|-----|------|------|
+| 本地回环 (无延迟) | ~1400 MB/s | ~92 MB/s | TCP |
+| 100ms 延迟 | 0.98 MB/s | 2.41 MB/s | **QUIC** |
+
+**结论：** QUIC 在理想网络环境下吞吐量低于 TCP 是正常的，这是用户空间实现、强制加密等设计权衡的结果。但在真实的高延迟、高丢包网络环境中，QUIC 能够提供更好的性能和用户体验。