我当年备考计网、后来面试别人最大的感受是计算机网络的知识点本身不难难的是它们太散。一会儿讲 TCP 三次握手一会儿讲子网掩码一会儿又跳到 HTTP 状态码如果不把逻辑主线串起来学完就像抓了一把沙子什么都记不住。这篇文章我就站在一个实际从事网络技术工作的角度把计网知识点里的主干内容重新梳理一遍分清楚哪些是必须死磕的哪些只要会用就够。无论你是正在复习考试的学生还是准备后端、运维岗位面试的开发者这套框架都能直接帮你省掉大量走弯路的时间。1. 计网知识点到底在学什么先建立整体框架1.1 为什么分层模型不是背出来而是用出来的很多人一上来就被 OSI 七层模型劝退物理层、数据链路层、网络层、传输层、会话层、表示层、应用层背得头疼。我想说的是七层模型更多是理论参考实际网络世界基本按照 TCP/IP 的四层来运转应用层、传输层、网络层、网络接口层。网络通信的本质就是两个进程之间聊天。但数据要跨过物理线路就得有人管衔接、管寻址、管纠错。分层的好处很简单每个环节拆成独立模块上层不关心下层怎么实现下层只要向上层提供约定好的接口就行。你不需要在应用层代码里纠结数据怎么在网线上变成电信号这正是分层要解决的问题。换句话说分层不是让你背协议的清单而是让你在排障的时候有一个明确的排查方向问题到底出在应用层、传输层、网络层还是链路层。还有一个容易忽视的细节七层模型的会话层和表示层在 TCP/IP 四层模型里基本被合并到应用层里了。面试时如果有人把两者搞混我会建议他用 TCP/IP 四层模型去串知识点而不是硬套 OSI。因为真实的路由器、交换机、防火墙在转发时完全不关心 session 和 presentation 这层的东西。1.2 一次数据发送的完整链路抓包看到的真实面貌假设你在浏览器里访问一个网站这个请求从按下回车到页面展示数据经历了这样几个封装动作应用层先产生 HTTP 请求内容传输层在它前面加上 TCP 头也就是源端口、目的端口、序号、校验和这些东西网络层再往前面加 IP 头包括源 IP、目的 IP、TTL到了网络接口层还要加上目的 MAC 地址、源 MAC 地址和帧校验序列最后变成光信号或者电信号送出网口。对端收到数据后反过来操作从网卡驱动往上每层剥掉属于自己的头部直到应用进程拿到原始请求。这个过程叫“封装”和“分用”两个词听着专业用快递包裹类比就通了IP 地址是你要寄到哪个城市MAC 地址是小区里的具体门牌号TCP 头是收件人姓名和签收要求而包裹里的货物才是真正的应用数据。这也是为什么抓包工具里能看到一堆头部字段。我建议刚开始学计网的人不要只看书抓几个真实的 TCP 包、HTTP 包看一眼比背诵十遍结构体定义都有用。工具推荐 Wireshark过滤表达式tcp.port 80之类十分钟就能上手。2. 从比特到以太网物理层与数据链路层的核心2.1 MAC地址与ARP协议排查“同网段不通”的第一站数据链路层最常考的两个知识点一个是 MAC 地址一个是 ARP 协议。MAC 地址长度 48 位通常写成十二个十六进制字符前 24 位是厂商编号后 24 位是设备序号。它在局域网里是唯一标识一块网卡的逻辑编号。但这里有个关键问题一个 IP 报文到了局域网里怎么知道该发给哪块网卡这就是 ARP 干的活。发送方会广播一条消息谁的 IP 是 192.168.1.1麻烦把你的 MAC 地址告诉我。目标主机收到后单独回一条 ARP 应答双方同时把这条映射关系缓存到本地 ARP 表里缓存的时长一般只有几分钟防止设备搬走或换网卡之后缓存失效。实际排障中同网段内某台机器突然 ping 不通但其他机器正常我会先清一下 ARP 缓存再看。Windows 上执行arp -dLinux 上执行ip neigh flush dev eth0然后重新 ping 一次问题经常就这么解决了。不要一开始就去抓包分析太浪费时间。记住 ARP 是链路层协议走的是广播如果交换机开启了端口隔离那同网段也可能 ARP 不通。2.2 以太网帧与VLAN交换机为什么不广播所有数据以太网帧里最重要的字段是目的 MAC、源 MAC、类型、数据和帧校验序列。交换机依据 MAC 地址表转发数据帧但 MAC 地址表不是天生的靠学习。一台设备第一次发送数据时交换机会记录“这个 MAC 来自哪个端口”之后再有发往这个 MAC 的数据帧就直接转发到对应端口避免全网广播。不过什么是 VLAN它解决的是广播域过大和安全隔离的问题。如果你不划分 VLAN整个二层网络就是一个广播域任何一台机器发广播包其他几百台都得处理网络质量很容易劣化。VLAN 通过给帧打上 VLAN Tag把物理网络切成多个逻辑网络。比如把办公区和服务器区放在不同 VLAN办公区的广播不会影响服务器区同时可以通过三层路由控制谁访问谁。很多初学者搞不懂交换机和路由器的边界交换机负责二层转发依靠 MAC路由器负责三层转发依靠 IP。两台设备要跨 VLAN 通信需要走三层接口可以是路由器也可以是三层交换机的 VLANIF 接口。这是计网知识点里最容易考问的组网细节答清楚这一条面试观感会提升不少。3. 网络层与IP地址子网划分和路由的实操3.1 IP地址分类、CIDR与公有私有地址IPv4 地址一共 32 位分为网络部分和主机部分。老式的分类地址把地址分成 A、B、C、D、E 五类其中 A 类第一字节 1 到 126B 类 128 到 191C 类 192 到 223。但这样分太死板现在实际使用中用得最多的是 CIDR也就是无类别域间路由写法是一个 IP 后面加斜杠和前缀长度比如 192.168.1.0/24。/24 表示前 24 位是网络位后 8 位是主机位所以这个网段一共 256 个地址去掉网络地址和广播地址可用主机地址是 254 个。题目里如果让你算 192.168.1.5/26 的网络地址最快的方法是看掩码 /26 对应 255.255.255.192每个子网大小是 64那么 0-63 是一个子网64-127 是第二个以此类推。192.168.1.5 落在 0-63 段网络地址就是 192.168.1.0广播地址是 192.168.1.63。私有地址段需要背熟10.0.0.0/8172.16.0.0/12192.168.0.0/16。这些地址只能在组织内部使用不能直接出现在公网路由表里。公网上跑的只能是公网 IP内网设备要上外网就要靠 NAT 把私有地址转换成公网地址。NAT 不是协议而是一种地址转换机制这也是 IPv4 地址枯竭背景下最常用的技术之一。3.2 子网划分计算步骤一次讲清楚很多教程把子网划分讲得很玄其实就一套流程确认原始网段的掩码和主机位数。根据需要的子网数量确定要借几位。每个子网内需要的可用地址数为 A则主机位至少要满足 2^(主机位) - 2 大于等于 A。借位后新掩码长度等于旧掩码加借位数。用“块大小”计算每个子网的范围。块大小等于 256 减去新掩码对应字节的十进制值比如掩码 255.255.255.192块大小是 64。举个例子把 192.168.1.0/24 划分成 4 个子网。需要从主机位借用 2 位新掩码是 255.255.255.192。块大小等于 64因此子网依次是 192.168.1.0/26、192.168.1.64/26、192.168.1.128/26、192.168.1.192/26。每个子网可用 IP 从网络号加 1 到广播号减 1也就是 62 个可用地址。实际运维中这个技能用于规划办公网段、设备网段、服务器网段。我见过不少人直接用 192.168.1.0/24 一铺到底所有设备一个大广播域出了问题全部受影响。稍微懂一下子网划分把监控和设备单独放到一个 /26 的网段里故障半径就会小很多。另外面试时常见陷阱问“可用主机数”记得要减掉两个保留地址网络地址和广播地址都不能分配给主机。3.3 路由下一跳与最长前缀匹配数据包是怎么找出口的数据包在网络上不是走一步问一步而是查路由表决定下一跳。路由表里最关键的是目标网段、掩码、下一跳地址和出接口。当路由器收到一个目标 IP 为 8.8.8.8 的数据包它会拿这个 IP 去匹配路由表里所有表项如果有多条匹配采用最长前缀匹配原则。也就是说掩码越长表示的路径越具体优先级越高。这个原则非常好理解一个包要去 192.168.1.5路由表里同时有 0.0.0.0/0 默认路由和 192.168.1.0/24 路由那它一定走 192.168.1.0/24因为前缀更长。默认路由是最后一根救命稻草只有前面都匹配不上才走它。动态路由协议里OSPF 用的是开销值选路BGP 用的是无数路径属性。当时我接触真实网络时发现最长前缀匹配这个知识点远比协议细节更重要因为它决定了一个数据包的真实转发行为。排查路由问题时第一步永远是show ip route或者ip route看期望的网段是不是在路由表里以及下一跳是否可达。4. 传输层TCP和UDP的选择题4.1 TCP三次握手与四次挥手面试必考但经常讲不透TCP 三次握手的过程客户端发 SYN服务端回 SYNACK客户端再回 ACK。为什么不是两次因为握手过程要让双方都确认自己和对方的收发能力没有问题。第一次握手后服务端知道客户端能发第二次握手后客户端知道自己能发能收也确认服务端能发能收第三握手后服务端确认客户端能收。如果没有第三次服务端无法确认客户端是否已经具备接收数据的能力会留下一个连接半开状态。我面试时经常听到有人背“防止已失效的连接请求突然传到服务端”这句话本身没错但你要能解释清楚如果只有两次握手客户端历史上发出的延迟 SYN 报文万一到达服务端服务端会直接分配连接资源然后一直等数据造成资源浪费。三次握手可以避免这种情况因为客户端这边没有继续发 ACK服务端收不到最终确认就会放弃这个半连接。四次挥手类似主动关闭方发 FIN对端回 ACK对端再发 FIN主动关闭方回 ACK。这里真正容易踩坑的是 TIME_WAIT 状态。主动关闭方在发送完最后的 ACK 后不会立刻进入关闭而是进入 TIME_WAIT通常等 2MSL 后才释放端口。为什么首先保证最后一个 ACK 如果丢了还有机会重传其次让旧连接里的所有延迟包在网络中自然消亡防止污染新连接。线上如果有大量连接处于 TIME_WAIT很多时候是服务端主动关闭连接且短连接请求量很高造成的。排查手段先看监听端口和 keep-alive 配置而不是急着调整内核参数。4.2 TCP的窗口机制流量控制与拥塞控制TCP 的可靠传输依靠序号、确认号、重传和窗口。窗口分成两个概念很多人会混到一起流量控制和拥塞控制。流量控制是接收方限制发送方的发送速度。接收方会在确认报文里带上自己的接收窗口大小告诉发送方“你最多再发这么多多了我收不下”。这类似于两个人合作搬砖一个人在中场喊停另一个人就得停下。接收方缓冲区快满了窗口就缩小处理完了窗口再扩大。拥塞控制是发送方推测网络线路的承载能力。它和接收方无关即使接收方窗口很大网络中间路由器也可能因为排队溢出而丢弃报文。TCP 的拥塞控制主要有慢启动、拥塞避免、快速重传和快速恢复。慢启动阶段拥塞窗口从很小开始每收到一个确认就翻倍直到达到慢启动阈值。超过阈值后进入拥塞避免阶段窗口线性增长。一旦发生超时阈值降到当前窗口的一半窗口重新从最小值开始。快速重传则是收到三个重复 ACK 时不等超时立刻重传数据。实际工作中你不需要背每个算法细节但需要知道TCP 的性能瓶颈不一定是带宽很多时候是延迟和重传。内网传输慢先抓包看有没有 TCP 重传和乱序而不是一味调大缓冲区。4.3 UDP完全不靠谱吗为什么像直播这类场景离不开它UDP 头只有 8 个字节没有序号、没有确认、没有连接状态发出去就完了。它不保证可靠但换来了极低延迟和开销。像语音通话、视频直播、实时游戏这种场景如果一丢包就重传反而会把延迟拉高到无法接受。哪怕偶尔丢几个音频帧也比拖到下一秒才到要好用户感知明显是流畅更关键。所以选型上我一般会这样判断对可靠性和顺序要求高的场景用 TCP比如 HTTP、文件传输对实时性要求高且能容忍少量丢失的场景用 UDP比如 RTP 语音流、游戏同步。另外后来出现的一些抽象层比如 QUIC本质上是基于 UDP 重新实现了一套可靠传输既保留了 UDP 的低延迟特征又解决了队头阻塞问题。这算是一个加分知识点面试时主动提一句 QUIC 和 HTTP/3 的关系会体现你确实在跟进网络技术。5. 应用层HTTP、DNS与HTTPS三剑客5.1 HTTP请求流程与状态码记忆思路一个完整的 HTTP 请求从客户端到服务端会经历 DNS 解析、TCP 三次握手、发送请求行和头部、服务端处理、返回状态码和响应体。HTTP 协议本身是无状态的所以才有 Cookie 和 Session 机制来补足状态管理。状态码是高频考点我建议按分类记忆2xx 表示成功3xx 表示重定向4xx 表示客户端错误5xx 表示服务端错误。具体来说200 是正常响应301 是永久重定向302 是临时重定向304 表示资源未修改可以继续用本地缓存400 是请求语法有问题401 是未认证403 是权限不足404 是资源不存在500 是服务端内部错误502 是网关收到上游无效响应503 是服务不可用504 是网关超时。排障时很多人一看 502 就去查服务进程这不一定对。502 是网关和后端之间出了问题应该先看后端有没有挂再看网关到后端的网络通不通。而 504 更重点看后端处理时间有没有超过网关超时阈值。状态码本身很简单但结合场景判断才是工作里的真功夫。另外一个实际经验遇到接口返回 404 时不要只检查 URL 路径还要确认代理和网关的转发规则有时正是转发规则丢了路径前缀才导致 404。5.2 DNS解析过程排障时比背知识点更重要DNS 负责把域名解析成 IP。我见过很多人只背流程不会排障。实际上完整的解析过程是这样的浏览器缓存、操作系统缓存、本地 DNS 服务器、根 DNS 服务器、顶级域名服务器、权威域名服务器。根服务器、顶级域名服务器、权威服务器这种链路你用 nslookup 跟一次就能看懂。比如说nslookup -typeNS example.com可以查看权威服务器nslookup example.com 8.8.8.8可以指定服务器解析。线上遇到域名解析慢或者解析结果不一致先看一眼本地 DNS 配置再检查有没有走公共 DNS然后看权威服务器上记录是否有变更传播延迟。记住DNS 使用 UDP 53 端口做主查询但区域传送使用 TCP 53。解析响应如果超长也会转用 TCP。实际工作中我踩过的一个坑是改了域名解析记录但本地缓存一直不生效。原因就是本地 DNS 服务器缓存 TTL 还没过期只能等。所以以后改记录前先调低 TTL 到比如 60 秒改完再调回去这是标准操作。面试时你如果能把这一套流程和排障思路讲清楚效果比干背概念强很多。5.3 HTTPS在握手过程中做了什么HTTPS 就是在 HTTP 和 TCP 中间加了一层 TLS 加密默认端口 443。TLS 握手核心目的只有一个在双方不预先共享密钥的情况下商量出一个只有两人知道的会话密钥后续所有内容都用这个密钥做对称加密。握手过程大致如下客户端发 ClientHello带上支持的 TLS 版本、随机数、加密套件。服务端回 ServerHello选定加密套件带上自己的证书和随机数。客户端验证证书合法性确认服务器身份后生成一个预主密钥用证书里的公钥加密发给服务端。服务端用私钥解密拿到预主密钥。双方根据两个随机数和预主密钥各自生成相同的主密钥之后通信全部使用对称加密。为什么要数字证书我经常用一句话解释为了防中间人。公钥本身可以被替换如果有人在你和服务器中间截获公钥再伪造一个公钥给你你就完全被欺骗。数字证书相当于由第三方机构证明“这个公钥确实属于这个域名”。验证链路是浏览器信任根证书根证书签发中间证书中间证书再签发网站证书一层一层向上验证。实际运维中证书过期是 HTTPS 故障的最高频原因。处理方式是用工具批量监控证书有效期而不是等到浏览器报错再补救。另外部署证书时要保证完整链书配置齐全很多服务器只贴了域名证书漏掉中间证书导致部分客户端验证失败。6. 常见问题与排障经验实录6.1 高频面试问题速查表下面是几个我实习面试和招聘候选人都遇到的题目附上解题切入点问题关键思路TCP 和 UDP 的区别连接状态、可靠性、头部开销、使用场景为什么 TCP 连接是三次握手不是两次防止旧连接请求造成资源浪费确认双方收发能力四次挥手为什么要有 TIME_WAIT保证最后的 ACK 能重传让旧包自然消亡ifconfig 或 ip addr 看到 inet 是什么IPv4 地址、掩码、广播地址的解析一台电脑能同时和外部建立多少 TCP 连接受四元组限制与文件描述符、端口范围有关/24 和 /16 的区别网络位长度、可用主机数、广播域大小HTTP 和 HTTPS 的端口80 与 443TLS 握手差异DNS 解析具体过程缓存、递归、迭代、权威服务器表格里的问题都不算刁难但能把每个问题往下追问两三层的人不多。比如问你“TCP 和 UDP 的区别”你除了答可靠性和连接还能说头部开销、流量控制和拥塞控制、有序性以及适合什么场景这就够了。6.2 从应用层到物理层的排障顺序网络排障不要跳着查按层往下走效率最高。第一步确认应用层。看浏览器或客户端报什么错是超时、连接拒绝还是响应码异常。第二步看 DNS。域名能解析吗nslookup或者dig short快速确认。第三步测 TCP 连接。telnet ip port或者用nc -vz ip port看端口通不通。第四步测网络层。ping网关再ping远端地址观察丢包和延迟。第五步查链路层。看 ARP 是否正常网卡有没有 Down交换机端口是否 up。这套顺序的逻辑是先把“上层有没有正常工作”搞清楚再往底层找原因避免一开始就钻到数据链路里。比如端口不通可能只是防火墙把端口封了但你却一直在抓包分析 SYN 重传浪费大量时间。我自己的习惯是执行每个命令时都把输出完整看一遍而不是只看 ping 通没有。ping 通不意味着网络好延迟高、抖动大、丢包时通时断都需要看统计信息。6.3 我踩过的几个坑希望你别再踩第一个坑是刚学会抓包就喜欢什么都抓结果被大量 TLS 加密流量淹没。后来我习惯先关掉不相关的端口过滤只关注当前问题的会话流。抓包时如果发现客户端发了很多 SYN 重传不要急着怀疑丢包先用ss -anp看看服务端有没有进程在监听那个端口很多时候就是服务没起来或者防火墙拒绝。第二个坑是把 NAT 和代理概念混在一起。NAT 是三层或四层的地址转换通常发生在路由器或防火墙上应用层代理工作在第七层客户端把请求发给代理代理再代替客户端去访问目标服务。两者解决的核心问题不一样哪怕工作场景都是让内网设备访问外网面试时混着答容易暴露概念不牢。第三个坑是忽略 MTU 对网络性能的直接影响。两个网络设备 MTU 不一致时大概率会出现 TCP 传输慢、大包不通、小包正常的情况。遇到这种问题先看链路两端的 MTU 设置再用带 DF 标志的大包ping测试分片行为。学计网知识点如果不做实验很多结论都只是停留在文字层面。最后再分享一个我个人很受用的学习方法每学完一个协议就自己画一条完整的通信链路出来先是什么请求哪一层加什么头对端怎么处理画出问题在哪里断开。计网知识点最核心的价值不在于你能默写出多少协议字段而在于遇到一个真实网络问题时你能顺着这条链路快速判断“这问题大概出在哪一层”然后直接去那一层查证据。这套技能才是任何面试和岗位里真正能拉开差距的东西。
