1. 课程定位与整体设计思路拆解
1.1 为什么传统计算机网络课程必须动刀
我教了几年计算机网络，也参与过几轮课程大纲的修订，最直观的感受就是：学生越来越难被“协议分层”这四个字打动。以前讲OSI七层模型，学生还会认真记笔记，现在他们更关心的是——这些协议跟我用的大模型有什么关系？我训练一个模型，网络到底在哪个环节拖了我的后腿？
这个项目标题“面向生成式人工智能的计算机网络课程建设”，核心要解决的就是这个断层。传统计算机网络课程的知识体系是围绕“端到端通信”建立的，从物理层的信号编码，到应用层的HTTP、DNS，整条链路非常完整。但生成式AI带来的负载特征完全不一样：大模型训练需要的是高带宽、低延迟、无损的RDMA网络；推理服务需要的是高并发、弹性伸缩的容器网络；分布式训练还涉及集合通信库在底层对网络拓扑的极致压榨。
如果课程还是只讲TCP三次握手、滑动窗口、CSMA/CD，学生学完之后面对一个真实的GPU集群网络问题，根本无从下手。所以这个课程建设的第一个设计决策就是：保留经典网络原理的骨架，但把血肉换成生成式AI场景下的真实问题。
具体来说，我做了这样的取舍：物理层和数据链路层的内容压缩到原来的60%，但增加了“数据中心网络拓扑与布线”的模块；网络层保留IP路由的核心逻辑，但把重点从“互联网路由协议”转向“集群内路由与拥塞控制”；传输层是重头戏，TCP要讲，但更要讲RDMA over Converged Ethernet和InfiniBand的传输机制；应用层则直接对接gRPC、NCCL通信、参数服务器等实际框架。
这个取舍背后的逻辑很简单：学生毕业后如果去搞AI基础设施，他每天面对的不是“为什么我的网页打不开”，而是“为什么我的AllReduce操作延迟突然飙升”。课程必须让他有能力回答后一个问题。
1.2 课程模块的划分与学时分配
整个课程我设计成六个模块，总学时48小时，其中理论32小时，实验16小时。这个比例是经过两轮试讲后调整出来的，第一轮理论给了40小时，结果学生反馈“听懂了但不会做”，所以第二轮大幅增加了实验比重。
| 模块 | 核心内容 | 理论学时 | 实验学时 |
|---|---|---|---|
| 网络基础与AI负载特征 | 分层模型、带宽延迟积、AI训练/推理流量模式 | 6 | 2 |
| 数据中心网络 | 叶脊架构、RDMA、无损网络、拥塞控制 | 8 | 4 |
| 分布式通信与集合操作 | NCCL、MPI、AllReduce、参数服务器 | 6 | 4 |
| 容器与编排网络 | CNI、Overlay、Service Mesh、K8s网络 | 6 | 2 |
| 网络性能调优 | 抓包分析、带宽测试、延迟测量、瓶颈定位 | 4 | 4 |
| 前沿专题 | 在网计算、可编程交换机、光互连 | 2 | 0 |
这个表格里的学时分配不是拍脑袋定的。数据中心网络给了8+4，是因为这是生成式AI最吃网络的部分，也是学生最容易踩坑的地方。分布式通信给了6+4，因为集合操作的性能直接决定训练效率，而且这部分内容在传统课程里几乎不涉及。容器网络给了6+2，因为现在推理服务基本都跑在K8s上，不懂CNI和Overlay，连服务发现都搞不定。
注意：实验学时的分配要留出至少2小时的“自由排障”时间，不要把所有实验都设计成按步骤操作。真实网络问题从来不是按步骤出现的，让学生自己面对一个“训练任务卡住了”的场景，比让他照着文档配一遍RDMA更有价值。
1.3 与生成式AI工作流的对接点
课程建设的另一个核心思路是：每一个网络知识点都要找到一个生成式AI工作流中的锚点。没有锚点的知识点，要么删掉，要么压缩成背景阅读材料。
举个例子，讲TCP拥塞控制的时候，传统讲法是慢启动、拥塞避免、快重传、快恢复。我在课上会先放一段真实训练任务的网络监控图，让学生看到：当多个GPU节点同时进行AllReduce时，TCP的拥塞窗口波动会导致集合通信时间抖动，进而拖慢整个训练步。然后我再讲为什么RDMA的基于信用的流控能解决这个问题。这样学生就明白了：不是TCP不好，而是场景变了，需求变了。
再比如讲DNS，传统讲法是递归查询、迭代查询、缓存机制。我会把它接到“推理服务的服务发现”上：当一个推理请求到达网关，网关需要把请求路由到某个模型实例，这个过程中服务注册与发现机制是怎么工作的，DNS在容器环境里扮演什么角色，CoreDNS的性能瓶颈在哪里。这样DNS就不再是一个孤立的协议，而是推理链路的一环。
这种对接方式的好处是，学生学完之后，脑子里有一张“AI系统网络全景图”，而不是一堆散落的协议知识点。他遇到一个新问题，知道该从哪个层面去排查，该用哪个工具去验证。
2. 核心细节解析与实操要点
2.1 数据中心网络拓扑的讲法与实验设计
叶脊架构是数据中心网络的基础，但很多教材讲得太抽象。我的做法是先用一个生活化类比：叶脊架构就像一个大城市的交通网络，叶交换机是各个小区门口的道路，脊交换机是城市主干道。小区内部的车流不会直接上主干道，而是先汇聚到叶交换机，再根据目的地选择走哪条脊交换机。这样任何两个小区之间的通信，最多只需要经过三跳。
讲完类比之后，我会带学生做一个纸面设计练习：假设有一个64节点的GPU集群，每个节点需要200Gbps的带宽，要求任意两个节点之间的通信延迟不超过10微秒，请设计一个叶脊拓扑，并计算需要多少台叶交换机、多少台脊交换机、多少条上行链路。
这个练习的答案不是唯一的，但有一个合理的计算过程。假设每台叶交换机有32个200Gbps下行端口和8个400Gbps上行端口，那么一台叶交换机可以连接32个节点。64个节点需要2台叶交换机。每台叶交换机有8条400Gbps上行链路，总上行带宽是3.2Tbps。如果脊交换机有32个400Gbps端口，那么一台脊交换机可以连接4台叶交换机（因为每台叶交换机占用8个端口）。为了冗余，至少需要2台脊交换机。所以最终方案是2台叶交换机、2台脊交换机，每台叶交换机用4条上行链路分别连接到2台脊交换机。
这个计算过程我会让学生在课上自己推一遍，然后我再讲实际部署中还要考虑的问题：比如线缆长度限制、光模块兼容性、供电和散热、以及最关键的——收敛比。收敛比是下行总带宽与上行总带宽的比值，这个比值决定了网络在突发流量下的表现。对于AI训练集群，收敛比通常要做到1:1或者接近1:1，因为AllReduce操作会产生大量的突发流量。
实验环节我设计了一个基于开源工具的拓扑模拟：用容器模拟交换机和主机，用Linux的流量控制工具模拟链路带宽和延迟，然后让学生用iperf3和ping测试不同拓扑下的吞吐和延迟。这个实验不需要真实的交换机，但能让学生直观感受到拓扑对性能的影响。
实操心得：在模拟实验里，一定要让学生手动设置MTU。默认的1500字节MTU在RDMA场景下会导致大量的分片，性能直接腰斩。把MTU调到9000（巨帧）之后，同样的流量模式，吞吐能提升30%以上。这个对比实验学生做一次就记住了。
2.2 RDMA与无损网络的原理拆解
RDMA是生成式AI网络里绕不开的技术，但也是最难讲清楚的技术之一。我的讲法是先从问题出发：为什么TCP在AI训练场景下不够用？
核心原因是TCP的内核协议栈处理开销太大。每一次数据包的处理都要经过内核态到用户态的拷贝，还要经过中断处理、协议解析、拥塞控制等环节。在100Gbps以上的带宽下，CPU根本来不及处理这么多包，大量的时间花在了协议栈上，而不是真正的数据传输上。
RDMA的思路是：把网络协议栈的处理卸载到网卡上，数据直接从一台机器的用户态内存传输到另一台机器的用户态内存，完全不经过CPU和内核。这就像从“快递员把包裹送到小区门口，你自己下楼去取”变成了“快递员直接把包裹放进你家冰箱”。
但RDMA要跑在以太网上，就面临一个根本矛盾：以太网天生是有损的，而RDMA假设网络是无损的。解决这个矛盾的技术就叫RoCE（RDMA over Converged Ethernet）。RoCEv2通过UDP封装RDMA数据包，然后在网络层实现基于优先级的流控（PFC）和显式拥塞通知（ECN）。
PFC的原理是：当交换机的一个端口缓冲区快满的时候，它向上一跳发送一个暂停帧，告诉对方“先别发了，等我缓一缓”。这个机制能保证不丢包，但有个副作用——队头阻塞。如果暂停帧发得太频繁，整个链路都会被拖慢。所以PFC的阈值设置非常关键，设得太低会频繁暂停，设得太高会丢包。
ECN则是另一种思路：交换机在缓冲区快满的时候，不是暂停发送，而是在数据包里打一个标记，接收方收到标记后通知发送方降速。这种方式更平滑，但需要端侧协议栈的支持。
我在课上会用一个表格来对比这两种机制：
| 机制 | 触发条件 | 动作 | 优点 | 缺点 |
|---|---|---|---|---|
| PFC | 缓冲区超过阈值 | 发送暂停帧 | 保证不丢包 | 可能队头阻塞 |
| ECN | 缓冲区超过阈值 | 标记数据包 | 平滑降速 | 需要端侧支持 |
实验环节我设计了一个RoCE配置实验：用两台服务器，各插一张支持RoCE的网卡，通过一台支持PFC和ECN的交换机连接。然后让学生分别配置PFC和ECN，用perftest工具测试RDMA的带宽和延迟，对比两种机制下的性能差异。
这个实验的难点在于网卡和交换机的配置。不同厂商的网卡配置命令不一样，交换机更是各家有各家的语法。我的建议是：实验环境尽量统一用同一品牌的设备，减少兼容性问题。如果条件有限，可以用软RoCE（Soft-RoCE）来模拟，虽然性能差很多，但原理和配置流程是一样的。
注意：配置PFC的时候，一定要确认整个链路上的所有设备都支持并正确配置了PFC。只要有一个环节没配，PFC就不会生效，而且不会报错，只是性能上不去。这个坑我踩过好几次，排查起来非常费时间。
2.3 集合通信与NCCL的实操解析
集合通信是分布式训练的核心，NCCL是NVIDIA的集合通信库，也是目前用得最广泛的。但很多学生只知道NCCL快，不知道它为什么快，更不知道什么时候会慢。
NCCL的核心优化在于它能够根据网络拓扑自动选择最优的通信算法。比如AllReduce操作，NCCL会根据节点数量、GPU数量、网络带宽和延迟，在Ring、Tree、CollNet等算法之间做选择。Ring算法适合节点数较少、带宽均匀的场景；Tree算法适合节点数多、带宽不均匀的场景；CollNet则是利用交换机或在网计算能力来加速。
我在课上会让学生做一个实验：用4台服务器，每台4张GPU，总共16张GPU，跑一个AllReduce操作。然后分别用NCCL的Ring算法和Tree算法，测量不同消息大小下的通信时间。学生会发现：小消息下Tree更快，大消息下Ring更快。这个结论和NCCL的自动选择逻辑是一致的。
实验的具体步骤是这样的：
# 设置NCCL使用的算法 export NCCL_ALGO=Ring # 或者 export NCCL_ALGO=Tree # 运行AllReduce测试 ./all_reduce_perf -b 8 -e 128M -f 2 -g 4这个命令会从8字节开始，每次翻倍，一直测到128MB，测量不同消息大小下的通信带宽和延迟。学生会看到一条曲线：小消息下延迟主导，大消息下带宽主导。然后我会让他们把NCCL_ALGO改成Tree，再跑一遍，对比两条曲线的差异。
这个实验的价值在于，它让学生直观理解了“算法选择不是拍脑袋，而是有数据支撑的”。以后他们在实际工作中遇到通信瓶颈，就知道该从哪里入手去调优。
实操心得：NCCL的日志非常有用。设置NCCL_DEBUG=INFO之后，NCCL会打印出它选择的算法、使用的通道数、以及每个通道的带宽。这些信息是排查通信问题的第一手资料。我建议学生在跑任何分布式训练任务之前，都先开NCCL_DEBUG=INFO跑一遍小规模的测试，确认通信路径是符合预期的。
2.4 容器网络与推理服务的对接
生成式AI的推理服务现在基本都跑在Kubernetes上，这就涉及容器网络的问题。传统网络课程不讲容器网络，但学生如果不懂CNI、Overlay、Service Mesh，连一个推理服务都部署不起来。
容器网络的核心问题是：容器需要有自己的IP地址，需要能够跨节点通信，需要能够被服务发现机制找到。Kubernetes通过CNI插件来解决第一个问题，通过Overlay网络来解决第二个问题，通过Service和Ingress来解决第三个问题。
我在课上会重点讲三种CNI插件的区别：Calico、Flannel、Cilium。Calico基于BGP路由，性能好但配置复杂；Flannel基于VXLAN Overlay，配置简单但有封装开销；Cilium基于eBPF，性能最好但需要较新的内核版本。
| CNI插件 | 实现方式 | 性能 | 配置复杂度 | 适用场景 |
|---|---|---|---|---|
| Calico | BGP路由 | 高 | 中 | 大规模集群 |
| Flannel | VXLAN Overlay | 中 | 低 | 中小规模集群 |
| Cilium | eBPF | 最高 | 高 | 性能敏感场景 |
实验环节我设计了一个对比实验：在同一个K8s集群里，分别用Flannel和Calico部署两个推理服务，然后用wrk或者hey工具压测，对比两种CNI下的吞吐和延迟。学生会发现Calico的延迟明显低于Flannel，因为Flannel的VXLAN封装会增加额外的头部开销，而且封包解包会消耗CPU。
这个实验的另一个目的是让学生理解：网络性能不是孤立的，它和CPU、内存、存储都有关系。Flannel的封装开销最终会体现在CPU使用率上，如果CPU本身就很紧张，网络性能会进一步下降。
注意：在生产环境里，CNI插件的选择往往不是单纯看性能，还要考虑运维成本、社区活跃度、与现有监控体系的兼容性。Calico虽然性能好，但BGP的运维门槛不低；Cilium虽然性能最好，但对内核版本有要求，老旧的K8s集群可能跑不起来。这些取舍在课上要讲清楚，不能只讲技术不讲工程。
3. 实操过程与核心环节实现
3.1 实验环境搭建的完整流程
整个课程的实验环境我设计成两层：一层是本地虚拟机环境，用于基础实验；一层是远程GPU集群环境，用于分布式通信实验。本地环境用Vagrant加VirtualBox搭建，远程环境用容器化的方式模拟。
本地环境的搭建步骤如下：
# 初始化Vagrant环境 vagrant init ubuntu/focal64 vagrant up # 登录虚拟机 vagrant ssh # 安装基础工具 sudo apt update sudo apt install -y iproute2 tcpdump iperf3 net-tools # 配置网络命名空间模拟多主机 sudo ip netns add host1 sudo ip netns add host2 sudo ip link add veth1 type veth peer name veth2 sudo ip link set veth1 netns host1 sudo ip link set veth2 netns host2这个环境可以模拟两台主机之间的通信，学生可以在里面做TCP拥塞控制、路由配置、抓包分析等实验。网络命名空间的好处是隔离性好，一台机器上可以模拟出多台主机的效果，而且不会影响宿主机的网络配置。
远程GPU集群环境我用的是容器化的方案：用Docker容器模拟GPU节点，用NCCL的容器镜像来跑集合通信测试。这个方案的好处是不需要真实的GPU，用CPU也能跑通NCCL的通信逻辑，只是性能数据没有参考价值。但对于理解通信算法和排查配置问题来说，已经足够了。
# 拉取NCCL测试镜像 docker pull nvcr.io/nvidia/pytorch:23.10-py3 # 启动两个容器模拟两个节点 docker run -d --name node1 --network host nvcr.io/nvidia/pytorch:23.10-py3 docker run -d --name node2 --network host nvcr.io/nvidia/pytorch:23.10-py3 # 在容器内运行AllReduce测试 docker exec -it node1 bash # 在容器内执行 ./all_reduce_perf -b 8 -e 128M -f 2 -g 1这个实验的关键是让两个容器能够互相通信。用host网络模式是最简单的，但会占用宿主机的端口。如果要做更真实的模拟，可以用自定义的Docker网络，然后配置静态IP和路由。
实操心得：在容器里跑NCCL测试的时候，一定要设置NCCL_SOCKET_IFNAME环境变量，指定使用哪个网络接口。如果不设置，NCCL可能会选错接口，导致通信失败或者性能极差。这个坑我踩过，排查了半天才发现是接口选错了。
3.2 网络性能测试与瓶颈定位
网络性能测试是课程里最实用的部分。我教学生用三个工具：iperf3测带宽，ping和hping3测延迟，tcpdump和Wireshark抓包分析。
iperf3的用法很简单，但参数选择有讲究：
# 服务端 iperf3 -s # 客户端，测试TCP带宽 iperf3 -c 192.168.1.100 -t 30 -P 4 # 客户端，测试UDP带宽和丢包 iperf3 -c 192.168.1.100 -u -b 1G -t 30这里的-P 4表示用4个并行连接。为什么要用并行连接？因为单个TCP连接的带宽往往受限于拥塞窗口和往返延迟，达不到链路的物理带宽。用多个连接可以绕过这个限制，更准确地测量链路的最大吞吐。
UDP测试则用来测量丢包率。在RDMA场景下，丢包是致命的，因为RDMA假设网络是无损的。如果UDP测试发现丢包，就要去排查是链路问题、交换机缓冲区问题，还是PFC配置问题。
延迟测试用ping就够了，但要注意ping的默认间隔是1秒，测不出微突发。如果要测微突发，可以用hping3：
# 每秒发送1000个包，测量延迟分布 hping3 -c 10000 -i u1000 192.168.1.100这个命令会每1000微秒发送一个包，总共发送10000个包。然后看延迟的分布，如果延迟抖动很大，说明网络存在拥塞或者缓冲区不足的问题。
抓包分析是排查网络问题的终极手段。我教学生用tcpdump抓包，然后用Wireshark分析。重点看几个东西：TCP的重传率、乱序率、零窗口通告、以及RDMA的PFC暂停帧。
# 抓取RDMA相关的包 tcpdump -i eth0 -w rdma.pcap 'udp port 4791' # 抓取TCP重传 tcpdump -i eth0 -w tcp.pcap 'tcp[tcpflags] & tcp-retransmit != 0'注意：抓包会消耗大量的CPU和磁盘IO，在生产环境里要谨慎使用。如果一定要抓，建议用环形缓冲区，限制抓包文件的大小和数量。另外，抓包的时间点很关键，最好在问题复现的时候抓，而不是事后抓。
3.3 分布式训练通信的调优实操
分布式训练的通信调优是课程的高阶内容。我设计了一个完整的调优流程：先测量基线性能，然后逐步调整参数，观察性能变化，最后找到最优配置。
基线测量用NCCL的all_reduce_perf工具，测量不同消息大小下的带宽和延迟。然后调整以下参数：
- NCCL_ALGO：选择Ring、Tree或CollNet
- NCCL_PROTO：选择LL、LL128或Simple
- NCCL_NTHREADS：每个GPU的通信线程数
- NCCL_MIN_NCHANNELS：最小通道数
- NCCL_MAX_NCHANNELS：最大通道数
这些参数的组合非常多，不可能全部穷举。我的做法是先用默认配置跑一遍，然后根据瓶颈类型来调整。如果瓶颈是延迟，就尝试Tree算法和LL协议；如果瓶颈是带宽，就尝试Ring算法和Simple协议，并增加通道数。
# 基线测试 ./all_reduce_perf -b 8 -e 128M -f 2 -g 8 # 调整算法和协议 export NCCL_ALGO=Tree export NCCL_PROTO=LL ./all_reduce_perf -b 8 -e 128M -f 2 -g 8 # 增加通道数 export NCCL_MIN_NCHANNELS=8 export NCCL_MAX_NCHANNELS=16 ./all_reduce_perf -b 8 -e 128M -f 2 -g 8这个调优过程学生会发现：没有一组参数是万能的。小消息下最优的参数，大消息下可能不是最优的。所以实际训练中，往往需要根据消息大小的分布来折中。如果训练任务里小消息多，就偏向延迟优化；如果大消息多，就偏向带宽优化。
实操心得：NCCL的调优不要一次改太多参数，否则你根本不知道是哪个参数起了作用。我的习惯是一次只改一个参数，记录性能变化，然后再改下一个。虽然慢一点，但能积累出可靠的调优经验。
3.4 推理服务的网络配置实操
推理服务的网络配置和训练不一样，训练关注的是高带宽和低延迟，推理关注的是高并发和弹性伸缩。我设计了一个基于K8s的推理服务部署实验，让学生从零搭建一个推理服务，并配置网络。
实验步骤大致如下：
# 部署一个简单的推理服务 kubectl create deployment inference --image=nginx --replicas=3 # 暴露服务 kubectl expose deployment inference --port=80 --target-port=80 --type=ClusterIP # 查看服务 kubectl get svc inference # 测试服务发现 kubectl run test --image=busybox --rm -it -- wget -qO- http://inference这个实验看起来简单，但里面涉及了K8s网络的核心概念：Pod网络、Service网络、DNS解析、kube-proxy的负载均衡。学生会发现，从test Pod访问inference Service，请求会被kube-proxy转发到后端的某个Pod上。这个转发过程在iptables模式下是通过iptables规则实现的，在IPVS模式下是通过IPVS实现的。
然后我会让学生把Service类型改成NodePort，再从集群外部访问，观察网络路径的变化。再改成LoadBalancer，如果有云环境的话，观察云厂商的负载均衡器是怎么工作的。
这个实验的延伸是配置Ingress和Service Mesh。Ingress负责七层路由，可以根据URL路径把请求转发到不同的后端服务。Service Mesh则提供了更细粒度的流量控制、熔断、限流等功能。这些内容在传统网络课程里不讲，但在实际的推理服务部署中非常常见。
注意：K8s的网络模型有一个核心原则：每个Pod都有自己的IP地址，Pod之间可以直接通信，不需要NAT。这个原则和传统的虚拟机网络模型不一样，学生在理解的时候容易混淆。我在课上会反复强调这一点，并用实际的抓包数据来验证。
4. 常见问题与排查技巧实录
4.1 网络性能不达标的排查思路
网络性能不达标是最常见的问题，但排查起来往往没有头绪。我总结了一个排查顺序：先看物理层，再看链路层，再看网络层，最后看传输层和应用层。
物理层的问题包括：光模块不兼容、线缆质量差、接口协商速率不对。排查方法是看网卡的统计信息：
# 查看网卡统计 ethtool -S eth0 | grep -i error ethtool eth0 | grep -i speed如果看到大量的CRC错误或者丢包，基本可以确定是物理层的问题。这时候要检查光模块的型号是否匹配，线缆是否插紧，接口的协商速率是否和预期一致。
链路层的问题包括：MTU不匹配、VLAN配置错误、STP环路。MTU不匹配是常见问题，尤其是在RDMA场景下。如果一端配了9000的MTU，另一端还是1500，大包就会被丢弃。排查方法是ping大包：
# 测试MTU ping -M do -s 8972 192.168.1.100如果这个命令失败，说明路径上的MTU小于9000。需要逐跳排查，找到MTU最小的那一跳。
网络层的问题包括：路由配置错误、ARP表项过期、ACL拦截。排查方法是看路由表和ARP表：
ip route show ip neigh show传输层的问题包括：TCP拥塞窗口太小、重传率太高、零窗口通告。排查方法是看TCP的统计信息：
ss -ti netstat -s | grep -i retrans应用层的问题包括：应用配置错误、线程池太小、序列化开销太大。排查方法是看应用的日志和性能指标。
这个排查顺序的逻辑是：从底层到上层，从简单到复杂。物理层和链路层的问题往往最容易排查，也最容易解决。如果底层没问题，再往上查。
实操心得：排查网络问题的时候，一定要先确认“问题是不是网络引起的”。我见过很多次，应用性能差，大家第一反应是网络问题，结果查了半天发现是数据库慢查询。所以第一步应该是看应用的性能指标，确认瓶颈确实在网络层。
4.2 RDMA配置的常见坑与解决方法
RDMA配置的坑特别多，我整理了一个速查表：
| 问题现象 | 可能原因 | 排查方法 | 解决方法 |
|---|---|---|---|
| RDMA连接建立失败 | 网卡不支持RoCE | ibv_devinfo | 换支持RoCE的网卡 |
| 带宽远低于预期 | PFC未配置 | 检查交换机PFC配置 | 配置PFC |
| 延迟抖动大 | ECN未配置 | 检查交换机ECN配置 | 配置ECN |
| 间歇性丢包 | MTU不匹配 | ping大包 | 统一MTU |
| 性能突然下降 | 网卡固件bug | 查看网卡日志 | 升级固件 |
这个表里的每一个问题我都实际遇到过。最坑的是“带宽远低于预期”这一条，因为PFC没配的时候，RDMA不会报错，只是性能上不去。你去看网卡状态，一切正常；你去看交换机状态，也一切正常。但就是跑不满带宽。后来用抓包工具看，发现大量的PFC暂停帧没有被正确处理，才知道是PFC配置的问题。
另一个坑是MTU不匹配。RDMA默认用巨帧，但如果路径上有一台设备的MTU没改，大包就会被分片或者丢弃。分片会严重降低性能，丢弃则会导致重传。排查方法是逐跳ping大包，找到MTU最小的那一跳。
注意：RDMA的配置一定要在实验环境里先验证，再上生产。生产环境里改RDMA配置的风险很高，一旦配错，可能导致整个集群的网络中断。我建议在变更之前，先准备好回滚方案，并且选择业务低峰期操作。
4.3 分布式训练通信超时的排查
分布式训练通信超时是另一个常见问题。现象是训练任务卡住，日志里出现NCCL timeout或者socket timeout。排查思路如下：
首先看NCCL的日志。设置NCCL_DEBUG=INFO之后，NCCL会打印出详细的通信过程。如果看到某个rank一直卡在某个操作上，说明那个rank可能有问题。
export NCCL_DEBUG=INFO export NCCL_DEBUG_SUBSYS=ALL然后看网络连通性。用ping和iperf3测试所有节点之间的连通性和带宽。如果某个节点之间的带宽异常低，说明那个节点的网络有问题。
再看GPU的状态。用nvidia-smi查看GPU的使用率和显存占用。如果某个GPU的使用率一直是0，说明那个GPU可能没有被正确初始化。
最后看系统日志。用dmesg查看内核日志，看有没有网卡或者GPU的报错。
dmesg | grep -i error dmesg | grep -i eth dmesg | grep -i nvidia这个排查流程的关键是：先确认是哪个节点的问题，再确认是哪个组件的问题。分布式训练涉及多个节点、多个GPU、多个网络接口，问题可能出现在任何一个环节。缩小范围是排查的第一步。
实操心得：分布式训练的超时问题，很多时候不是网络本身的问题，而是某个节点的GPU出了问题，导致整个集合通信卡住。所以排查的时候，不要只盯着网络看，也要看GPU和CPU的状态。我遇到过好几次，最后发现是某张GPU的显存坏了，导致NCCL操作无法完成。
4.4 容器网络的典型故障与修复
容器网络的故障往往比较隐蔽，因为容器网络是叠加在宿主机网络之上的，问题可能出现在任何一层。我整理了几个典型故障：
故障一：Pod无法访问Service。排查方法是先看Pod的DNS解析是否正常，再看kube-proxy的规则是否正确。
# 在Pod内测试DNS nslookup kubernetes.default # 查看kube-proxy的iptables规则 iptables -t nat -L KUBE-SERVICES -n故障二：Pod之间跨节点通信失败。排查方法是看CNI插件的日志，以及节点的路由表。
# 查看CNI插件日志 journalctl -u kubelet | grep -i cni # 查看路由表 ip route show故障三：Service的负载均衡不生效。排查方法是看Endpoints是否正确，以及kube-proxy的模式是iptables还是IPVS。
# 查看Endpoints kubectl get endpoints # 查看kube-proxy模式 kubectl logs -n kube-system kube-proxy-xxx | grep -i mode这些故障的修复方法各不相同，但排查思路是一致的：先确认问题出在哪一层，再针对那一层去排查。容器网络的问题往往需要结合宿主机网络和容器网络一起看，不能只看一边。
注意：在K8s集群里排查网络问题，一定要用“最小复现”的原则。先创建一个最简单的Pod，测试最基本的连通性，然后逐步增加复杂度。不要一上来就在复杂的应用里排查，那样变量太多，很难定位问题。
5. 课程建设的经验总结与迭代方向
5.1 两轮试讲后的反馈与调整
这个课程我试讲了两轮，第一轮偏理论，学生反馈“听懂了但不会做”；第二轮增加了实验比重，学生反馈“实验太多，理论没讲透”。第三轮我做了折中：理论部分用真实案例驱动，每个知识点都配一个实际场景；实验部分分层次，基础实验必做，进阶实验选做。
具体调整包括：把TCP拥塞控制的理论课时从4小时压缩到2小时，但增加了一个“用Wireshark分析真实训练任务的TCP重传”的实验；把RDMA的理论课时从2小时增加到4小时，因为学生反馈这部分最难理解；把容器网络从选修改为必修，因为推理服务部署的需求太普遍了。
这个调整过程让我意识到：课程建设不是一锤子买卖，需要根据学生的反馈持续迭代。而且不同背景的学生需求不一样，有的偏研究，有的偏工程，课程设计要尽量兼顾。
5.2 后续可以扩展的方向
这个课程目前覆盖了生成式AI网络的主要方面，但还有一些方向可以扩展。比如在网计算，利用可编程交换机在网络上直接做聚合操作，可以进一步降低集合通信的延迟。再比如光互连，用光交换代替电交换，可以大幅提升带宽和降低功耗。
这些方向目前还在研究中，但已经有一些初步的成果。我打算在下一轮课程里增加一个前沿专题，邀请做相关研究的同行来做一个讲座，让学生了解最新的技术动态。
另外，我还在考虑把课程内容开源出去，让更多的学生和从业者能够受益。开源的难点在于实验环境的搭建，因为不同的硬件和软件环境差异很大。我打算先开源理论部分的讲义和实验指导书，实验环境则提供容器化的方案，降低复现的门槛。
这个课程建设的过程让我深刻体会到：网络技术正在从“连接互联网”转向“连接算力”，而生成式AI是推动这个转变的核心力量。作为网络课程的教师，我们需要跟上这个变化，把最新的技术和最真实的问题带进课堂。
