计算机网络是计算机相关专业里一门绕不开的核心课，也是一门“看着简单、学起来容易飘”的课。很多人捧着教材从第一章看到最后一章，协议背了不少，但一问到“两台电脑之间发一个网页请求，中间到底发生了什么”就卡壳；或者该记得的IP地址分类、TCP三次握手都答得上来，但实际网络一到手就不知道怎么排查。这篇内容不是要把教材重新抄一遍，而是把真正影响你理解、考试、面试和日常排障的那些核心知识点全部拆开揉碎，讲清楚它们是什么、为什么存在、怎么用，以及最常见的坑在哪里。适合正在复习备考的学生、准备网络方向面试的开发者，以及工作中需要自己动手排查网络问题的人。
1. 分层模型：网络为什么非要分层
1.1 OSI七层模型与TCP/IP四层模型的对应关系
只要学过网络，一定绕不开OSI七层模型。很多人觉得这玩意儿纯粹是考试要背的名字，实际工作中根本没人按七层说话。这话说对了一半：七层模型确实太理想化，实际互联网用的是TCP/IP四层模型。但七层模型的思路——分层——恰恰是整个计算机网络最核心的设计哲学。
先理清对应关系，这张表是基础中的基础：
| OSI七层 | TCP/IP四层 | 典型协议与设备 | 核心职责 |
|---|---|---|---|
| 应用层 | 应用层 | HTTP、DNS、FTP、SMTP | 为用户应用提供网络服务 |
| 表示层 | （合并入应用层） | 数据加密、压缩、格式转换 | 解决数据格式差异 |
| 会话层 | （合并入应用层） | 会话建立与维持 | 管理通信双方会话 |
| 传输层 | 传输层 | TCP、UDP | 端到端可靠传输或尽力传输 |
| 网络层 | 网络层 | IP、ICMP、路由协议 | 逻辑寻址与路径选择 |
| 数据链路层 | 数据链路层 | 以太网、交换机、MAC地址 | 相邻节点间帧的传输 |
| 物理层 | 物理层 | 网线、光纤、中继器 | 比特流的物理传输 |
这里面有个特别值得注意的点：TCP/IP模型把OSI高三层合并成了应用层，因为在实际工程里，表示层和会话层的工作（编码、压缩、加密）往往由应用自己处理，或者由协议内部实现，不需要独立成层。所以你在抓包工具里看到的，最上层直接就是HTTP或者TLS，不会单拎出来一个“表示层”让你调试。
1.2 分层的本质：每一层只解决自己的问题
我见过太多人学完网络还是晕，根本原因就是没有真正理解“为什么要分层”。打个生活中的比方：你寄快递，不需要自己造一辆卡车，也不需要自己修高速公路，你只需要写好地址、把包裹交给快递员，剩下的事由快递系统内部处理。每一层只用关心自己负责的那段流程，不需要知道其他层的内部细节。
放到网络里就是：应用层不用关心数据是怎么从北京到上海的电信号编码，传输层不用关心走的是光纤还是无线，网络层不用关心数据链路层用的是以太网还是其他技术。每一层给上层提供服务，同时只依赖下层提供的服务。这就是“单向依赖、逐层封装”的分层原则。
数据在发送端从上往下逐层打包，每层加一个头部（有的层还会加尾部）；到达接收端后从下往上逐层解包。这个过程叫“封装”和“解封装”。你可以把它想象成套娃：应用的数据被装进TCP的“信封”，TCP的“信封”被装进IP的“信封”，IP的“信封”再被装进以太网的“信封”，最后变成电信号发出去。接收方每拆一层，就能看到对应层需要的信息，再往上层传递。
2. 数据链路层与物理层：数据怎么在链路上跑起来
2.1 物理层的核心：带宽、时延与传输介质
物理层看上去知识点多且杂——什么编码方式、调制技术、复用技术——但真正需要重点掌握的其实就三个指标和一个概念。
三个指标是：带宽、时延、吞吐量。带宽是链路能承载的最大数据传输速率，单位是bit/s；时延包括发送时延、传播时延、处理时延和排队时延；吞吐量是实际每秒成功传输的数据量。考试和面试最喜欢问的一个坑是：带宽大的链路不意味着时延就一定低，因为传播时延由物理距离决定，跟带宽无关。你用光纤和用铜缆传同一个数据包，如果距离一样，传播时延基本一样，差的是发送时延。
一个概念是“比特流传输”。物理层干的事就是把数据链路的帧转换成可以在介质上传输的电信号、光信号或无线信号，不做差错控制、不做寻址。很多同学容易把物理层和数据链路层搞混，记住一句话：物理层只负责把一个一个比特搬到对面，不管搬得对不对；检查搬得对不对，是数据链路层的职责。
2.2 数据链路层的封装成帧与透明传输
数据链路层工作的基本单位是“帧”。发送方把网络层下来的IP数据报加上帧头和帧尾，变成一个帧；接收方收到后，根据帧头和帧尾把帧解开，取出里面的网络层数据报。这个过程叫封装成帧。
封装成帧有两个关键问题：一是帧定界，即接收方怎么知道帧从哪里开始、到哪里结束，每个协议的定界方式不同，像以太网用前导码和帧间隙来定界；二是透明传输，即数据中如果出现了和帧定界符一样的比特组合，怎么不让接收方产生误判。
解决透明传输的经典办法有两种：字节填充和比特填充。字节填充常见于面向字符的协议，在数据里遇到特殊字符就加一个转义字符；比特填充是HDLC这类面向比特的协议用的，在连续5个1后面插入一个0。这两种方法本科考试经常出题，但实际工作中更多是你理解了“透明传输是保证数据内容不被误读”这个思想就够了。
2.3 MAC地址、以太网帧与交换机的工作机制
MAC地址是数据链路层设备的物理地址，48位，通常写成十六进制的6组数，比如AA-BB-CC-DD-EE-FF。它是出厂时烧录在网卡上的，正常情况下全球唯一。以太网帧里有源MAC地址和目的MAC地址，帧格式大概是：目的MAC（6字节） + 源MAC（6字节） + 类型（2字节） + 数据（46~1500字节） + FCS（4字节）。
交换机是数据链路层的关键设备，它的工作机制特别有意思。交换机内部有个MAC地址表，记录“哪个MAC地址在哪个端口”。当一个帧到达交换机时，它会查表：
- 如果帧的目的MAC地址在表里，直接从这个对应端口转发出去；
- 如果不在表里，就向除了接收端口以外的所有端口广播这个帧，收到回复后学习源MAC地址，记录进表；
- 如果目的MAC地址正好是接收端口下的设备，就丢弃不转发。
所以交换机是“先广播、后学习、再精准转发”。MAC地址表有老化时间，默认一般是300秒，老化之后又要重新学习。这个机制在实际网络排障里经常遇到——比如网线换了端口，短时间内交换机可能还按老端口转发，造成网络不通，等表老化或清空后就好了。
2.4 差错检测：CRC循环冗余校验
物理链路谁都不敢保证不出错，差错检测就是数据链路层除了寻址之外最重要的职责。最常用的检错机制是CRC（循环冗余校验），它和简单的校验和（比如IP头里的checksum）原理不一样。
CRC的做法是：发送方把帧的数据部分看成一个很大的二进制数，除以一个双方约定好的生成多项式对应的二进制数，得到的余数作为FCS帧校验序列，附在帧尾发送。接收方收到后用同样的除法计算，如果余数为0就认为帧没错，否则丢弃或要求重传。
这个生成多项式的选择很讲究，不同的生成多项式检错能力不一样。像CRC-32被用在以太网里，检错能力非常强，能检测出所有长度小于等于32位的突发错误。注意一个常见误区：CRC能检错，但不能纠错。数据错了只能重传，所以它叫“检错码”而不是“纠错码”。真正能纠错的是海明码这类前向纠错码，但这类码开销大，链路层很少用。
3. 网络层：IP寻址、路由与跨网通信
3.1 IPv4地址、CIDR与子网划分计算
网络层的核心是IP协议，它解决的是“逻辑寻址”问题。IPv4地址是32位，通常写成点分十进制，比如192.168.1.100。IPv4地址由网络号和主机号两部分组成，早期按A/B/C类分类，后来因为太浪费，改用CIDR无类别域间路由。
CIDR的写法是在IP地址后面加一个斜杠和前缀长度，比如192.168.1.0/24，表示前24位是网络号，后8位是主机号。这个前缀长度就是子网掩码中1的个数，255.255.255.0对应/24。
子网划分的题目是考试和面试的高频考点，也是最容易算错的地方。给你一个具体的例子算一遍，你就彻底明白了。
假设公司拿到了一个网段192.168.10.0/24，需要划分成4个子网，每个子网能容纳约60台主机。怎么分？先把/24看成8位主机位，要分成4个子网，需要从主机位借2位（2的2次方等于4）。借了2位后，子网掩码变成/26，也就是255.255.255.192。每个子网的主机位数是6位，可用主机数是2的6次方减2，也就是62台，满足60台需求。
4个子网的网络地址分别是：
192.168.10.0/26（可用主机：1~62）192.168.10.64/26（可用主机：65~126）192.168.10.128/26（可用主机：129~190）192.168.10.192/26（可用主机：193~254）
每个子网的广播地址是主机位全1的地址，即每个子网最后一个地址，比如第一个子网的广播地址是192.168.10.63。算的时候一定要记得“主机位全0是网络地址，全1是广播地址，这两个都不能分配给设备用”。
3.2 ARP协议：IP地址怎么变成MAC地址
说到IP寻址，就绕不开ARP（地址解析协议）。网络层的数据包要真正发出去，必须封装成数据链路层的帧，而帧里填的是目的MAC地址。问题来了：我只有对方的IP地址，怎么知道它的MAC地址？
ARP的机制是：发送方在本地广播一个ARP请求报文，内容是“谁的IP是192.168.1.1？请告诉我你的MAC地址”，局域网内所有设备都能收到这个广播，但只有IP地址匹配的那台设备会回复自己的MAC地址。发送方收到回复后，把IP和MAC的对应关系缓存到ARP表中，下次直接查表，不用再广播。
ARP表有老化时间，不同系统不一样，Windows一般是2分钟，Linux一般是几十秒到几分钟。ARP也是网络安全中容易被利用的协议——有人可以伪造ARP应答报文，把一个IP地址对应到错误的MAC地址上，实现流量劫持。这也是为什么现在很多网络会做动态ARP检测或绑定MAC地址的原因。我在实际排查“一个网段里部分设备上网时好时坏”的问题时，第一件事就是查ARP表是否异常。
3.3 ICMP：ping和traceroute的实现原理
ICMP（互联网控制报文协议）经常被误认为IP协议的一部分，其实它是IP层的一个辅助协议，用来传递差错报告和控制信息。你最熟悉的ping就是基于ICMP的，它发送ICMP回声请求报文（Echo Request），对方收到后回复回声应答报文（Echo Reply），ping命令就能统计往返时延和丢包率。
ping不通不一定代表网络不通，这是一个特别重要的排障意识。因为很多网络设备为了防止探测，默认会丢弃ICMP报文。换句话说，ICMP被屏蔽了，HTTP业务可能照样正常。这就是为什么你ping不通某台服务器，但浏览器打开它的网页却正常——别一上来就判断网络故障，先把场景搞清楚。
traceroute（Windows下叫tracert）也是基于ICMP，但它的原理要巧妙得多。它发送一系列UDP报文，第一组TTL设为1，路由器收到后TTL减为0，就会丢弃报文并向源地址发回一个ICMP超时报文，源主机就知道路径上的第一跳是谁。然后TTL设为2、3、4……每经过一台路由器就返回一个超时报文，这样就把整条路径的每一跳都摸清了。通过观察每一跳的时延变化，也能大概判断瓶颈出在哪一段。
3.4 路由协议：路由器怎么选择路径
路由器是网络层的核心设备，它通过路由表决定数据包从哪个端口转发出去。路由表的来源有三种：直连路由（路由器自己直连的网段）、静态路由（管理员手工配置）、动态路由（路由协议自动学习）。
动态路由协议里，经常需要对比的是距离矢量协议和链路状态协议。RIP是典型的距离矢量协议，它只跟邻居交换“我到某个网段有多远”的信息，用跳数做度量，最大跳数15，超过就认为不可达。RIP实现简单，但收敛慢，大型网络不适合，现在已经很少用了。
OSPF是链路状态协议，核心思路是让全网所有路由器都了解整个网络的拓扑结构，每台路由器把自己知道的链路状态信息广播出去，最终所有路由器都有一张完整的网络地图，再用Dijkstra算法算出到每个网段的最短路径。OSPF收敛快、支持大型分层网络，是目前企业内网最常见的动态路由协议之一。
BGP则是自治系统之间的路由协议，运行在全球互联网的骨干路由器之间。BGP把互联网看成一张由无数个自治系统组成的图，它不找最短路径，而是基于各种策略选择路径——商业关系、流量成本、政治因素都会影响路由选择。考试只需要知道BGP是“策略路由”而非“最短路径路由”就够了。
3.5 NAT、网关与私有地址
私有IPv4地址段是学校和企业网络里最常见的地址段，RFC 1918规定了三个私有网段：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。私有地址不能直接在公网上路由，必须通过NAT转换后才能访问互联网。
NAT最常用的形式是NAPT（网络地址端口转换），也叫端口多路复用。它把内网很多个私有IP和端口映射到同一个公网IP的不同端口上。比如内网两台主机192.168.1.10:50000和192.168.1.11:50000同时访问同一个网站，路由器会把它们映射成公网IP的50001和50002端口，等应答回来后再根据端口号反查映射表，把数据包正确送达对应主机。
理解了这个机制，很多问题就好解释了：为什么你家里的宽带虽然只有一个公网IP，但全家手机电脑都能同时上网；为什么内网服务器要从外网访问必须做端口映射，而不能直接“访问内网IP”；为什么NAT会让P2P连接变得困难，因为外部主机无法主动向内网主机发起连接。
网络层的“网关”也是一个高频概念。网关就是连接两个不同网段的“门”，在主机配置里通常是路由器接口的IP地址。主机要访问不同网段的设备时，数据包会先发给默认网关，由网关帮你转发。排障时判断“网络通不通”的粗略方法就是：先ping网关，再ping外网，如果网关都ping不通，问题大概率出在链路或本机配置上。
4. 传输层：TCP与UDP的全面剖析
4.1 TCP报文段格式与关键字段
传输层在TCP/IP中承担的是端到端通信的职责。TCP报文段格式里有几个关键字段必须非常熟悉：源端口、目的端口、序号、确认号、数据偏移、标志位（URG、ACK、PSH、RST、SYN、FIN）、窗口大小、校验和。
序号的作用是保证字节流有序。TCP把应用层传来的数据看成一个字节流，每一个字节都会编一个号。报文段的序号表示“这个报文段第一个字节的序号”。确认号表示“期望收到对方下一个字节的序号”，同时它隐含了一个信息：确认号之前的所有字节都正确收到了。这种“累积确认”机制是TCP可靠传输的基础。
标志位里，SYN用于建立连接时同步序号，FIN用于关闭连接，ACK用于确认，RST用于异常复位连接。抓包的时候看到RST，基本就是连接出了异常——比如端口没监听、连接被防火墙重置、双方状态不一致。
4.2 三次握手：为什么不是两次或四次
TCP建立连接的三次握手可以看作一次同时进行的“号码对齐”过程：
- 客户端发送SYN报文，序号为x，进入SYN_SENT状态；
- 服务器收到后回复SYN+ACK报文，序号为y，确认号为x+1，进入SYN_RCVD状态；
- 客户端收到后发送ACK报文，确认号为y+1，双方进入ESTABLISHED状态。
有一个初学者最容易问的问题：为什么需要三次而不是两次？最核心的理由是：防止失效的连接请求突然到达服务器，导致服务器白白建立一条空连接。
举个经典例子：客户端第一次发的SYN报文因为网络拥堵被卡了很久，客户端等不到确认超时重传了一个新的SYN，后来第一次的SYN又到了服务器。如果只有两次握手，服务器收到两个SYN就会建立两条连接，浪费资源。三次握手时，服务器虽然收到了第一个SYN并回复了SYN+ACK，但客户端发现确认号不是自己期望的，就不会再发ACK，服务器等不到第三次ACK就放弃这条半连接。这样就能过滤掉历史失效的连接请求。
还有一层原因：三次握手能协调双方初始的序号。TCP要求双方各自维护一个初始序号，这个序号不仅要告诉对方“我从哪个字节开始编号”，还要得到对方的确认。只有双方都确认了对方的初始序号，双向可靠传输才能真正开始。
抓包验证三次握手也很直观：看三次报文的标志位和序号。第一条SYN（seq=x），第二条SYN+ACK（seq=y, ack=x+1），第三条ACK（seq=x+1, ack=y+1）。面试时能把这个具体数字标出来，比空谈“建立可靠连接”有说服力得多。
4.3 四次挥手与TIME_WAIT状态
TCP关闭连接要四次挥手，因为TCP连接是双工通信，每个方向都必须单独关闭：
- 主动方发送FIN报文，表示自己这边的数据发完了，进入FIN_WAIT_1状态；
- 被动方回复ACK，进入CLOSE_WAIT状态，主动方收到ACK后进入FIN_WAIT_2状态；
- 被动方也发送FIN报文，表示自己也准备关闭，进入LAST_ACK状态；
- 主动方回复ACK，主动方进入TIME_WAIT状态，被动方收到ACK后关闭。
注意第二步和第三步之间可能有时间差，因为被动方可能还有数据没发完，先ACK确认收到FIN，等数据发完再发FIN。这就是为什么挥手需要四次，不能合并成三次。
TIME_WAIT状态是很多人理解和排障的难点。主动关闭方在回复最后一个ACK后，要等待2倍MSL（最大报文段生存时间，一般2分钟）才能彻底关闭。原因是两点：一是防止最后一个ACK丢失，如果被动方没收到ACK会重发FIN，主动方还要能再回应；二是让本连接中所有旧报文都在网络中消失，避免它们干扰新连接。
高并发服务器上如果大量连接由服务器主动关闭，会出现很多TIME_WAIT状态的连接，占用端口和内存。处理办法通常是调整内核参数，比如开启net.ipv4.tcp_tw_reuse让TIME_WAIT连接能被安全复用，或者优化业务逻辑减少主动关闭连接。这些参数在网络优化时你会经常遇到。
4.4 流量控制与拥塞控制的区别
这是TCP最容易被混淆的两个机制。流量控制解决的是“发送方太快，接收方来不及处理”的问题，通过滑动窗口实现；拥塞控制解决的是“网络太堵，发送方要主动降低发送速率”的问题，通过慢启动、拥塞避免、快重传、快恢复四种算法实现。
流量控制的原理很简单：TCP报文头里的窗口大小字段就是接收方当前还能接收的字节数。发送方每次发送的数据量不能超过对方的接收窗口大小。这是端到端的协作——接收方告诉发送方自己有多大的“肚子”能装下多少数据。
拥塞控制的四种算法是面试和考试的重点：
- 慢启动：连接刚建立时，拥塞窗口从1个SMSS开始，每收到一个ACK就翻倍，指数增长；
- 拥塞避免：拥塞窗口增长到慢启动阈值后，改为线性增长，每个RTT只增加1个窗口大小；
- 快重传：收到三个重复ACK就立即重传丢失的报文，不等超时计时器；
- 快恢复：发生快重传后，拥塞窗口减半，然后进入拥塞避免阶段，而不是回到慢启动从1开始。
这几段算法的演进背景是：TCP早期用“超时重传”来感知丢包，效率很低；后来发现连续收到三个重复ACK说明网络还有接收能力，不必那么激进地降速。真正的难点在于理解这些算法都是在没有全局视角的情况下“猜测网络状态”，所以TCP也被称为“尽力而为网络上的可靠传输”。
4.5 TCP与UDP的选型对比
TCP和UDP的区别是基础中的基础，但实际项目里的选型反而值得多说一句。
| 特性 | TCP | UDP |
|---|---|---|
| 连接状态 | 面向连接 | 无连接 |
| 可靠性 | 可靠传输、有序到达 | 尽力传输、可能丢失或乱序 |
| 流量控制 | 有（滑动窗口） | 无 |
| 拥塞控制 | 有（四大算法） | 无 |
| 传输效率 | 相对低，头开销大 | 相对高，开销小 |
| 首部大小 | 20字节以上 | 8字节 |
| 典型应用 | HTTP、FTP、SMTP | DNS、音视频直播、游戏 |
很多做音视频传输的人会下意识选UDP，因为实时性要求高。但要注意，UDP不保证可靠性，一旦丢包就需要应用层自己做重传或前向纠错。还有一些新的传输协议（比如QUIC）本质上是基于UDP实现的“类TCP”协议，既保留了UDP的低延迟优势，又在用户态实现了可靠传输和拥塞控制。这说明协议选型不是简单看“TCP可靠就用TCP”，而是要看整个应用对延迟、吞吐、可靠性的综合需求。
5. 应用层协议：从HTTP到DNS的日常工程
5.1 HTTP协议演进与请求响应结构
应用层是你日常开发打交道最多的一层，而HTTP是其中出现频率最高的协议。HTTP从1.0到1.1再到2.0、3.0，每次演进都解决了一类工程痛点。
HTTP/1.0是“短连接”，每次请求都要建立一条TCP连接，效率很低。HTTP/1.1默认开启了持久连接（Keep-Alive），一个TCP连接可以发多个请求；同时引入了管道化，但实际中管道化用得不多，因为存在队头阻塞——前面的请求响应慢，后面的请求即使到了服务器也等在前面。HTTP/1.1还有一个Host头字段，让一台服务器能通过不同域名承载多个网站。
HTTP/2.0解决了队头阻塞问题，核心是多路复用。它把请求和响应都拆成二进制帧，多个请求的帧可以交错传输，一个TCP连接同时跑几十个请求没有问题。HTTP/2.0还支持头部压缩和服务器推送，性能明显提升。
HTTP/3.0则更进一步，把底层从TCP换成了基于UDP的QUIC。原因是TCP自己也有队头阻塞——一个TCP报文丢了，后续即使到了也得等重传。HTTP/3.0在用户态实现可靠传输和拥塞控制，能更快地处理丢包，移动网络弱网环境下表现更好。
HTTP请求报文结构包括请求行（方法、URL、版本）、请求头部（Host、User-Agent、Accept、Cookie等）、空行和请求体（GET无请求体）。响应报文结构包括状态行（版本、状态码、状态描述）、响应头部（Content-Type、Content-Length、Cache-Control等）、空行和响应体。状态码里常见的需要背熟：200成功、301永久重定向、302临时重定向、304未修改（走缓存）、400请求错误、401未认证、403禁止访问、404不存在、500服务器内部错误、502网关错误、503服务不可用、504网关超时。
5.2 DNS解析过程：从输入域名到拿到IP
DNS是互联网的“电话簿”，把域名解析成IP地址。它也是一个树状结构的分布式系统。完整解析过程是这样的：
- 浏览器先查本地DNS缓存，没有则查操作系统缓存，还没有则查本地hosts文件；
- 都没有，则向本地配置的DNS服务器（比如运营商或公共DNS服务器）发起递归查询；
- 本地DNS服务器如果自己没有缓存，就向根域名服务器发起迭代查询，根服务器返回顶级域服务器地址（比如.com的服务器）；
- 本地DNS服务器再去问顶级域服务器，得到权威服务器的地址；
- 本地DNS服务器再去问权威服务器，拿到具体的A记录；
- 本地DNS服务器把结果缓存起来，同时返回给客户端。
这里面“递归查询”和“迭代查询”的区别是考点：客户端向本地DNS服务器是递归（你帮我查到底），本地DNS服务器向根服务器及往下是迭代（我给你指路，你自己去问下一站）。
DNS记录类型里最常用的是A记录（IPv4地址）、AAAA记录（IPv6地址）、CNAME记录（域名别名）、MX记录（邮件交换服务器）、NS记录（域名服务器）。配置域名时还有个细节：TTL值决定了缓存时间，调低TTL能让DNS变更更快生效，但会增加查询压力；一般做迁移前会先把TTL调低，等迁移完成后再调回来。
排障中有一类经典问题：浏览器打开网页提示“找不到服务器IP地址”，但ping域名却正常。这种奇怪的差异往往是因为浏览器和系统用了不同的DNS解析流程，或者浏览器缓存了旧的错误结果。清缓存、换DNS、检查hosts文件，按顺序排查。
5.3 HTTPS与TLS握手过程
HTTPS不是独立于HTTP的新协议，而是HTTP协议加上TLS加密层。TLS握手的简化过程：
- 客户端发送ClientHello，包含支持的加密算法列表和随机数；
- 服务器回复ServerHello，选择加密算法，发送自己的证书和随机数；
- 客户端验证证书合法性（是否由可信CA签发、域名是否匹配、是否过期）；
- 客户端生成预主密钥，用服务器公钥加密后发送给服务器；
- 双方各自根据两个随机数和预主密钥，计算出相同的会话密钥；
- 双方发送Finished消息，确认后续通信都用会话密钥加密。
这个流程里有一个非常重要的考点：TLS握手用的是非对称加密来协商密钥，协商完成后的数据传输改用对称加密。原因是非对称加密慢，对称加密快。证书里包含服务器公钥，客户端用公钥加密预主密钥，只有服务器能用私钥解密。如果没有证书体系，中间人可以轻易伪造公钥劫持通信，所以证书的可信链是HTTPS安全的根基。
实际开发中你不需要记全部加密套件，但要理解几个概念：前向保密（即使服务器私钥泄露，历史通信也无法解密）、证书链校验、会话恢复（减少握手往返次数）。抓包时看到TLS握手至少两个RTT，用HTTP/2还会更快。
5.4 DHCP与常用应用层协议概览
DHCP是局域网里自动分配IP地址的协议。它的四个步骤是：Discover（客户端广播“我需要IP地址”）、Offer（DHCP服务器回应“我可以给你这个IP”）、Request（客户端广播“我就要这个IP”）、Ack（服务器确认并分配租约）。这个机制考试经常考，四个报文的类型和顺序要背清楚。
DHCP租约有个很重要的特点：第一次获取IP几乎都要等约一半租约时间后才会更新租约。电脑弹“IP地址冲突”往往就是局域网里有两个设备被分到同一个IP，排查时可以看看交换机上该IP对应的MAC地址是不是在两个端口之间跳变。
其他常见应用层协议也建议梳理一遍：FTP用来传文件，控制连接走21端口、数据连接走20端口；SMTP发邮件走25或465/587，POP3收邮件走110，IMAP收邮件走143；SSH远程登录走22。这些端口号不需要死记硬背，但你得有印象，因为服务配置、防火墙规则、抓包分析时都会遇到。
6. 常见问题排查与学习实战建议
6.1 高频认知误区：ping通不代表一切正常
我见过太多人把ping当成网络连通性的唯一判断标准，结果排障走了弯路。ping能通，只能说明ICMP报文能在两个IP之间往返，不能证明：
- 目标端口是开放的（TCP端口是否监听需要单独探测）；
- 应用层服务正常（Web服务进程挂了，但系统网络栈一样正常回ping）；
- 数据传输性能达标（ping时延低不代表丢包率低、吞吐量够）；
- 数据能从公网正确路由到目标（可能一个方向通，另一个方向不通）。
正确的排障思路是“逐层排查”：先看物理层（网线灯、WiFi连接状态），再看数据链路层（MAC地址、交换机端口状态），然后网络层（IP地址、网关、路由），传输层（端口连通性），最后才是应用层（服务日志、配置）。很多人一上来就重启服务，如果问题出在网络层，折腾半天也没用。
6.2 必会的排查命令与抓包分析方法
工作中最常用的网络排查命令，你要能做到脱口而出：
ping：测试IP连通性和时延；tracert/traceroute：查看经过的路径节点；ipconfig/ifconfig/ip addr：查看本机IP配置；netstat/ss：查看端口监听和连接状态；telnet/nc：测试TCP端口连通性；dig/nslookup：查看DNS解析结果；arp -a：查看ARP表；route/ip route：查看路由表。
抓包分析是提升网络理解最快的途径。用Wireshark抓一次HTTP请求，你能亲眼看到三次握手的三个报文、HTTP请求行和响应状态码、四次挥手的FIN报文。把课本上抽象的知识在抓包里对一遍，很多原来死记硬背的东西就变成了理所当然的事实。
个人建议从这三个实验开始做：第一，抓一次访问某个网站的完整HTTP请求，观察TCP握手和HTTP报文结构；第二，在命令行发起一次DNS查询并抓包，看客户端本机DNS请求发出去了没有；第三，找两台机器直连，手动配置IP后互相ping，观察ARP广播的过程。
6.3 高频面试题与避坑提示
网络方向的面试题，考来考去就那几个核心场景。你可以自己试着回答：
- 浏览器输入一个网址后，按下回车到底发生了什么？要完整说出DNS解析、TCP握手、HTTP请求、服务器处理、HTTP响应、浏览器渲染这条链路；
- 为什么TCP要三次握手而不是两次？关键答“防止失效连接请求”和“确认双方初始序号”；
- TCP和UDP最本质的区别是什么？别只说“一个可靠一个不可靠”，要具体到连接、确认、重传、排序、流控这些机制；
- 大量TIME_WAIT连接怎么处理？要能说出产生的场景和调整内核参数的思路；
- 如何判断一台服务器上某个端口是否开放？用telnet或nc测，而不是用ping；
- IP地址冲突会有什么现象？时通时断，交换机MAC表跳变，用
arp-scan这类工具扫一下就知道了。
答题的时候有一个通用技巧：不要只背结论，要把“因为所以”讲出来。面试官想听的其实是你有没有建立因果关系的能力，因为网络排障就是不断做因果推理的过程。
6.4 学习路径与实际场景结合的建议
把计算机网络学好，最有效的方式是“用学过的知识解释你每天看到的现象”。家里WiFi突然变慢，你可以想一下是无线信道干扰、路由器性能瓶颈还是出口带宽不足；公司网络某段时间视频会议卡顿，你可以从丢包、抖动、带宽占用几个维度去分析；你的web应用访问慢，先判断是TCP握手耗时、首字节耗时还是内容下载耗时。
建议把知识点组织成“网络是如何让一个请求完成的”这条主线，而不是按章节零散地背。当你对这条主线熟悉到可以随时展开细节时，考试、面试和实际排障都变成了同一件事。
有一个我反复实践的经验：每次学完一个协议，马上用Wireshark把对应的协议报文抓一遍，记录下来。这比看十遍书都管用。看到TCP连接的序列号从1000跳到2000再到3000的感觉，和你想象“TCP连接有一个序列号”的感觉，完全不是一回事。
计算机网络知识体系庞大，但核心脉络就那么几条：分层模型是骨架，IP是寻址基础，TCP提供了可靠传输的范式，HTTP定义了应用交互的规则。把这几个主干抓牢，其他的知识点都能顺着生长出来。在后面的工作和学习中，你会一次次重新遇到这些概念，每一次都会比上一次多懂一点。
