简介高级计算机网络课程第一章“计算机网络与Internet1-2”课件PDF对应谢希仁教授网络原理教材中关于计算机网络发展过程与分组交换产生背景的核心内容适合正在学习互联网体系结构、需要夯实分组交换与电路交换差异的高校学生或自学者。资料以课件形式呈现重点回顾了20世纪60年代ARPA网研究背景、电路交换的三个阶段及其传送突发性计算机数据的低效性并逐步拆解分组交换的“报文划分—分组封装—存储转发—还原报文”全过程配合多张示意图帮助理解结点交换机、分组首部地址等信息。全部内容共1个PDF文件整体12.63MB可直接在电脑或手机上阅读。该课件已有51人学习浏览适合作为课前预习、课后复习或备课参考通过原理对比与流程图解提升对Internet基础机制的系统认知。1. 高级计算机网络第一课为什么还要从“计算机网络与Internet”讲起不少做了五年以上运维或网络开发的朋友翻回高级计算机网络课件时会对“计算机网络与Internet”这一节产生落差感第一反应是这不就是本科教材开篇的定义吗但实际上一旦你带过线上故障、调过跨云专线、拆过容器网络再看第一章第 1-2 节的叙述方式会发现它并不在复述“Internet 是网络的网络”这种常识而是把整门课后面要用的坐标系一次性铺开网络边缘、接入网、网络核心、分组交换、时延组成、协议层次。这一课真正能解决的问题是把“Internet”从一个笼统的产品词变成一个可以观测、可以分段、可以逐层验证的技术对象。适合的人群不是刚背完计网八股的学生而是已经在业务里见过 DHCP 分配异常、NAT 会话表溢出、MTU 不一致导致 HTTPS 闪断的工程师。你缺的不是“哪一层是什么”而是“当网络不通时先看哪一层后看哪一层”的判断顺序。第一章前两节恰好就给这个顺序提供了骨架先分清边缘与核心再理解端到端连接最后把时延和吞吐量作为衡量网络行为的两个标尺。所以这篇内容不打算复述 PPT而是按这个标题常见的教学路径把理论拆成你能直接拿去验证的一套做法。2. 协议分层、网络边缘与接入网把 OSI 模型拆给运维和开发用2.1 用四层而不是七层去理解“Internet 通不通”高级计算机网络第一课通常不会让你背七层而是强调分层不是为了让协议栈长得好看而是为了在网络出问题时能定位该看哪个对象的哪些字段。你在生产环境里抓包时看得最清楚的其实只有四层链路层、网络层、传输层、应用层。七层模型里的表示层、会话层、甚至部分会话层功能今天大多已被 TLS、HTTP/2 连接复用的机制吸收你很难单独观测它们。排障时最有效的分层口径如下分层你能看到的典型对象常用观察命令应用层HTTP 状态码、DNS 响应、QUIC 流curl -v、dig传输层TCP/UDP 端口、SEQ/ACK、重传ss -tn state established网络层IP 地址、TTL、ICMP、路由选择ip route、traceroute链路层以太网地址、VLAN、ARP、接口计数ip -s link、ethtool这里要特别留意一个容易被误解的点TLS 在概念上位于应用层与传输层之间但实际抓包时它的“握手记录”既不属于 TCP 头的标准字段也不像 HTTP 报文那样直接可见。所以当客户端报错TLS handshake timeout时正确思路不是先骂安全团队而是先用ss确定 TCP 连接是否已经建立如果连接根本没建起来问题在传输层之下TLS 错误只是应用层的最终表现。下面这组命令可以在一分钟内完成分层状态检查# 查看本机监听的端口和对应的进程确认服务是否真的在监听 ss -tulnp # 查看接口状态、收发错误、丢包计数先排除链路层硬件问题 ip -s link # 抓一个 TCP SYN 握手包观察从网卡进入协议栈时会带上哪些层信息 sudo tcpdump -nn -i eth0 tcp port 443 -c 1ss -tulnp里的-u是 UDP-l是监听状态-n跳过域名解析-p显示进程号这几项在排障时最好同时带上ip -s link中的RX errors和TX errors如果持续增长说明链路层已经有物理或驱动层面的损耗这时候调整应用超时没有意义。tcpdump -c 1只抓一个包用于验证抓包路径避免在高流量接口上把会话表打满。2.2 网络边缘的“端”已经不只是 PC而是业务端点传统教材把“网络边缘”解释为主机、服务器、手机等终端设备这个定义并没有错但放在云原生环境下会误导人。今天大多数接入网络的端是容器、负载均衡器、API 网关、CDN 节点甚至是 Serverless 函数实例。它们依然遵循“端到端”的连接模型但它们的生命周期和移动性远比一台 PC 复杂。第一章讲 Internet 结构时习惯把网络看成“边缘 接入网 核心网”这个结构对云网络同样成立VPC 里的子网是边缘专线和公网出口是接入骨干网是核心。你在云上买一个负载均衡器它既是一个“端”也是一个中间设备因为客户端到它的连接和它到后端的连接是两个独立 TCP 连接。理解这一点后排障时就不会只盯客户端与 SLB 之间的抓包而会主动去对比两段连接的建立时间。应用层连接是否建立不能只看ping因为 ping 走的是 ICMP和业务走的 TCP 端口没有直接关系。更可靠的做法是用 curl 把各阶段耗时拆开curl -v --connect-timeout 3 --max-time 10 \ -o /dev/null -w \ dns%{time_namelookup} tcp%{time_connect} tls%{time_appconnect} total%{time_total}\n \ https://example.com输出里dns是域名解析耗时tcp是 TCP 三次握手完成时刻tls是 TLS 握手完成时刻。如果tcp很小但tls很大说明网络路径基本健康瓶颈在中间设备的证书卸载或 SSL 策略上如果tcp本身就超时说明边缘主机到目标服务的传输层链路有问题继续看应用层日志纯属浪费时间。2.3 端到端原则与中间盒的取舍第一章第一次把“端到端”概念引进来时通常会说网络层只负责尽力而为交付复杂的可靠性交给端系统。但今天的真实 Internet 里充斥着大量中间盒NAT、防火墙、负载均衡器、WAF、流量镜像设备。它们的存在违背了端到端原则却又是商业网络无法绕开的基础设施。高级网络课讲这段的用意不是让你去争论中间盒该不该存在而是要求你在引入任何一个中间设备时能准确说出它修改的是第几层。NAT 改的是网络层地址和传输层端口映射负载均衡器改的是 TCP 连接终点WAF 解析的是应用层内容一个误配的防火墙则可能在传输层直接丢 SYN 包。这个能力在排查“连接被重置”时尤其值钱。入口只有一条 curl 命令但错误发生在哪个中间盒、哪个节点需要逐跳确认。此时按下不表第 3 节会给出 traceroute 的方法先把分层模型的印象固定住每一层都有独立的故障现象不要把应用层报错直接等同于网络不可用。3. 网络核心、时延与丢包分组交换、排队时延和 traceroute 的测量口径3.1 分组交换与排队时延为什么链路越拥塞延迟越像指数曲线Internet 的核心是分组交换路由器不等待完整文件到达而是收到一个分组就在内存中查表、转发。每个路由器端口前面都相当于一个排队缓冲分组到达速率超过端口处理速率时排队长度就会增长。计算机网络教材常用利用率 ρ 表示链路繁忙程度ρ 越接近 1排队时延增长越陡峭而不是线性增加。这里的工程含义非常直接你用ping看到的 RTT 变大不一定意味着链路变长更可能是某一段的利用率已经进入了非线性区。带宽监控图上哪怕只有 70% 的出口利用率突发流量依然可能在毫秒级窗口内打满缓冲表现为应用侧偶发延迟高。所以高级课会把“时延”拆成四个组成部分处理时延、排队时延、传输时延、传播时延。处理时延是路由器查表和校验的时间排队时延取决于拥塞传输时延等于分组长度除以链路速率传播时延取决于物理距离。四者里只有传播时延是接近固定值的另外三者都会随流量特征改变。3.2 用固定大小报文校准链路 MTU 与传输时延实际测量中最容易忽略的是报文大小对时延的影响。一次 ping 返回时间包含发送方向的传输时延和接收方向的传输时延而传输时延与报文长度成正比所以用不同大小的 ICMP 报文可以粗略分离出“传输”和“传播”两个部分。最小的一套路测命令是# 不分片发送 1472 字节数据对应标准 1500 字节 MTU ping -M do -s 1472 -c 10 目标地址 # 再发一个稍大的包正常网络应当直接提示 Frag needed ping -M do -s 1473 -c 3 目标地址-M do表示禁止分片-s指定 ICMP 负载大小。因为 ICMP 头 8 字节、IP 头 20 字节负载 1472 加上去正好是 1500 字节如果这个包能通而-s 1473不通说明链路 MTU 是 1500且中间路由器没有开启 PMTUD 需要的 ICMP 反馈。跨云专线最常见的故障就是 MTU 不一致导致大包丢失、小包正常用这两条命令能在五分钟内给出结论。时延拆解则更复杂单个 ping 只能看到往返总时间无法区分四类时延。常见的做法是多做几组对照链路空闲时测到的 RTT 接近传播时延加传输时延业务高峰时再测RTT 增量基本来自排队时延。如果两条路径 RTT 接近但 MST 差异很大问题不在距离而在链路出口限速。3.3 traceroute 与 TTL逐跳看到的延迟哪些能信哪些不能信traceroute 是第一章网络核心内容最直接的落地工具。它通过递增 IP 头里的 TTL让每一跳路由器在丢弃分组时返回一个 ICMP Time Exceeded 报文从而看到从源到目标的路径列表。推荐在生产排查时用 TCP 模式的 traceroute而不是默认的 UDP 模式traceroute -n -T -p 443 -q 1 目标地址-n不做反向域名解析速度快且不会被 DNS 干扰-T使用 TCP SYN 探测能穿透许多对 UDP 不响应的路由器-p 443让探测包长得像普通 HTTPS 请求避免被网络策略直接丢掉-q 1每跳只探测一次先把整体路径跑出来。但要注意三个坑。第一往返路径不一定对称去程经过的跳数和回程经过的跳数可能完全不同traceroute 只反映去程。第二路由器对 ICMP 报文的处理优先级可能低于业务数据转发某跳 RTT 高不代表业务丢包也可能是该设备 CPU 对 ICMP 限速。第三设备厂商常做“最后一跳”策略你看到的最后一跳可能是目标机房边缘防火墙而不是业务服务器本体所以永远要用“端到端 curl/tcp 建连时间”作为最终结论。3.4 用抓包确认 ACK 间隔把时延量化到 TCP 链路比 ping 更精细的做法是抓包后分析 TCP ACK 时间。当你发起一次 HTTPS 请求服务端回应数据后客户端会回 ACKWireshark 的tcp.analysis.ack_rtt字段能直接给出“从发送方看到数据到收到 ACK 的间隔”。这个字段包含网络往返时间和服务端处理时间适合定位到底是网络慢还是服务端慢。# 后台抓包只抓 TCP 443 端口 sudo tcpdump -i eth0 -w rtt.pcap tcp port 443 # 发起一次真实请求 curl -o /dev/null -s https://example.com # 结束抓包 sleep 1 sudo kill %1 # 用 tshark 解析 ACK RTT 分布 tshark -r rtt.pcap -Y tcp.analysis.ack_rtt -T fields \ -e frame.number -e tcp.analysis.ack_rtt -c 20tshark 在大部分发行版中随 wireshark-common 安装如果提示找不到先安装对应包。-Y是显示过滤器-T fields指定只输出字段值-e frame.number和-e tcp.analysis.ack_rtt分别给出帧序号和 ACK 往返时间。如果同一连接的ack_rtt从 1ms 突然变成 100ms且规律出现在窗口增长之后说明瓶颈在拥塞窗口增长后的排队而不是基础链路。4. 本地制造丢包和排队用 Linux 网络命名空间复现第一章性能参数4.1 为什么用 netns 和 veth 而不是直接拔网线想理解第一章里那些参数最直接的办法是亲手造出一个“带延迟、带丢包、带带宽限制”的网络。直接在服务器网卡上执行tc qdisc add dev eth0 root netem delay 100ms很容易把自己 SSH 断掉所以我给这个主题的常规实验环境是 Linux 网络命名空间加 veth pair。这个组合能在一台 Linux 机器里模拟两台独立主机并且不影响真实对外网络。# 创建两个隔离网络命名空间 sudo ip netns add client sudo ip netns add server # 创建一对 veth 虚拟网线一端进 client一端进 server sudo ip link add veth-a type veth peer name veth-b sudo ip link set veth-a netns client sudo ip link set veth-b netns server # 配置互不可达但能直连的地址 sudo ip netns exec client ip address add 10.0.0.1/24 dev veth-a sudo ip netns exec server ip address add 10.0.0.2/24 dev veth-b sudo ip netns exec client ip link set veth-a up sudo ip netns exec server ip link set veth-b upveth pair 可以理解为一根没有中间交换机参与的虚拟网线一端发出的报文直接从另一端进入协议栈。ip netns 则相当于把 Linux 网络协议栈复制出一份命名空间内的网卡、路由表、防火墙都是独立状态。这组命令建立的是最简单的一条点到点链路和第一章里“链路”的概念完全对应。为这条链路加上延迟和丢包# 在 client 出口方向加 100ms 延迟和 10% 随机丢包只影响 client 到 server 方向 sudo ip netns exec client tc qdisc add dev veth-a root netem delay 100ms loss 10% # 实测 RTT 和丢包率 sudo ip netns exec client ping -c 10 10.0.0.2tc qdisc add ... root netem是给网卡根队列添加网络模拟器delay 100ms表示每包固定延迟 100msloss 10%表示随机丢弃 10% 的数据包。由于命令加在 client 命名空间的 veth-a 上只影响 client 到 server 的报文ping 统计结果会显示大约 200ms 的 RTT 和 10% 左右丢包。产生 200ms 的原因是请求方向延迟 100ms回复方向没有额外延迟往返合计约 200ms。实验完用下面命令清理避免残留网卡影响后续测试sudo ip netns del client sudo ip netns del server删除命名空间时veth 对端通常会被一同回收如果出现残留可以在主机上执行sudo ip link del veth-a主动清理。4.2 netem 常用参数延迟抖动、丢包模型、乱序与重复netem 不是只能做固定延迟。生产环境中的网络质量更像抖动型延迟值在一个范围内波动。可以参考下面这张参数表做组合模拟场景命令参数说明固定延迟加抖动delay 50ms 10ms延迟 50ms上下抖动 10ms更接近真实分布delay 50ms 10ms distribution normal按正态分布抖动避免均匀抖动过于机械随机丢包loss 1%均匀随机丢包连续突发丢包loss state 5%用 Gilbert 模型模拟连续丢包报文重复duplicate 1%制造重复包能触发 TCP 快速重传报文乱序reorder 25% 50%25% 报文延迟 50ms 后发出distribution normal是实践里最值得用的参数它让延迟在某个均值附近呈正态分布能模拟真实网络的排队波动而不是所有包都延迟同一个固定值。loss state则模拟衰落信道适合测拥塞控制算法在连续丢包下的反应。验证每个参数对协议的影响时建议把iperf3和tcpdump同时打开一边看吞吐曲线一边看重传标记。4.3 用 iperf3 测吞吐量结合 BDP 解释 TCP 窗口制造延迟和丢包之后下一步是测量传输层吞吐。iperf3 是最常见的工具在实验命名空间里启动服务端和客户端即可# 在 server 命名空间启动 iperf3 服务端 sudo ip netns exec server iperf3 -s -p 5201 # 在 client 命名空间发起 10 秒测试 sudo ip netns exec client iperf3 -c 10.0.0.2 -p 5201 -t 10-s是服务端模式-c是客户端模式-p指定端口-t指定测试时长。加上-w 256K可以显式指定 TCP 发送缓冲默认窗口不足时会限制吞吐。理论吞吐量等于带宽延迟积即“链路带宽乘往返时延”。一条 100ms RTT 的链路理论上需要一个 12.5MB 的 TCP 窗口才能在 1Gbps 带宽下跑满。实际测试中如果设置了 100ms 延迟但没调整窗口你会看到吞吐远远达不到链路速率这正是第一章里“时延带宽积”概念的现场证据。5. 从“Internet 无流量”到“异常流量提示”第一章结构如何指导排障顺序5.1 先判断“无 Internet”是哪一层的问题“网络已连接但无 Internet”是 IT 从业者最常遇到的表述而 Windows 任务栏是否显示地球图标未必代表真实网络状态。按照第一章的边缘与核心结构正确顺序是先确认边缘接口是否拿到有效地址再确认默认路由存在再测三层连通性最后测 DNS 和 HTTPS。下面这张表可以当速查卡现象优先怀疑层次验证命令IP 地址是 169.254.x.x链路层/DHCPip addr show能访问网关但域名解析失败DNS 层getent hosts example.com能 ping 网关不能 ping 公网 IPNAT/路由出口ping 223.5.5.5能 ping 公网 IP不能打开网页四层/应用层curl -v https://example.com223.5.5.5只是我习惯用的一个公共固定地址只要你测试环境的路由允许换任何一个可达的固定 IP 都可以。这里的核心是ping IP 只测网络层不测 DNS也不测应用层所以每层各用一个独立命令才不会越级判断。网关能通但公网不通时重点看 NAT 和默认路由# 查看默认路由是否存在下一跳是谁 ip route show default # 查看本机所有 TCP 连接数量排序判断是否有连接堆积 ss -tn state established | awk {print $4} | sort | uniq -c | sort -rn | head -20awk {print $4}取出本地地址和端口再用sort | uniq -c统计本机 IP 上建立的连接数量sort -rn按数量倒序。这条命令能迅速发现某些容器或服务是否占用了大量本地端口避免把端口耗尽误判为出口网络不通。5.2 风控系统提示“异常流量”时网络工程师要看什么如果你遇到一个第三方平台在页面上给出“系统检测到您的计算机网络中存在异常流量请稍后重新发送请求”的提示这通常不是网页语言问题而是对方的风控网关已经拒绝了这个源 IP 的请求。对网络工程师来说第一反应不是找业务方申诉而是先确认出口流量特征是否真的异常。最常见的内网原因是 NAT 会话表溢出。大量终端共享一个公网出口 IP 时每秒新建连接数一旦超过网关的 conntrack 处理能力连接跟踪表就会老化失败某些请求会以“无法建立连接”的形式被第三方感知成异常流量。查看 conntrack 状态# 查看连接跟踪统计entries 是否接近 max sudo conntrack -S # 查看两张关键内核参数 sudo sysctl net.netfilter.nf_conntrack_max sudo sysctl net.netfilter.nf_conntrack_tcp_timeout_establishedconntrack -S输出里entries是当前跟踪的连接数量insert_failed是创建连接失败次数drop是丢包计数。如果insert_failed一直在涨说明 NAT 表已经被占满需要把无用的长连接清理或调低nf_conntrack_tcp_timeout_established的数值。这个参数默认通常是五天对短连接业务来说显然过长调到 600 秒左右可以显著降低表项压力。另外运维侧还要确认发出的报文里面有没有明显畸形的扫描特征。生产环境里被植入挖矿程序后主机对外发起大量随机目标端口连接也会被上游风控定义为异常流量。这时用ss -tn state syn-sent检查大量未完成连接即可看到端倪发现业务连接数异常再逐台排查不要只动防火墙规则。5.3 路径不对称导致 traceroute 假象traceroute 显示某段 RTT 高不一定代表端到端连接差。Internet 的路由是逐跳独立决策的去程可能走 A 运营商回程可能走 B 运营商同一台设备的 ICMP 响应速度也和设备控制面负载强相关。所以第一章里提到的“网络核心”从来不是一条固定管道而是一组动态决策的点。更可靠的收束方式是同时看两段traceroute 对应网络层路径curl 的time_connect对应真实 TCP 建连时间。如果 curl 显示 TCP 建连只有 20ms而 traceroute 有一跳显示 60ms那基本可以忽略 traceroute 上那跳的延迟因为它大概率不是业务路径上的瓶颈。MTR 连续探测比单次 traceroute 更有参考价值mtr -rwzc 100 目标地址-r是报告模式-w输出宽表格-z同时显示 AS 号-c 100每跳发送 100 个探测包。最终看的是各跳的 loss% 列而不是某一次 RTT 的最大值只要目标是可访问的丢包集中在少量跳数上通常只是路由器控制面限速端到端丢包率才是业务真实体感。这个排障动作对应到第一章结构里就是典型的“先分层、再分段”第一段是本机到网关第二段是从网关到 ISP 边界第三段是从骨干到目标边界最后一段是目标边界到业务节点。每一段的判定标准不同不能混在一起说“网络卡”。6. 验证你是否听懂第一章三条命令把边缘、核心与时延测一遍这门课学完最有价值的检验方式不是做课后判断题而是现场做一次小实验。下面三条命令分别对应网络边缘接口、网络核心路径、时延带宽积三个知识点能在半个小时内完成自测。第一条验证边缘接口和链路层用 ethtool 看网卡协商速率和丢包计数。ethtool eth0如果输出里 Speed 显示 1000Mb/s 而实际交换机端口是 10G说明边缘接口协商到了错误速率Duplex 如果不是 Full半双工状态在千兆链路上会引发大量冲突和重传。这个环节考察的是你是否理解“边缘接入”不是一个固定带宽概念而是实际由一对接口协商出来的状态。第二条验证网络层路径用限制大小的 ICMP 报文探测 MTU 约束。ping -M do -s 1472 -c 5 10.0.0.2 ping -M do -s 1473 -c 3 10.0.0.2前提是你已经按照第 4 节搭好 netns 实验环境。第一个命令通、第二个命令不通说明这一段 1500 字节的 MTU 没有被中间设备一致支持如果两个都不通先回到 RTT 是否异常再考虑是否存在丢包。这既检验了分组交换中“最大传输单元”的概念也检验了对 ICMP 协议字段的熟悉度。第三条复现拥塞排队给 netns 链路加不同延迟然后用一个简单的 Python TCP 连接测量往返时间变化import socket import time sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(5) start time.time() try: sock.connect((10.0.0.2, 5201)) rtt (time.time() - start) * 1000 print(ftcp connect rtt: {rtt:.2f} ms) except socket.error as exc: print(fconnect failed: {exc}) finally: sock.close()先用tc qdisc add dev veth-a root netem delay 50ms设 50ms 延迟脚本输出会接近 50ms再把 delay 改成 150msRTT 随之增大。这个实验把计算机网络第一章最重要的三件事连到了一起边缘主机发起连接、网络核心负责转发、时延参数决定应用体感。把这三条命令跑完你会发现“Internet 是否可用”这句话从此有了明确的分层含义而不是一个黑盒开关。本文还有配套的精品资源点击获取