简介这份PDF面向管理类、工商类本科学生及计算机网络初学者系统梳理数据通信与计算机网络课程的核心知识框架帮助读者掌握网络基本理论并建立从数据通信到网络管理的完整认知。内容涵盖计算机网络概论、数据通信、计算机局域网、网络互连与广域网、Internet与Intranet、网络管理及网络操作系统等模块并配套局域网组网、Internet应用、Windows网络操作系统配置、Web服务器搭建、Linux网络服务配置等实验要求同时给出各章学时分配与开卷考核说明便于对照课程进度复习。资源包共1个PDF文件大小约16KB轻量便携适合随时查阅。目前已有331人学习可作为课程配套讲义、期末复习提纲或自学入门的参考材料。1. 数据通信与计算机网络从一根网线到一次完整请求到底发生了什么很多人第一次翻开《数据通信与计算机网络》这类教材是被“分层”“协议”“封装”这些词劝退的。但如果你是一个要排查线上问题的工程师或者正在准备 408、期末复习、头歌实训的学生你会发现真正卡住你的从来不是定义而是一次请求从你的电脑发出到服务器返回中间到底经过了哪些设备、每一层加了什么头、哪里可能丢包。数据通信解决的是“比特怎么在介质上可靠地传”计算机网络解决的是“这些比特怎么找到对端、怎么被正确理解”。这两件事合在一起才构成你每天敲下curl之后发生的一切。这篇笔记不打算复述教材目录而是按“先建立模型、再动手抓一次、最后看坑在哪”的顺序把数据通信与计算机网络里最值得投入的那部分讲透适合想真正看懂抓包、想搞明白 DevOps 里网络为什么总出玄学问题的人。2. 分层模型不是背诵题把一次 HTTP 请求拆到每一层2.1 为什么非要分层从“换一块网卡就要重写应用”说起教材里讲 OSI 七层和 TCP/IP 四层很多人背完就忘。真正让分层立住的是一个很实际的问题如果你的应用逻辑和物理介质绑死那么从网线换成光纤、从 IPv4 换成 IPv6你的代码就得重写。分层本质上是把变化隔离在各自的层里每一层只对上一层提供稳定的接口。我一般这样理解各层的职责边界层TCP/IP关心的问题典型协议/设备数据单元应用层这段数据是什么意思HTTP、DNS、SSH报文传输层给哪个进程、要不要可靠TCP、UDP段/数据报网络层送到哪台主机、怎么跨网IP、ICMP、路由器包网络接口层下一跳是谁、怎么上介质以太网、ARP、交换机帧关键点在于每一层只信任上一层交给它的载荷不去解读内容。路由器转发 IP 包时根本不关心里面是 HTTP 还是 DNS这就是为什么你可以在同一条链路上跑各种应用。理解这一点后面看封装和抓包才不会乱。2.2 封装与解封装一次请求的头是怎么一层层加上去的当你在浏览器里访问一个地址数据是自上而下“穿”过协议栈的。应用层生成 HTTP 报文传输层加上 TCP 头含源端口、目的端口、序号网络层加上 IP 头含源 IP、目的 IP、TTL网络接口层加上以太网头含源 MAC、目的 MAC。到了对端再自下而上剥掉这就是封装与解封装。用一段 Python 直观感受一下“载荷被逐层包裹”的过程这里不依赖任何第三方库只是模拟头部叠加的逻辑# 模拟一次自顶向下的封装过程重点看每层加了什么字段 def app_layer(payload: str) - dict: # 应用层这里用最简化的“HTTP 请求行”代表报文 return {layer: app, data: fGET /{payload} HTTP/1.1} def transport_layer(app: dict, src_port: int, dst_port: int) - dict: # 传输层加上端口和序号TCP 靠这些做可靠传输 return {layer: tcp, src_port: src_port, dst_port: dst_port, seq: 1, payload: app} def network_layer(seg: dict, src_ip: str, dst_ip: str, ttl: int 64) - dict: # 网络层加上 IP 地址和 TTLTTL 每过一个路由器减 1 return {layer: ip, src_ip: src_ip, dst_ip: dst_ip, ttl: ttl, payload: seg} def link_layer(pkt: dict, src_mac: str, dst_mac: str) - dict: # 网络接口层加上 MAC 地址决定这一跳交给谁 return {layer: eth, src_mac: src_mac, dst_mac: dst_mac, payload: pkt} frame link_layer( network_layer( transport_layer(app_layer(index.html), 51000, 80), 192.168.1.10, 93.184.216.34 ), aa:bb:cc:dd:ee:ff, 11:22:33:44:55:66 ) print(frame)逻辑说明app_layer只负责生成业务数据transport_layer关心端口和可靠性字段network_layer关心寻址和生存时间link_layer关心这一跳的物理地址。参数上ttl64是常见初始值每经过一个三层设备减一减到 0 就丢弃并回 ICMP 超时——这正是traceroute的工作原理。src_port用 51000 这类高位端口是因为客户端临时端口通常由系统在 32768–60999 之间分配。提示真实协议栈里各层是零拷贝或缓冲区拼接不是像上面这样层层套字典但“载荷 本层头”的结构是一致的理解模型足够。2.3 用 tcpdump 抓一次真实请求把模型对上现实光看模型容易飘抓一次包就落地了。在 Linux 上最直接的工具是tcpdump。假设你要观察本机访问某个 HTTP 服务的完整过程# -i any 监听所有网卡-nn 不做域名和端口名解析-A 以 ASCII 显示载荷 # 过滤条件只抓 80 端口的 TCP 流量避免噪音 sudo tcpdump -i any -nn -A tcp port 80 -c 20执行后另开一个终端发起请求你会看到类似Flags [S]SYN、Flags [S.]SYN-ACK、Flags [.]ACK的三次握手然后是GET / HTTP/1.1的明文载荷。参数说明-c 20表示抓满 20 个包就停避免刷屏-nn在排查时非常关键它阻止 tcpdump 反查 DNS否则你看到的可能是解析后的域名反而掩盖了真实 IP。如果你只想看握手是否成功把过滤条件换成tcp[tcpflags] (tcp-syn|tcp-ack) ! 0更聚焦。抓到包之后对照 2.2 的模型以太网头里有 MACIP 头里有地址和 TTLTCP 头里有端口和标志位。模型和现实的对应关系一旦建立后面排查问题就是按层缩小范围。3. 从 IP 到 TCP寻址、可靠传输与那些必须记住的参数3.1 IP 地址与子网划分为什么你的机器“能上外网却 ping 不通同事”网络层最容易被低估的是子网划分。很多人配了 IP 和掩码却说不清“同子网”和“跨子网”的区别。核心规则只有一条源和目的 IP 分别与子网掩码做按位与结果相同就是同子网直接二层通信不同就交给网关。举个常见配置本机192.168.1.10/24同事192.168.1.20/24掩码都是255.255.255.0与运算后网络号都是192.168.1.0同子网走 ARP 找 MAC 直接发。如果同事是192.168.2.20/24网络号变成192.168.2.0不同子网你的包会发给默认网关。如果网关没配或配错现象就是“能 ping 通同网段、ping 不通外网”这是血泪经验里出现频率最高的排查点之一。用一段 Python 做子网判断比手算靠谱import ipaddress def same_subnet(ip1: str, ip2: str, mask: str) - bool: # 把字符串转成 IPv4 对象再和掩码做与运算得到网络号 net1 ipaddress.IPv4Network(f{ip1}/{mask}, strictFalse) net2 ipaddress.IPv4Network(f{ip2}/{mask}, strictFalse) return net1.network_address net2.network_address print(same_subnet(192.168.1.10, 192.168.1.20, 255.255.255.0)) # True print(same_subnet(192.168.1.10, 192.168.2.20, 255.255.255.0)) # False参数说明strictFalse允许主机位非零的地址被接受否则192.168.1.10/24会因为不是网络地址而报错。这个函数在写自动化巡检脚本时很有用比如批量判断一批机器是否在同一网段。3.2 TCP 三次握手与四次挥手状态机里藏着排障线索传输层里 TCP 是重点因为它承担了可靠传输。三次握手的目的是双方确认彼此的发送和接收能力都正常并同步初始序号。四次挥手则是因为 TCP 是全双工两个方向要分别关闭。排障时最有价值的不是背流程而是记住几个状态SYN_SENT长时间停留说明 SYN 发出去了但没收到 SYN-ACK通常是对方没监听、被防火墙丢弃或路由不通。TIME_WAIT大量堆积主动关闭方会进入这个状态等待 2MSL高并发短连接场景下会耗尽端口常见优化是开启tcp_tw_reuse需谨慎。CLOSE_WAIT堆积说明对端关了但你这边应用没调close()这是应用层代码问题不是内核参数能救的。用ss看状态分布比netstat更快# -t TCP-a 全部-n 不解析统计各状态数量 ss -tan | awk NR1 {print $1} | sort | uniq -c | sort -rn这条命令输出的是当前所有 TCP 连接按状态计数TIME_WAIT或CLOSE_WAIT异常多时一眼就能看出来。参数上-n避免 DNS 解析拖慢速度awk NR1跳过表头。3.3 滑动窗口与拥塞控制为什么带宽够但传输还是慢很多人以为传输慢就是带宽不够其实更常见的是窗口和拥塞控制没跑满。TCP 用滑动窗口做流量控制接收方通过Window字段告诉发送方自己还能收多少同时用慢启动、拥塞避免等算法探测网络容量。关键参数接收窗口rwnd由接收方缓冲决定太小会限制吞吐。拥塞窗口cwnd由发送方根据丢包情况调整慢启动阶段指数增长。带宽时延积 BDP 带宽 × RTT决定了“在途数据”的上限窗口小于 BDP 就跑不满带宽。在长肥管道高带宽高延迟场景下默认窗口往往不够需要开启窗口缩放。这也是为什么同样带宽跨地域传输比同机房慢很多——不是带宽问题是 RTT 把窗口限制放大了。理解这一点你在做 DevOps 跨区部署时就不会盲目加带宽而是先看 RTT 和窗口。4. 应用层协议与抓包分析DNS、HTTP 到底怎么配合4.1 DNS 解析一次请求之前先发生的“查号”你敲下域名第一步不是发 HTTP而是解析域名。DNS 默认走 UDP 53 端口查询过程是递归加迭代本地递归服务器帮你问根、问顶级域、问权威服务器最后拿到 A 记录。用dig看全过程# trace 从根开始逐级追踪能看清每一级返回了什么 dig trace example.com A参数说明trace会绕过本地缓存直接模拟迭代查询适合排查“解析结果不对”的问题如果只想看最终结果用dig example.com A short。常见坑是本地 hosts 文件或缓存覆盖了真实解析排查时先dig再对比/etc/hosts。4.2 HTTP 请求的完整生命周期与常见状态码DNS 拿到 IP 后TCP 握手建立连接然后发 HTTP 请求。一个请求的生命周期可以拆成DNS 解析 → TCP 握手 → TLS 握手HTTPS→ 发送请求 → 等待响应 → 关闭或复用连接。状态码里最容易被误读的301/302重定向注意 301 会被浏览器缓存改错了很难回滚。502网关收到上游无效响应通常是后端挂了或超时。504网关等待上游超时重点查后端处理时间和网关超时配置。用curl看各阶段耗时# -w 自定义输出%{time_*} 系列变量给出各阶段耗时 curl -o /dev/null -s -w dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} total:%{time_total}\n https://example.com参数说明time_namelookup是 DNS 耗时time_connect是 TCP 握手完成time_appconnect是 TLS 完成time_total是总耗时。如果 dns 占比高查解析connect 高查网络和握手total 远大于前面之和查服务端处理。这是定位“慢”最快的方法。4.3 用 Wireshark 过滤表达式定位问题Wireshark 的过滤表达式是排障利器。常用几条ip.addr 192.168.1.10只看某台主机。tcp.port 443 tcp.flags.syn 1只看 443 的 SYN 包判断握手是否发出。http.response.code 500只看服务端错误响应。tcp.analysis.retransmission只看重传判断是否丢包。这些表达式配合前面的分层模型能让你从“一片混沌的包”里迅速锁定某一层。先按 IP 缩小主机再按端口缩小进程最后按标志位或分析项缩小事件这个顺序我一直在用。5. 避坑与排查数据通信与网络里最容易翻车的 5 个点5.1 现象能 ping 通 IP 但域名打不开原因DNS 解析失败而 ICMP 不依赖 DNS。解决先dig或nslookup确认解析再检查/etc/resolv.conf和 hosts 文件。这是最经典的“网络没问题是解析有问题”。5.2 现象TCP 连接建立成功但传输极慢原因多半是 MTU 不匹配导致分片或 PMTUD 黑洞。解决用ping -M do -s 1472逐步试探最大不分片尺寸定位链路 MTU必要时在接口上调整 MSS。参数上 1472 28 字节头 1500是常见以太网 MTU。5.3 现象大量 CLOSE_WAIT 堆积原因应用层收到 FIN 后没有关闭自己的 socket属于代码缺陷。解决检查连接池是否正确释放、异常分支是否漏了close()。调内核参数没用必须改代码这是很多人绕不过去的坑。5.4 现象抓包看到重传但带宽没跑满原因链路存在丢包触发拥塞控制降窗。解决用tcp.analysis.retransmission定位丢包位置检查中间设备是否有拥塞或错误配置。不要一上来就怪应用。5.5 现象改了子网掩码后部分机器不通原因掩码变更导致网络号变化原本同子网的机器被划到不同网段但网关或路由没同步更新。解决变更前用 3.1 的脚本批量核对网络号变更后逐台验证网关可达性。网络变更一定要有回滚方案这是后悔药。6. 进阶技巧用最小实验环境把协议“跑”一遍学网络最有效的方式不是看而是自己搭一个能抓、能改、能复现的最小环境。我的习惯是用 Linux 网络命名空间在一台机器上模拟多台主机不依赖虚拟机几秒就能起一套拓扑。# 创建两个网络命名空间相当于两台独立主机 sudo ip netns add ns1 sudo ip netns add ns2 # 创建一对 veth 虚拟网线两端分别插进两个命名空间 sudo ip link add veth1 type veth peer name veth2 sudo ip link set veth1 netns ns1 sudo ip link set veth2 netns ns2 # 配置 IP 并启用接口 sudo ip netns exec ns1 ip addr add 10.0.0.1/24 dev veth1 sudo ip netns exec ns2 ip addr add 10.0.0.2/24 dev veth2 sudo ip netns exec ns1 ip link set veth1 up sudo ip netns exec ns2 ip link set veth2 up # 从 ns1 ping ns2验证二层和三层连通 sudo ip netns exec ns1 ping -c 3 10.0.0.2逻辑说明ip netns创建的是独立的网络协议栈veth是一对虚拟网卡数据从一端进另一端出等价于一根网线。参数上/24决定同子网ping -c 3只发三个包便于观察。这个环境的好处是你可以随意改 MTU、加丢包、抓包而不影响宿主机。在此基础上用tc注入延迟和丢包观察 TCP 行为# 在 ns2 的 veth2 上注入 100ms 延迟和 5% 丢包 sudo ip netns exec ns2 tc qdisc add dev veth2 root netem delay 100ms loss 5% # 再次 ping 或传输观察 RTT 和重传 sudo ip netns exec ns1 ping -c 10 10.0.0.2参数说明delay 100ms模拟跨地域延迟loss 5%模拟不稳定链路。你会看到 RTT 上升、偶发丢包如果此时跑 TCP 传输还能观察到拥塞窗口的变化。把 3.3 的窗口理论和这里的实测对上比背十遍公式都管用。我自己的习惯是每学一个协议就在这个环境里抓一次包改一个参数看现象怎么变。网络这东西看会了不算会跑通了、改坏了、再修好了才算真的懂。希望帮到你。本文还有配套的精品资源点击获取