简介这份PDF资料面向准备技术面试的IT求职者与网络初学者系统梳理了计算机网络的核心考点帮助读者在面试与工程实践中快速建立知识框架。内容围绕OSI七层参考模型与TCP/IP四层模型展开涵盖TCP/IP协议族、TCP/UDP/SCTP协议对比、三次握手与四次挥手、TCP状态机、TIME_WAIT状态、端口号、超时重传与快速重传、TCP Header结构、可靠传输、流量控制与拥塞控制以及IPv4、IPv6、ICMP、ARP、IGMP等网络层协议并附有常见面试问题解析。资源包共1个PDF文件大小约2.08MB结构清晰、便于按章节检索复习。目前已有969人学习适合需要系统梳理网络知识、查漏补缺或冲刺面试的读者参考。1. 从一次“网络不通”的排查说起计算机网络基础知识到底该学什么很多人第一次被网络问题卡住不是不会写代码而是不知道从哪里看。应用层日志显示请求超时传输层可能连 SYN 都没发出去ping通了但业务端口连不上问题可能出在防火墙策略而不是路由。计算机网络基础知识之所以重要是因为它决定了你排查问题时有没有一张“分层地图”。这张地图最常用的两个版本一个是 OSI 七层模型一个是 TCP/IP 模型。前者适合教学和职责划分后者才是真实协议栈的落地形态。学它的目标不是背概念而是能回答三个问题数据从网卡到应用经过了哪些层、每层可能在哪里丢、用什么命令能验证。本文面向需要做后端开发、嵌入式联网、测试运维或准备 408 考研的读者把 OSI、TCP/IP、TCP、UDP 这些高频词串成一条可复现的排查路径。2. OSI 七层与 TCP/IP 四层分层模型怎么对应到真实协议栈2.1 两张模型图的映射关系与选型理由OSI 七层模型把网络通信拆成物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。TCP/IP 模型通常讲四层网络接口层、网际层、传输层、应用层。实际工程里会话层和表示层的功能大多被应用层协议或库消化了比如 TLS 放在应用层和传输层之间JSON 序列化属于表示层职责但由业务代码完成。所以排查问题时我一般用 TCP/IP 四层做主线用 OSI 七层做细分定位。OSI 七层TCP/IP 四层典型协议/设备排查命令或现象物理层网络接口层网线、光模块、网卡网卡灯不亮、ethtool看链路数据链路层网络接口层以太网、ARP、交换机arp -a、MAC 地址表网络层网际层IP、ICMP、IGMP、路由器ping、traceroute、ip route传输层传输层TCP、UDPss -tunlp、端口连通性会话层应用层RPC 会话、Socket 连接连接复用、超时重连表示层应用层TLS、编码、序列化抓包看明文/密文应用层应用层HTTP、DNS、Modbus TCPcurl、dig、业务日志这张表的价值在于当你说“网络不通”时先判断是哪一层的问题。物理层看链路状态网络层看 IP 和路由传输层看端口和握手应用层看协议格式和业务逻辑。很多“系统检测到异常流量”的提示实际是应用层风控或网关策略不是 TCP/IP 协议栈本身故障。2.2 用ping、traceroute、ss做一次分层验证下面这组命令适合在 Linux 上按顺序执行用来判断一个目标服务是否可达。假设目标 IP 是192.168.1.100端口8080。# 1. 网络层看目标 IP 是否可达ICMP 是否被放行 ping -c 4 192.168.1.100 # 2. 网络层看路径经过哪些路由器定位在哪一跳开始丢包 traceroute -n 192.168.1.100 # 3. 传输层看本机监听端口和已建立连接 ss -tunlp | grep 8080 # 4. 传输层测试目标 TCP 端口是否开放不依赖应用协议 nc -zv 192.168.1.100 8080 # 5. 应用层用 curl 看 HTTP 响应头和状态码 curl -v --max-time 5 http://192.168.1.100:8080/health逻辑说明ping走 ICMP属于网络层能通不代表 TCP 端口开放traceroute看路径如果某一跳后全是*可能是中间设备禁了 ICMP 或路由不可达ss看本机 socket 状态LISTEN表示服务在听ESTAB表示连接已建立nc直接测 TCP 三次握手比ping更接近业务curl验证应用层协议。参数上-c 4表示发 4 个包-n表示不解析域名-tunlp分别表示 TCP、UDP、数字端口、监听状态、进程名。如果ping通但nc不通优先查防火墙和 iptables/nftables 规则而不是怀疑网卡。2.3 数据在 TCP/IP 模型中的封装与解封装过程发送端从应用层往下走应用数据加 TCP 头变成段加 IP 头变成包加以太网头变成帧最后变成比特流。接收端反过来每层剥掉自己的头交给上层。这个过程中MTU 和 MSS 是常见坑。以太网 MTU 通常 1500 字节IP 头 20 字节TCP 头 20 字节所以 TCP 有效载荷 MSS 一般是 1460 字节。如果应用层一次写超过 MSSTCP 会自动分段UDP 不会分段超过 MTU 时 IP 层会分片接收端重组失败就丢包。这就是为什么iperf3用 UDP 打流时如果包长设得太大会出现大量丢包和乱序。# 用 iperf3 测试 UDP 吞吐包长 1400 字节带宽 100M持续 10 秒 iperf3 -c 192.168.1.100 -u -l 1400 -b 100M -t 10参数说明-u表示 UDP-l 1400是应用层载荷长度加上 UDP 头 8 字节和 IP 头 20 字节总 IP 包长 1428 字节小于 1500避免分片-b 100M是目标带宽-t 10是持续时间。如果-l设成 1472 以上IP 层就会分片在丢包环境下重组成功率下降测出来的吞吐会失真。这个细节在嵌入式 UDP 调试和 C# UDP 分包组包里同样适用。3. TCP 三次握手与四次挥手连接建立和释放的每一步怎么验证3.1 三次握手的报文序列与状态迁移TCP 是面向连接的可靠传输协议。三次握手的过程是客户端发 SYN服务端回 SYNACK客户端再回 ACK。服务端收到 ACK 后进入 ESTABLISHED客户端在收到 SYNACK 后也进入 ESTABLISHED。为什么不是两次因为两次握手无法确认客户端的接收能力和服务端的发送能力同时正常且容易受历史重复 SYN 影响。第三次 ACK 让服务端确认客户端确实收到了自己的 SYNACK。用tcpdump可以完整看到这个过程# 抓取本机与 192.168.1.100 的 8080 端口之间的 TCP 握手包 tcpdump -i any -nn -S tcp port 8080 and host 192.168.1.100输出里会看到[S]、[S.]、[.]三种标志。-S让序列号显示绝对值而不是相对值方便对照。-nn不解析域名和端口名。如果只看到 SYN 没有 SYNACK说明服务端没监听、防火墙拦截或路由不可达如果看到 SYNACK 但客户端没回 ACK可能是客户端被安全软件拦截或路由不对称。3.2 四次挥手的主动关闭与被动关闭TCP 是全双工的所以关闭需要四次挥手主动关闭方发 FIN对方回 ACK对方处理完数据后发 FIN主动方回 ACK。主动方最后进入 TIME_WAIT等待 2MSL 后彻底关闭。TIME_WAIT 的作用是确保最后一个 ACK 能到达并让旧连接的重复报文在网络中消失。高并发短连接服务如果出现大量 TIME_WAIT会占用本地端口导致无法建立新连接。# 统计本机 TIME_WAIT 连接数量 ss -tan | awk $1TIME-WAIT {count} END {print count} # 查看内核相关参数 sysctl net.ipv4.tcp_tw_reuse sysctl net.ipv4.tcp_max_tw_bucketstcp_tw_reuse允许将 TIME_WAIT 状态的 socket 复用于新的出站连接但只对客户端有效且需要时间戳支持。tcp_max_tw_buckets限制 TIME_WAIT 数量超过后内核会直接清理并打日志。生产环境更推荐用连接池或长连接而不是盲目调这两个参数。如果是服务端主动关闭大量 TIME_WAIT 会落在服务端此时应让客户端主动关闭或使用 SO_REUSEADDR。3.3 用 Python 写一个最小 TCP 服务端和客户端验证握手下面这段代码可以在本地跑通一次完整的 TCP 连接建立、数据收发和关闭。服务端监听127.0.0.1:9000客户端连接后发送一条消息。# tcp_server.py import socket server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((127.0.0.1, 9000)) server.listen(5) print(listening on 127.0.0.1:9000) conn, addr server.accept() print(connected by, addr) data conn.recv(1024) print(received:, data.decode()) conn.sendall(back from server) conn.close() server.close()# tcp_client.py import socket client socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect((127.0.0.1, 9000)) client.sendall(bhello tcp) resp client.recv(1024) print(response:, resp.decode()) client.close()逻辑说明SO_REUSEADDR让服务端重启时不必等待 TIME_WAIT 结束就能绑定同一端口。listen(5)是半连接队列长度不是最大连接数。recv(1024)一次最多读 1024 字节TCP 是字节流不保证一次recv对应一次send所以应用层需要自己定义消息边界比如长度前缀或分隔符。这也是 C# UDP 分包组包和 Modbus TCP 解析时同样要处理的问题。4. UDP 与 TCP 的选型边界什么时候该用 UDP怎么测4.1 TCP 和 UDP 的区别不只是“可靠”和“不可靠”TCP 提供可靠、有序、面向连接的字节流有流量控制和拥塞控制。UDP 提供无连接、不可靠的数据报不保证顺序和到达但头部开销小、延迟低、没有队头阻塞。选型时不要只看“可靠”两个字。实时音视频、游戏状态同步、DNS 查询、DHCP、SNMP 这类场景更适合 UDP因为丢一两个包比等重传更可接受。Modbus TCP 虽然名字里有 TCP但它是基于 TCP 的工业协议不是 UDP。IGMP 是网络层的组播管理协议用于主机告诉路由器自己加入了哪个组播组和 TCP/UDP 不在同一层。对比项TCPUDP连接方式面向连接三次握手无连接直接发可靠性确认、重传、排序不保证头部开销20 字节起8 字节传输方式字节流数据报拥塞控制有无典型场景HTTP、SSH、Modbus TCPDNS、视频、游戏、iperf3 UDP4.2 用 Python 发 UDP 包并观察分片UDP 发送端不需要握手直接sendto。下面代码发送一个 2000 字节的 UDP 包超过 MTU 后会触发 IP 分片。# udp_sender.py import socket sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) payload bA * 2000 # 超过常见 MTU 1500会触发 IP 分片 sock.sendto(payload, (127.0.0.1, 9001)) sock.close()# udp_receiver.py import socket sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((127.0.0.1, 9001)) data, addr sock.recvfrom(4096) print(received bytes:, len(data), from, addr) sock.close()逻辑说明SOCK_DGRAM表示 UDP。recvfrom(4096)的缓冲区要大于可能的最大数据报否则多余部分会被截断。在本地回环上MTU 通常很大2000 字节不会分片但在以太网上1500 字节 MTU 下2000 字节会被分成两个 IP 片。如果中间设备禁止分片或重组超时接收端就收不到完整数据。排查时可以用tcpdump -i any -nn udp port 9001看是否有分片标志。read udp: unknown error (code10054)这类错误在 Windows 上通常表示对端不可达ICMP 端口不可达报文被返回给了 UDP socket。4.3 用 iperf3 做 UDP 打流和丢包统计iperf3是常用的带宽测试工具UDP 模式下能给出丢包率和抖动。# 服务端 iperf3 -s # 客户端UDP 模式带宽 50M包长 1200持续 20 秒每 1 秒报告一次 iperf3 -c 192.168.1.100 -u -b 50M -l 1200 -t 20 -i 1参数说明-s是服务端-c是客户端-u是 UDP-b是目标带宽-l是包长-t是时长-i是报告间隔。结果里重点看Lost/Total Datagrams和Jitter。如果丢包率随带宽上升而急剧增加说明链路或接收端处理能力到瓶颈了。包长建议设为 1200 左右留出余量避免分片。嵌入式设备如 ESP01S 发 TCP 消息时也要注意发送缓冲区大小和分包策略不能一次写入超过可用缓冲区的数据。5. 避坑与排查网络基础知识落地时最容易翻车的 5 个点5.1 现象ping通但业务端口连不上原因ICMP 和 TCP 是不同协议防火墙可能放行 ICMP 但拦截 TCP 端口。解决用nc -zv或telnet测目标端口检查 iptables/nftables、安全组和云平台网络 ACL。不要用ping的结果判断业务可用性。5.2 现象TCP 连接建立后立刻被重置原因服务端进程崩溃、连接队列满、或中间设备发送 RST。解决用tcpdump抓包看 RST 来自哪一方。如果是服务端发 RST检查listenbacklog 和somaxconn如果是中间设备检查负载均衡健康检查配置。5.3 现象UDP 收不到数据但发送端无报错原因UDP 无连接发送成功只表示数据交给了内核不代表对端收到。解决在接收端用tcpdump确认包是否到达网卡检查接收缓冲区net.core.rmem_max和SO_RCVBUF。如果包到达但应用没读到可能是缓冲区溢出。5.4 现象大量 TIME_WAIT 导致端口耗尽原因短连接频繁主动关闭TIME_WAIT 默认 60 秒。解决改用长连接或连接池客户端可开启tcp_tw_reuse服务端避免主动关闭。不要随意把tcp_fin_timeout调得过小可能引发旧连接数据错乱。5.5 现象抓包看到分片但应用层数据不完整原因UDP 或 IP 分片在中间设备被丢弃或接收端重组缓冲区不足。解决控制应用层单包大小在 MTU 以内通常 UDP 载荷不超过 1472 字节推荐 1200 字节左右。如果必须发大包改用 TCP 或应用层分片。6. 把分层排查变成习惯一个可复用的检查清单和抓包技巧我自己的习惯是遇到网络问题先画四层从下往上排除。物理层看网卡和链路状态网络层看 IP、路由和 ICMP传输层看端口和握手应用层看协议和日志。这个顺序能避免一上来就翻业务代码。下面这张检查清单可以贴在工位上。层级检查项命令或工具通过标准物理层网卡是否 UPip link状态 UP有 MAC数据链路层ARP 是否解析arp -a或ip neigh目标 IP 有 MAC网络层IP 和路由ip addr、ip route有默认网关路由可达网络层ICMP 可达ping有回包丢包率低传输层端口监听ss -tunlp目标端口 LISTEN传输层TCP 握手tcpdump、nc看到 SYN/SYNACK/ACK应用层协议响应curl、dig、业务日志状态码正常数据完整抓包时我一般用tcpdump先看有没有包再用 Wireshark 看协议细节。tcpdump的-w可以把包存成 pcap 文件方便后续分析。# 抓取 8080 端口的前 100 个包保存到文件 tcpdump -i any -nn -c 100 -w /tmp/tcp8080.pcap tcp port 8080-c 100表示抓满 100 个包就停-w写文件。分析时重点看三次握手是否完成、有没有 RST、有没有重传。如果看到大量重传说明链路质量差或拥塞如果看到零窗口说明接收端处理不过来。这些信号比应用日志更早暴露问题。最后说一个我踩过的坑曾经在一个嵌入式项目里UDP 发送端一直正常接收端偶尔丢包查了两天才发现是接收缓冲区太小突发流量一来就溢出。后来把SO_RCVBUF调大并加了应用层序号问题才稳定。网络基础知识不是背出来的是抓包抓出来的。希望帮到你。本文还有配套的精品资源点击获取