计算机网络与Internet：从分层模型到实战排障的完整指南

简介：高级计算机网络课程第一章“计算机网络与Internet（1-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 连接复用的机制吸收，你很难单独观测它们。

排障时最有效的分层口径如下：

这里要特别留意一个容易被误解的点：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 1

ss -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 请求，服务端回应数据后，客户端会回 ACK，Wireshark 的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 20

tshark 在大部分发行版中随 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 up

veth 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.2

tc qdisc add ... root netem是给网卡根队列添加网络模拟器，delay 100ms表示每包固定延迟 100ms，loss 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 不是只能做固定延迟。生产环境中的网络质量更像抖动型，延迟值在一个范围内波动。可以参考下面这张参数表做组合：

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。

下面这张表可以当速查卡：

223.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 -20

awk '{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_established

conntrack -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(f"tcp connect rtt: {rtt:.2f} ms") except socket.error as exc: print(f"connect failed: {exc}") finally: sock.close()

先用tc qdisc add dev veth-a root netem delay 50ms设 50ms 延迟，脚本输出会接近 50ms；再把 delay 改成 150ms，RTT 随之增大。这个实验把计算机网络第一章最重要的三件事连到了一起：边缘主机发起连接、网络核心负责转发、时延参数决定应用体感。把这三条命令跑完，你会发现“Internet 是否可用”这句话从此有了明确的分层含义，而不是一个黑盒开关。

本文还有配套的精品资源，点击获取