简介这份PPT课件面向计算机专业初学者与信息技术入门者系统讲解计算机网络的基础概念与核心原理帮助读者建立对网络体系结构的整体认知。内容涵盖网络的定义、产生与发展、基本组成与逻辑结构、拓扑结构及分类并深入剖析局域网与广域网的技术特点以及资源共享、通信功能、高可靠性、负荷均衡与分布式处理等主要功能同时结合企业信息管理与个人信息服务场景说明实际应用。资源包共1个PPT文件大小约1.13MB以图文并茂的幻灯片形式呈现便于课堂讲解与自学梳理。目前已有1143人学习下载适合作为课程配套讲义或备考复习资料帮助读者快速掌握网络基础知识点并理解其在现代信息技术中的关键地位。1. 计算机网络基础从一根网线到一次 HTTP 请求中间到底发生了什么很多人学「计算机网络基础」的方式是背 OSI 七层模型背完就忘忘了再背。我见过太多干了两年 CRUD 的兄弟被问到「浏览器输入 URL 之后发生了什么」时只能含糊地说「DNS 解析、TCP 握手、发 HTTP 请求」再往下问 TCP 握手具体交换了什么、为什么是三次不是两次就卡住了。问题不在记忆力在于学习路径反了——先背抽象模型再试图往里面填东西永远填不踏实。这篇东西不讲教科书讲一条真实的链路从你工位那根网线或者 Wi-Fi 信号出发一个数据包怎么被封装、怎么找到路、怎么到达对面服务器、又怎么把响应带回来。我会把每一层的实际动作、你能亲手敲的命令、以及排查问题时该看哪个字段讲清楚。适合两类人一是准备面试但不想背八股的开发者二是线上遇到网络问题只会重启服务的运维。读完你至少能做到抓包看得懂、ping 和 traceroute 的结果能解释、TCP 状态机不再是黑匣子。2. 分层不是背诵题数据包从应用到网线怎么被一层层扒皮2.1 为什么非要分层一次封装解封的真实开销先想一个问题如果没有分层你的浏览器要发一个 HTTP 请求它得自己处理「怎么找到服务器 MAC 地址」「怎么保证对方收到了」「网线断了怎么办」所有事。这显然不现实。分层的本质是关注点分离——每一层只解决一类问题上层不关心下层怎么实现。但分层不是免费的。每经过一层数据就要被加上一个头部Header这叫封装Encapsulation。一个 HTTP GET 请求到了网线上实际长这样[以太网头 14B][IP 头 20B][TCP 头 20B][HTTP 数据 ...][以太网尾 4B]假设 HTTP 数据是 100 字节那实际在网线上跑的是 158 字节。头部开销接近 37%。这就是为什么大文件传输时 MTU最大传输单元和 MSS最大报文段长度的调优有意义——头部占比越小有效载荷越高。接收端反过来做解封Decapsulation网卡收到帧剥掉以太网头发现是 IP 包交给 IP 层IP 层剥掉 IP 头发现协议号是 6TCP交给 TCP 层TCP 层剥掉 TCP 头发现端口是 80交给监听 80 的进程。每一层只干自己的事。提示抓包时看到的「帧」是二层概念「包」是三层「段」是四层。Wireshark 里点开一个包能看到它同时展示了 Ethernet II、IP、TCP 三层就是封装结构的可视化。2.2 用 tcpdump 抓一次真实请求看清每层头部理论说再多不如抓一次。在 Linux 上用 tcpdump 抓一个访问 example.com 的完整过程。先开一个终端抓包# -i any 监听所有网卡-nn 不做域名和端口解析-w 写入文件 sudo tcpdump -i any -nn port 80 -w http_capture.pcap然后另一个终端发起请求curl -v http://example.com/抓完后用 tcpdump 读回来只看前几个包# -r 读取文件-A 以 ASCII 显示载荷-c 5 只显示5个包 tcpdump -r http_capture.pcap -nn -A -c 5你会看到类似这样的输出关键字段我标注了IP 192.168.1.100.54321 93.184.216.34.80: Flags [S], seq 1234567890 IP 93.184.216.34.80 192.168.1.100.54321: Flags [S.], seq 987654321, ack 1234567891 IP 192.168.1.100.54321 93.184.216.34.80: Flags [.], ack 1这三行就是 TCP 三次握手。第一行Flags [S]是 SYN客户端说「我想连你我的初始序列号是 1234567890」。第二行Flags [S.]是 SYNACK服务器说「行我的序列号是 987654321确认收到你的 1234567890」。第三行Flags [.]是 ACK客户端说「收到你的确认了」。参数说明seq是序列号标记这个包在字节流中的位置ack是确认号表示「这个序号之前的数据我都收到了」。序列号不是从 0 开始是随机初始化的这是为了防止旧连接的延迟包被新连接误收。2.3 三次握手为什么不能是两次一个能说服自己的推导面试常问「为什么三次不是两次」。标准答案是「防止已失效的连接请求突然又传到服务器」。但这个答案太抽象我换个方式推。假设只有两次握手客户端发 SYN服务器回 SYNACK连接建立。现在考虑一个场景客户端发了一个 SYN但这个 SYN 在网络里堵了很久客户端等不到响应就放弃了。过了一会这个堵住的 SYN 终于到了服务器。服务器以为是新连接回 SYNACK 并直接进入 ESTABLISHED 状态等着收数据。但客户端根本不认这个连接不会发数据。服务器就白白维持了一个死连接占着资源。三次握手解决了这个问题服务器回 SYNACK 后不直接进入 ESTABLISHED而是进入 SYN_RCVD等客户端再发一个 ACK 才确认。那个堵住的 SYN 对应的客户端不会发第三个 ACK服务器等超时后就释放了。用 tcpdump 能看到这个状态变化。在服务器上执行# 查看 TCP 连接状态-tan 显示所有TCP连接不做解析 ss -tan state syn-recv如果有半开连接会显示SYN-RECV状态。正常情况下这个状态转瞬即逝如果大量堆积说明有人在 SYN Flood 攻击或者客户端网络有问题。3. IP 和路由数据包怎么在无数岔路口找到正确的那条3.1 IP 地址和子网掩码判断「同不同网段」的位运算IP 层最核心的问题是这个包该直接发给目标还是发给网关判断依据是子网掩码。拿192.168.1.100/24举例/24表示前 24 位是网络号后 8 位是主机号。判断两个 IP 是否同网段就是拿各自的 IP 和子网掩码做按位与# 判断两个IP是否在同一子网 def same_subnet(ip1, ip2, mask): # 将点分十进制转为整数 def ip_to_int(ip): parts ip.split(.) return (int(parts[0]) 24) (int(parts[1]) 16) \ (int(parts[2]) 8) int(parts[3]) def mask_to_int(mask): # mask 是前缀长度如 24 return (0xFFFFFFFF (32 - mask)) 0xFFFFFFFF m mask_to_int(mask) return (ip_to_int(ip1) m) (ip_to_int(ip2) m) # 测试 print(same_subnet(192.168.1.100, 192.168.1.200, 24)) # True print(same_subnet(192.168.1.100, 192.168.2.100, 24)) # False逻辑说明ip_to_int把192.168.1.100转成 32 位整数。mask_to_int把前缀长度 24 转成255.255.255.0的整数形式。按位与之后比较网络号。同网段就直接 ARP 找目标 MAC不同网段就发给默认网关。参数说明/24是最常见的子网划分一个 C 类网段 254 个可用地址。/16是 B 类6 万多个地址。生产环境里 VPC 常用/16或/20留足扩展空间。3.2 路由表长什么样用 ip route 看懂包的下一跳Linux 上查看路由表ip route show典型输出default via 192.168.1.1 dev eth0 proto dhcp metric 100 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100第一行是默认路由所有不匹配其他规则的包都发给192.168.1.1网关从eth0出去。第二行是直连路由192.168.1.0/24网段的包直接从eth0发源地址是192.168.1.100。路由匹配遵循最长前缀匹配原则。比如目标 IP 是192.168.1.50它同时匹配default和192.168.1.0/24但后者前缀更长24 0所以走直连路由。metric是路由优先级数值越小优先级越高。多条默认路由时metric 小的生效。这在多网卡场景比如同时有线和无线下决定走哪条路。3.3 traceroute 的原理用 TTL 逐跳逼出路径traceroute 是排查「包到底走哪条路」的利器。它的原理很巧妙发送 TTLTime To Live依次递增的包。TTL 每经过一个路由器减 1减到 0 时路由器丢弃包并回一个 ICMP 超时消息。traceroute 就靠这些 ICMP 消息确定每一跳的 IP。# -n 不做反向DNS解析-I 用ICMP而不是UDP-m 最大跳数 traceroute -n -I -m 15 example.com输出示例1 192.168.1.1 1.234 ms 2 10.0.0.1 5.678 ms 3 172.16.1.1 12.345 ms 4 * * * 5 93.184.216.34 45.678 ms第 4 跳显示* * *说明那个路由器配置了不回应 ICMP或者防火墙拦了。这不代表路径断了只是看不到那一跳的信息。参数说明-m 15限制最大 15 跳防止无限循环。-I用 ICMP 探测有些网络对 UDP 探测不友好。-n跳过 DNS 反查速度快很多。注意traceroute 显示的是「去程」路径回程路径可能完全不同。这叫非对称路由在有多条出口链路的网络里很常见。排查单向不通时两边都要 traceroute。4. TCP 可靠传输滑动窗口、重传和拥塞控制到底在干什么4.1 滑动窗口为什么发数据不用等一个确认再发下一个如果 TCP 每发一个包就停下来等 ACK那带宽利用率会低到没法看。滑动窗口Sliding Window解决了这个问题发送方可以连续发多个包只要它们在窗口范围内。窗口大小由接收方在 TCP 头部的 Window 字段告诉发送方。比如接收方说「我的窗口是 65535 字节」发送方就可以在没收到 ACK 的情况下最多发 65535 字节的数据。用 Wireshark 看一个 TCP 流点开任意一个包展开 TCP 头部能看到Window Size Value。如果这个值一直是 0说明接收方缓冲区满了发送方必须停下来。这就是「零窗口」——线上服务卡顿的常见原因之一。查看本机 TCP 缓冲区设置# 查看接收缓冲区 sysctl net.ipv4.tcp_rmem # 查看发送缓冲区 sysctl net.ipv4.tcp_wmem输出类似4096 87380 6291456分别是最小、默认、最大值。如果默认值太小高延迟高带宽场景比如跨机房传输吞吐量上不去。可以调大# 临时调整重启失效 sudo sysctl -w net.ipv4.tcp_rmem4096 262144 16777216 sudo sysctl -w net.ipv4.tcp_wmem4096 262144 16777216参数说明中间那个值是默认缓冲区大小。从 87380 调到 262144意味着每个连接默认能缓冲更多数据。代价是内存占用增加连接数多的时候要算总账。4.2 超时重传和快速重传丢包之后到底等多久TCP 保证可靠的核心机制是重传。发送方发了一个包启动一个定时器。如果在 RTORetransmission Timeout时间内没收到 ACK就重传。RTO 不是固定的是根据 RTT往返时间动态计算的。Linux 上查看当前连接的 RTT 和 RTO# 查看TCP连接的详细统计包括rtt和rto ss -tin输出里会有rtt:12.345/1.234和rto:200这样的字段。rtt是平滑后的往返时间rto是当前重传超时时间毫秒。除了超时重传还有快速重传如果发送方收到三个重复的 ACK说明中间有个包丢了但后面的包到了不等超时直接重传丢失的那个包。这比等 RTO 快得多。用 tcpdump 能看到重传# 抓包并过滤重传的包 sudo tcpdump -i any -nn tcp[tcpflags] tcp-ack ! 0 -w retrans.pcap在 Wireshark 里打开过滤tcp.analysis.retransmission能看到所有重传的包。如果重传率超过 1%网络质量就有问题了。4.3 拥塞控制从慢启动到 BBR内核帮你做了什么滑动窗口解决的是「接收方处理不过来」的问题拥塞控制解决的是「网络中间链路处理不过来」的问题。两者是独立的。Linux 默认的拥塞控制算法是 CUBIC。查看当前算法sysctl net.ipv4.tcp_congestion_control输出net.ipv4.tcp_congestion_control cubic。可以改成 BBR# 临时切换 sudo sysctl -w net.ipv4.tcp_congestion_controlbbr # 查看可用算法 sysctl net.ipv4.tcp_available_congestion_controlBBR 是 Google 提出的算法在高丢包高延迟链路上比 CUBIC 表现好很多。它的核心思路是不把丢包当作拥塞的唯一信号而是主动测量带宽和 RTT 来调整发送速率。参数说明切换拥塞控制算法不需要重启对新建连接生效。已有连接保持原算法。生产环境切换前建议在测试环境验证因为不同网络特征下表现差异很大。5. 避坑与排查那些让你加班到凌晨的网络问题5.1 现象服务时通时不通ping 正常但 curl 超时原因MTU 不匹配。路径中某个设备的 MTU 小于发送方的 MTU大包被丢弃但小包能通过。ping 默认发小包所以正常curl 发大包就卡住。解决先用 ping 探测路径 MTU# -M do 禁止分片-s 指定包大小 ping -M do -s 1472 example.com1472 28ICMP 头 IP 头 1500是标准以太网 MTU。如果这个不通但-s 1400通说明路径 MTU 在 1400 左右。然后在应用层调整 MSS# 设置MSS clamping让TCP协商时使用更小的MSS sudo iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu5.2 现象大量 TIME_WAIT 状态端口耗尽原因主动关闭连接的一方会进入 TIME_WAIT持续 2MSL通常 60 秒。高并发短连接场景下TIME_WAIT 堆积导致本地端口不够用。解决先确认是不是真的端口耗尽# 统计TIME_WAIT数量 ss -tan state time-wait | wc -l # 查看端口范围 sysctl net.ipv4.ip_local_port_range如果 TIME_WAIT 数量接近端口范围上限可以开启复用# 允许TIME_WAIT状态的socket被新连接复用 sudo sysctl -w net.ipv4.tcp_tw_reuse1 # 缩短FIN_WAIT_2的超时时间 sudo sysctl -w net.ipv4.tcp_fin_timeout30注意tcp_tw_reuse只对客户端生效且需要时间戳支持。不要开tcp_tw_recycle它在 NAT 环境下会导致连接随机失败已经被内核废弃。5.3 现象DNS 解析偶尔很慢但 ping DNS 服务器正常原因/etc/resolv.conf里配了多个 DNS 服务器第一个超时后才尝试第二个。而默认超时是 5 秒重试 2 次最坏情况等 15 秒。解决调整 resolv.conf 的超时和重试次数options timeout:1 attempts:2 rotatetimeout:1表示 1 秒超时attempts:2表示重试 2 次rotate表示轮询所有 DNS 服务器而不是只用第一个。改完后用dig验证# 查看解析耗时 dig example.com | grep Query time5.4 现象TCP 连接建立成功但传输数据时卡死原因路径上有防火墙或 NAT 设备只允许 SYN 和 SYNACK 通过后续的数据包被拦截。或者 MSS 协商有问题双方都发大包但中间设备不支持。解决用 tcpdump 同时抓两端对比包的数量和方向。如果一端发了数据但另一端没收到就是中间设备的问题。可以尝试在应用层启用 TCP keepalive 探测# 查看当前keepalive设置 sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes默认是 7200 秒2 小时才开始探测太长了。对于长连接服务建议调短sudo sysctl -w net.ipv4.tcp_keepalive_time600 sudo sysctl -w net.ipv4.tcp_keepalive_intvl30 sudo sysctl -w net.ipv4.tcp_keepalive_probes3这样 10 分钟没数据就开始探测30 秒一次3 次没响应就断开。能更快发现死连接。6. 用 eBPF 看清内核网络栈一个比 tcpdump 更细的视角tcpdump 抓的是网卡层面的包但包在内核里经历了什么——在哪一层被丢弃、在哪个钩子被修改——tcpdump 看不到。eBPF 可以挂在内核函数上追踪每个包的处理路径。先确认内核支持 eBPF# 查看内核版本需要4.9以上 uname -r # 查看bpf文件系统是否挂载 mount | grep bpf如果没有挂载手动挂上sudo mount -t bpf bpf /sys/fs/bpf用 bpftrace 追踪 TCP 重传事件需要先安装 bpftrace# 追踪tcp_retransmit_skb函数的调用 sudo bpftrace -e kprobe:tcp_retransmit_skb { printf(重传: %s:%d - %s:%d\n, ntop(((struct sock *)arg0)-__sk_common.skc_rcv_saddr), ((struct sock *)arg0)-__sk_common.skc_num, ntop(((struct sock *)arg0)-__sk_common.skc_daddr), ((struct sock *)arg0)-__sk_common.skc_dport); }这个脚本挂在内核的tcp_retransmit_skb函数上每次重传就打印源 IP、源端口、目标 IP、目标端口。比 tcpdump 过滤重传更直接因为这是内核决定重传的那一刻不是网卡上看到的包。参数说明arg0是函数第一个参数类型是struct sock *。skc_rcv_saddr是接收方地址对发送方来说是本地地址skc_daddr是目标地址。ntop把整数转成 IP 字符串。再追踪一下 TCP 连接建立失败的原因# 追踪tcp_v4_connect的返回值和错误码 sudo bpftrace -e kretprobe:tcp_v4_connect { if (retval ! 0) { printf(连接失败错误码: %d\n, retval); } }错误码对应关系-111是 ECONNREFUSED端口没监听-110是 ETIMEDOUT超时-113是 EHOSTUNREACH路由不可达。这比看应用日志快得多因为这是内核拒绝连接的第一现场。我自己的习惯是线上遇到网络问题先用ss -s看全局统计再用ss -tin看具体连接然后用 tcpdump 抓包确认最后如果还定位不到就用 eBPF 追内核。这套组合拳打下来90% 的网络问题都能在 10 分钟内定位。剩下 10% 是玄学问题——比如交换机 silently drop 了特定大小的包那就只能靠二分法换设备了。希望帮到你。本文还有配套的精品资源点击获取