1. 为什么"知识点摘要"这件事值得认真做
很多人看到"计算机网络知识点摘要"这个标题，第一反应是——这不就是考试前抄笔记吗？我一开始也这么想。但真正在工程实践中摸爬滚打几年之后，我发现一个扎心的事实：大部分网络问题的排查能力，取决于你对基础模型的记忆是否准确、是否成体系。不是"大概知道"，而是"能准确说出每一层干什么、数据单元叫什么、典型协议有哪些、出问题先查哪里"。
我见过太多这样的情况：一个接口调不通，有人上来就怀疑代码逻辑，查了半天发现是DNS解析超时；有人遇到连接偶发中断，第一反应是"服务端有bug"，实际上是TCP的keepalive没配、中间设备把空闲连接回收了。这些问题的根因都不在应用层代码，而在你对网络分层模型和协议行为的理解深度上。
所以这篇摘要不是给考试用的。它是给那些需要在实际工作中快速定位网络问题、需要和运维/后端/安全团队高效沟通、需要在自己脑子里建一张"网络全景图"的人用的。不管你是刚入行的开发、转岗的测试、还是需要补网络基础的运维，这份摘要都能帮你把零散的知识点串成一条线。
我整理这份摘要的原则是：不追求大而全，追求"能记住、能调用、能排查"。每个知识点都尽量回答三个问题——它是什么、它在哪一层、它出问题时会表现成什么样。下面我按自己的理解重新组织，不照搬教材目录，而是按"实际用得到的顺序"来排。
2. 分层模型：别背七层，先搞懂五层就够用了
2.1 OSI七层与TCP/IP四层的对应关系
教材上讲OSI七层模型：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。但实际工程中，会话层和表示层几乎不单独讨论，它们的功能被合并到了应用层里。所以真正干活时用的是TCP/IP四层模型：网络接口层、网络层、传输层、应用层。
我习惯用五层来记：物理层、数据链路层、网络层、传输层、应用层。这样既保留了OSI的清晰度，又贴近实际。
| 层次 | 数据单元 | 典型协议/设备 | 核心职责 | 出问题的典型表现 |
|---|---|---|---|---|
| 物理层 | 比特 | 网线、光纤、中继器 | 传输原始比特流 | 网卡灯不亮、链路不通 |
| 数据链路层 | 帧 | 以太网、交换机、MAC | 相邻节点间可靠传输 | MAC冲突、VLAN配置错误 |
| 网络层 | 包 | IP、ICMP、路由器 | 跨网络寻址与路由 | ping不通、路由环路 |
| 传输层 | 段/报文 | TCP、UDP | 端到端可靠/不可靠传输 | 端口不通、连接超时 |
| 应用层 | 数据 | HTTP、DNS、SMTP | 面向具体应用 | 域名解析失败、接口报错 |
这张表我建议你背下来。不是背文字，而是背"出问题的典型表现"那一列。因为排查问题时，你首先要知道"症状对应哪一层"，才能缩小范围。
2.2 封装与解封装：数据是怎么被"打包"的
很多人对封装的理解停留在"加个头"。但真正重要的是理解每一层加的头是给谁看的。
应用层数据往下传，传输层加TCP头（含源端口、目的端口、序列号等），网络层加IP头（含源IP、目的IP、TTL等），数据链路层加帧头帧尾（含源MAC、目的MAC、FCS校验）。接收端反过来一层层剥掉。
这里有个关键点：MAC地址只在同一局域网内有效，IP地址才是跨网络的全局标识。数据每经过一个路由器，帧头会被重新封装（源MAC和目的MAC变成下一跳的），但IP头基本不变（除了TTL减一）。理解这一点，你就能明白为什么"能ping通IP但访问不了域名"通常是DNS问题，而不是网络不通。
2.3 为什么分层思维能救命
分层思维最大的价值是隔离排查范围。遇到"网站打不开"，你可以按层往下查：
- 物理层：网线插了吗？WiFi连上了吗？
- 数据链路层：能ping通网关吗？
- 网络层：能ping通外网IP（如8.8.8.8）吗？
- 传输层：目标端口通吗？（telnet或nc测试）
- 应用层：DNS解析正常吗？HTTP返回什么状态码？
这个顺序不是随便定的，是从底层往上、从"更基础"到"更具体"。底层不通，上层肯定不通；底层通了上层不通，问题就在上层。我见过有人跳过前三步直接查应用日志，结果发现是网线松了——这种时间浪费完全可以通过分层排查避免。
提示：分层排查时，每一步都要有明确的"通过/不通过"判断标准。比如"能ping通网关"就是一个明确的判断点，不要用"感觉网络还行"这种模糊描述。
3. 传输层双雄：TCP和UDP的选择逻辑
3.1 TCP的三次握手与四次挥手，重点在状态变化
三次握手的过程大家都背过：SYN、SYN+ACK、ACK。但实际排查问题时，更重要的是状态机。
客户端发出SYN后进入SYN_SENT状态；收到SYN+ACK后进入ESTABLISHED；服务端收到SYN后进入SYN_RCVD，收到ACK后进入ESTABLISHED。如果服务端大量出现SYN_RCVD状态，说明有人在发SYN但没完成握手——这可能是SYN Flood攻击，也可能是客户端网络不稳定。
四次挥手：FIN、ACK、FIN、ACK。主动关闭方进入FIN_WAIT_1，收到ACK后进入FIN_WAIT_2，收到对方FIN后进入TIME_WAIT，等待2MSL后关闭。TIME_WAIT状态是排查中的高频词。大量TIME_WAIT会占用端口资源，但它是TCP可靠性的必要机制，不能简单"优化掉"。
我实际遇到过一个问题：某服务频繁创建短连接，导致TIME_WAIT堆积，新连接无法建立。解决方案不是关掉TIME_WAIT（那会破坏TCP可靠性），而是改用连接池复用连接。这就是理解状态机带来的实际价值。
3.2 TCP可靠传输的四个机制
TCP保证可靠传输靠四件事：序列号、确认应答、超时重传、流量控制。
序列号让接收端能按序重组数据；确认应答让发送端知道哪些数据被收到了；超时重传保证丢失的数据能被补发；流量控制（滑动窗口）防止发送端压垮接收端。后来还加了拥塞控制（慢启动、拥塞避免、快重传、快恢复），防止压垮网络本身。
这里有个容易混淆的点：流量控制是端到端的，拥塞控制是面向网络的。滑动窗口解决的是"接收端处理不过来"，拥塞窗口解决的是"网络中间设备处理不过来"。排查时如果发现传输速度上不去，要区分是接收端窗口太小还是网络拥塞。
3.3 UDP不是"不可靠"，而是"不保证"
很多人说UDP不可靠，这个说法不准确。UDP只是不提供可靠性保证，但你可以自己在应用层实现确认和重传。DNS用UDP是因为查询通常很小、一次请求一次响应，重传成本低；视频流用UDP是因为丢几帧比卡顿等待更可接受。
选择TCP还是UDP，核心判断标准是：你能接受数据丢失或乱序吗？不能就TCP，能就UDP。但要注意，即使选了UDP，也不意味着可以完全不管可靠性——很多基于UDP的协议（如QUIC）在应用层重新实现了可靠传输。
| 对比维度 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接 | 无连接 |
| 可靠性 | 保证可靠 | 不保证 |
| 传输效率 | 较低（有握手、确认） | 较高 |
| 适用场景 | 文件传输、网页、邮件 | 视频流、DNS、游戏 |
| 头部大小 | 20字节起 | 8字节 |
4. 应用层核心协议：DNS、HTTP、HTTPS
4.1 DNS解析：一切网络访问的起点
DNS把域名翻译成IP。解析过程是：浏览器缓存 → 系统缓存 → hosts文件 → 本地DNS服务器 → 根域名服务器 → 顶级域名服务器 → 权威域名服务器。任何一步出问题，都表现为"域名解析失败"。
排查DNS问题，我常用的命令是nslookup和dig。dig能显示完整的解析链路和耗时，比nslookup信息更全。如果dig能解析但浏览器打不开，问题就不在DNS，而在后续的TCP连接或HTTP请求。
注意：DNS默认用UDP 53端口，响应超过512字节时会改用TCP。如果防火墙只放行了UDP 53，大响应可能会失败。这是一个容易被忽略的坑。
4.2 HTTP请求的完整生命周期
从输入URL到页面展示，HTTP请求经历了：DNS解析 → TCP三次握手 → 发送HTTP请求 → 服务器处理 → 返回HTTP响应 → 浏览器渲染 → 四次挥手（或保持连接）。
HTTP/1.1默认开启Keep-Alive，连接可以复用。HTTP/2支持多路复用，一个连接上可以并行多个请求。HTTP/3基于QUIC（UDP），进一步减少了握手延迟。
排查HTTP问题，重点看状态码和头部信息。4xx是客户端问题（404资源不存在、403无权限），5xx是服务端问题（500内部错误、502网关错误、504网关超时）。502和504在微服务架构中特别常见，通常是网关后面的服务挂了或响应太慢。
4.3 HTTPS握手：比HTTP多了什么
HTTPS在HTTP和TCP之间加了TLS层。TLS握手过程包括：客户端发送支持的加密套件 → 服务端选择套件并返回证书 → 客户端验证证书 → 双方协商密钥 → 加密通信。
证书验证是关键。如果证书过期、域名不匹配、或签发机构不被信任，浏览器会报错。排查HTTPS问题，先看证书有效期和域名匹配，再看TLS版本和加密套件是否兼容。
我实际遇到过一个案例：某服务升级后，旧版客户端无法连接，原因是服务端只支持TLS 1.2+，而旧客户端只支持TLS 1.0。这不是"网络不通"，而是TLS协商失败。如果只查网络层，永远找不到原因。
5. 排查工具：会用这几个就够了
5.1 ping和traceroute：连通性与路径
ping测试网络层连通性，基于ICMP协议。能ping通说明IP层可达，但不代表端口开放或服务正常。traceroute（Windows上是tracert）显示数据包经过的每一跳，用来定位路由问题。
注意：有些服务器禁用了ICMP，ping不通不代表网络不通。这时候要用telnet或nc测试具体端口。
5.2 netstat和ss：连接状态一览
netstat -an显示所有连接和监听端口。ss -tuln是更现代的替代品，速度更快。重点看LISTEN状态（服务在监听）、ESTABLISHED（已建立连接）、TIME_WAIT（等待关闭）、CLOSE_WAIT（被动关闭但应用没关）。
CLOSE_WAIT大量堆积通常意味着应用程序没有正确关闭连接，这是代码问题，不是网络问题。这个区分很重要，能帮你把问题转给正确的团队。
5.3 tcpdump和Wireshark：抓包看真相
当所有间接手段都无法定位时，抓包是终极武器。tcpdump在命令行抓包，Wireshark图形化分析。重点看TCP三次握手是否完成、是否有RST包、是否有重传。
RST包通常表示连接被强制重置，可能是服务端端口未监听、防火墙拦截、或应用主动拒绝。看到RST，先查目标端口是否有服务在监听。
| 工具 | 适用场景 | 关键输出 |
|---|---|---|
| ping | 测试IP层连通性 | 延迟、丢包率 |
| traceroute | 定位路由路径 | 每一跳的IP和延迟 |
| netstat/ss | 查看连接状态 | LISTEN、ESTABLISHED、TIME_WAIT |
| tcpdump | 抓包分析 | 握手过程、RST、重传 |
| dig | DNS解析 | 解析结果、耗时、链路 |
6. 那些教材不写但实战中反复踩的坑
6.1 "能ping通但访问不了"的三种常见原因
第一种：目标端口没监听。ping走ICMP，访问走TCP，两者独立。用telnet IP 端口测试。
第二种：防火墙拦截。中间设备可能放行ICMP但拦截TCP。需要检查安全组、iptables、云平台网络ACL。
第三种：DNS问题。用IP能访问，用域名不行，基本就是DNS。检查/etc/resolv.conf和DNS服务器配置。
6.2 长连接被中间设备悄悄断开
很多云平台和负载均衡器有空闲连接超时设置，默认可能是60秒或300秒。如果应用的长连接超过这个时间没有数据传输，中间设备会悄悄断开，而两端应用可能都不知道。
解决方案：要么在应用层加心跳（定期发小包），要么调整中间设备的超时时间。TCP的keepalive也可以，但默认间隔太长（通常2小时），需要调整。
6.3 MTU和分片：大包发不出去的隐形杀手
MTU是最大传输单元，以太网默认1500字节。如果数据包超过MTU且设置了DF（不分片）标志，就会被丢弃。表现是：小请求正常，大请求超时或失败。
排查方法：用ping -s 1472 -M do 目标IP测试（1472+28=1500）。如果1472不通但1400通，说明路径MTU小于1500。解决方案是调整应用层发送大小或开启PMTUD（路径MTU发现）。
这个坑在跨运营商、跨地域的网络中特别常见，因为中间可能经过PPPoE（MTU 1492）或其他隧道。
6.4 本地hosts文件覆盖了DNS
有时候DNS配置没问题，但访问就是不对。检查/etc/hosts（Windows是C:\Windows\System32\drivers\etc\hosts），看是否有手动配置的解析记录。这个文件优先级高于DNS，容易被遗忘。
7. 怎么把这份摘要变成自己的东西
7.1 用"问题驱动"代替"目录驱动"复习
不要按教材目录从头背到尾。而是拿一张纸，写下你遇到过或听说过的网络问题，然后试着用分层模型去定位。比如"数据库连接偶尔超时"，你会怎么查？先看网络层是否丢包，再看传输层是否有重传，再看应用层连接池配置。
这种复习方式比死记硬背有效得多，因为它模拟了真实排查场景。
7.2 画一张自己的网络全景图
找一张白纸，画出从你的电脑到目标服务的完整链路：网卡 → 交换机 → 路由器 → 防火墙 → 负载均衡 → 服务器 → 应用。每一跳标注可能出问题的点和对应的排查工具。这张图不用给别人看，但画的过程会让你对"数据到底经过了什么"有更清晰的认识。
7.3 建立自己的"症状-原因"对照表
把工作中遇到的每个网络问题记录下来：症状是什么、排查过程是什么、最终原因是什么、用了什么工具。积累几个月，你就会有一张属于自己的排查速查表。这比任何教材都实用，因为它是你真实踩过的坑。
我个人在实际操作中的体会是：网络知识最大的价值不在于"知道多少协议"，而在于"遇到问题时能多快缩小范围"。分层模型和排查工具是两把钥匙，前者帮你定位到层，后者帮你定位到点。把这两样练熟，大部分网络问题都能在十分钟内找到方向。至于更深入的协议细节，可以在遇到具体问题时再针对性补，不需要一次性全背下来。
