计算机网络基础Day02：从IP寻址到HTTPS握手，一文打通网络核心

1. 为什么“Day02”要从网络基础开始

昨天搭好环境之后，很多人会急着写代码、跑服务，但我强烈建议先花一整天把计算机网络基础啃下来。原因很简单：你写的每一个程序，本质上都在跟网络打交道——前端要发请求、后端要接请求、数据库要回数据、CDN要调度流量，哪怕你只是在自己电脑上调试，localhost 背后也是一整套网络协议的运转。

这一天的学习资料参考的是谢希仁老师的《计算机网络》教材体系，它的地位不用多说，国内高校几乎人手一本。但我要说的是，教材写得再经典，如果没有人帮你把“考点”和“实战”连起来，学完很容易变成“背会了七层模型，却解释不清为什么网页打开那么慢”。所以这篇笔记不打算照搬课本目录，而是把我在实际排查网络问题、写网络脚本时真正用到的知识点，按照“从整体到细节、从理论到动手”的顺序重新梳理一遍。

这篇内容适合谁？零基础想入行网络运维或后端开发的新人，准备校招面试的应届生，以及那些“用过 curl 但说不清 HTTPS 握手过程”的开发者。读完你能自己画出一台电脑访问一个网站时，数据包从网卡到服务器的完整路径，能看懂 ping、traceroute、curl -v 的输出到底在说什么，也能在面试被问到“从输入 URL 到页面展示发生了什么”时，给出有条理的回答。

废话不多说，直接进入正题。

2. 先建立全局视图：网络到底在解决什么问题

2.1 从“寄快递”理解网络模型的本质

我一直觉得，计算机网络入门的第一课不该是背七层模型，而应该先想一个问题：两台机器要通信，需要什么条件？

用寄快递来类比。你给远方的朋友寄一个包裹，需要什么？第一，你得有地址，而且这个地址是全球唯一的——对应 IP 地址。第二，包裹要能经过多个中转站，从你家楼下的快递点，到城市集散中心，再到目的地——对应路由器转发。第三，包裹里面得有个收件人姓名，不能只送到小区门口就完事——对应端口号。第四，包裹如果太大，快递公司会分装成好几个小箱子，到了目的地再重新拼起来——对应数据包的分片与重组。

但这里有个关键点：快递公司只管把包裹送到，它不关心你寄的是书、是衣服还是手机。网络也是一样，传输层只负责“数据可靠地从 A 端到 B 端”，至于数据是什么内容，是网页还是视频流，那是应用层的事。这种“分层”的设计，就是整个计算机网络体系结构的核心思想。

2.2 OSI 与 TCP/IP：为什么课本讲七层，实战只用四层

谢希仁教材里花了大篇幅讲 OSI 参考模型——物理层、数据链路层、网络层、传输层、会话层、表示层、应用层，一共七层。但现实世界里，真正跑在互联网上的 TCP/IP 协议族，是四层架构：网络接口层、网络层、传输层、应用层。

这里很多初学者会困惑：那到底该记七层还是四层？我的建议是两个都要记住，但要清楚它们的关系。OSI 是理论上的“理想模型”，设计得极其完备，但正因为完备，有些层在实现时根本不需要单独分出来——比如会话层和表示层的功能，在实际协议中要么被应用层自己处理，要么直接被跳过了。TCP/IP 是“工程上的妥协”，它的分层更粗糙，但每一层都有对应的、真实在跑的协议去落实。

我的记忆口诀是：“物链网传会表应，实际浓缩成四层。”面试时被问到 OSI 与 TCP/IP 的区别，标准答法是：OSI 是参考模型，法律意义上的“标准”；TCP/IP 是事实标准，真正在互联网上用的。

如果你今天只能记住一个结论，那就是：分层带来了解耦，模型带来了一致性，而 TCP/IP 的务实性让它赢下了这场协议战争。

3. 第二天的重头戏：IP、子网与地址的“游戏规则”

3.1 IPv4 地址与进制换算：别害怕二进制

很多人在学网络基础时，第一个崩溃点就是二进制换算。比如 IP 地址 192.168.1.100，看起来像四个十进制的数字，其实每个数字是 8 位二进制数。192 对应 11000000，168 对应 10101000，1 对应 00000001，100 对应 01100100。

为什么要理解这个？因为子网掩码的本质就是在二进制层面做“按位与”运算。举个例子，255.255.255.0 这个掩码在二进制下是 11111111 11111111 11111111 00000000。用 IP 地址和掩码做按位与运算，得到的是网络号；掩码中 0 的部分，就是主机号。

我建议在第二天就强迫自己掌握一个技能：看到 IP 地址和子网掩码，能立刻说出这个网络里有多少可用主机。公式是 2^(32-掩码位数) - 2，减去的 2 是网络地址和广播地址。

举个例子：192.168.1.0/24，掩码位数是 24，那么主机位是 8 位，可用主机数就是 2^8 - 2 = 254 个。如果你看到一个 /30 的子网，那只有 2^2 - 2 = 2 个可用地址——这正好是 PPP 链路两端各用一个地址的标准配置。

3.2 公网与私网地址：为什么你家路由器是 192.168 开头

TCP/IP 设计之初就预留了三段私网地址，任何人都可以使用，但路由器默认不会转发这些地址的数据包（在正常的公网路由场景下）：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。

这就是为什么你家路由器分配的地址几乎永远是 192.168.x.x。这些私网地址通过 NAT（网络地址转换）技术，把内网众多设备映射到一个公网 IP 上出外网。NAT 这个机制值得你花时间深入理解，因为现在绝大多数家庭和中小企业的网络结构都离不开它。

我实测中经常遇到一个误区：很多人以为“公网 IP 不够用了，所以 NAT 解决了 IP 短缺问题”。这句话对，但不完整。NAT 更重要的价值是安全性——它把内网设备“藏”在一个公网 IP 后面，外部主动发起的连接因为找不到内网设备，在默认情况下是建立不起来的。这也是你家里的摄像头、NAS 要做“端口映射”才能从外网访问的根本原因。

如果你手头有云服务器，可以用 ip addr 命令看一眼自己的网卡地址。如果你的是云服务器的私网 IP，再通过 curl ifconfig.me 查看出口公网 IP——你会发现两者完全不同，这就是 NAT 在中间工作的最直观证据。

3.3 子网划分实战：一道经典面试题的两种解法

下面这个例子是校招面试的高频题：某公司申请了一个 192.168.10.0/24 的网段，需要划分为 4 个子网，每个子网至少容纳 50 台主机，怎么分？

思路一：从主机数反推。50 台主机，至少需要 6 位主机位（2^6 = 64，去掉网络号和广播号，可用 62 台），那么网络位就是 32 - 6 = 26 位，也就是子网掩码 255.255.255.192。划分结果是：192.168.10.0/26、192.168.10.64/26、192.168.10.128/26、192.168.10.192/26。每个子网可用地址范围分别是 1~62、65~126、129~190、193~254。

思路二：从子网数反推。需要 4 个子网，说明要借用 2 位主机位（2^2 = 4），掩码从 /24 变成 /26，结果和上面一样。

实际操作中我会用网上的子网计算工具，但笔试和面试时必须手算。练熟之后你会发现，子网划分不过是“借主机位”的数学游戏，难点不在计算，而在判断该从哪个条件入手。

4. 传输层：TCP 的可靠性是如何被设计出来的

4.1 三次握手与四次挥手：把“状态机”刻进脑子里

TCP 的三次握手和四次挥手，是网络基础面试的“必考题中的必考题”。但我要强调，光会背 SYN、ACK 的序号还不够，你得理解每一方发这个包的目的。

三次握手的过程：

1. 客户端发送 SYN=1, seq=x，表示“我想和你建立连接”。
2. 服务端回复 SYN=1, ACK=1, seq=y, ack=x+1，表示“我收到了你的请求，我也有话想说”。
3. 客户端发送 ACK=1, seq=x+1, ack=y+1，表示“我收到了你的确认”。

为什么要三次而不是两次？因为 TCP 是全双工通信，双方都需要确认“对方能收到我的数据”。两次握手只能保证服务器收到客户端的 SYN，但客户端无法确认服务器是否收到自己的 ACK——如果丢包了，连接状态就对不上了。简单说，三次握手是“确认双方收发能力都正常”的最小握手次数。

四次挥手的核心区别在于，TCP 连接是双工的，断开时每一方向都要单独说再见。这也就是为什么会有 FIN 和 ACK 各两个包的原因。这里面有个常考细节：主动关闭方会进入 TIME_WAIT 状态，持续 2MSL（报文最大生存时间，通常为 2 分钟）。为什么要等待？一是为了确保最后一个 ACK 到达对方（如果丢了对方会重发 FIN），二是为了让连接上的残留数据包在网络中自然消亡，避免影响新连接。我见过不少线上故障，就是因为没有注意服务端大量 TIME_WAIT 连接堆积，导致端口被占满。

4.2 拥塞控制与流量控制：滑动窗口不是只滑动那么简单

流量控制是“接收方管发送方”，通过滑动窗口告诉对方“你先别发这么快，我处理不过来了”。拥塞控制则是“网络管发送方”，当网络拥堵时，发送方必须主动降速。

TCP 的拥塞控制有四个算法：慢开始、拥塞避免、快重传、快恢复。我记得第一次看教材时，觉得这套机制抽象。后来我用 tcpdump 观察一个慢速网络的传输过程，亲眼看到窗口呈阶梯形增长、然后断崖式下降，才真正理解“拥塞窗口”的含义。

这里分享一个排查经验：如果你写了一个下载工具，发现传输速率会周期性掉到 0 再缓慢爬升，大概率不是服务器限制带宽，而是 TCP 的拥塞控制算法在生效——网络往返时间（RTT）太大，或者丢包率升高，发送窗口被反复重置。这个现象在跨境传输场景特别常见。解决思路通常是优化路由、启用 TCP BBR 或者 WebRTC 这类基于 UDP 的协议来绕开 TCP 的线速限制。

4.3 UDP：看似简单，却在音视频领域大放异彩

与 TCP 相比，UDP 几乎没有可靠性机制，不保证顺序，不保证到达，不防丢包。但它的优点是无连接、头部开销小（8 字节 vs TCP 的 20 字节）、延迟低。

为什么现在的视频直播、语音电话、在线游戏都在用 UDP？因为在这些实时场景里，延迟比可靠更重要。视频通话中丢掉一个音频帧，远比重传一个 200ms 后到达的帧更有意义。丢帧只是瞬间卡顿，重传导致的累积延迟会让整个对话变得完全不可用。

实际工程里，很多“基于 UDP 的应用层协议”会在 UDP 之上自己实现可靠性：比如 QUIC（HTTP/3 的底层）在 UDP 上实现了类似 TCP 的连接管理、拥塞控制、多路复用，效果反而比 TCP 更好。学习网络基础时不要觉得 UDP 是“劣等 TCP”，它只是选择了不同的权衡点。

5. 网络层的转发逻辑与排查工具

5.1 路由器的工作原理：查表、拆封装、再封装

网络层的核心设备是路由器。它的工作流程可以概括为：收到一个 IP 数据报，检查目的地址，查询路由表，决定从哪个接口转发出去。

但这里有一个隐蔽的细节：路由器在转发数据包时，会修改数据链路层的地址（MAC 地址），但不会修改网络层的 IP 地址。每一跳的“目的地 MAC”都在变，而“目的 IP”始终不变。用快递做类比：包裹上的收件人地址（IP）是不变的，但每个中转站的标签（MAC）是临时贴上去的，到了下一站就撕掉换新的。

理解这一点对排查问题很有帮助。很多人用 traceroute 排查链路，发现每一跳的 IP 都不同，就以为数据包的“目的地”被修改了——其实不是，每一跳显示的只是当前经过的路由器接口 IP，真正的目的 IP 从头到尾没变过。

5.2 抓包与协议分析：把学到的知识“可视化”

理论学习到一定程度，必须上手抓包来巩固。推荐两个工具：Wireshark 和 tcpdump。Wireshark 适合 GUI 环境做交互分析，tcpdump 适合服务器上无图形环境的快速排查。

我第一次抓包看 TCP 三次握手时，是这么操作的：先在终端运行 tcpdump -i eth0 tcp port 80，然后在另一个终端执行 curl -v http://example.com，观察输出。你会清晰地看到 SYN、SYN-ACK、ACK 三个包的序号、标志位和时间戳。那一刻，课本上的抽象描述变成了眼前可以拆解的客观事实。

这里分享一个配置技巧：在 Wireshark 里设置显示过滤器 tcp.flags.syn == 1，可以快速过滤出所有握手的 SYN 包；设置 http.request 只看 HTTP 请求。抓包时有个坑——如果你在云服务器上抓包，会发现很多“不明来源”的扫描流量，这是因为公网 IP 时刻在被全网扫描器探测。这在云上很正常，不用恐慌，你要关注的是 LAN 环境内是否有异常的持续交互。

6. 应用层：从 URL 到网页，一次完整的“旅途”

6.1 DNS 解析过程：不只是一个“查表”那么简单

在地址栏输入 www.example.com 回车之后，第一个环节不是连接服务器，而是解析域名。DNS 解析看起来是“查一张表”，但它的机制远比想象中复杂，我把它拆成五个步骤：

1. 浏览器先查自己的缓存（Chrome 的 chrome://net-internals/#dns 可以查看）。
2. 没命中，去查操作系统缓存（Windows 用 ipconfig /displaydns 查看）。
3. 还没命中，去查本地 DNS 服务器（通常是路由器或运营商 DNS）。
4. 本地 DNS 服务器没有缓存，则向根域名服务器发起迭代查询。
5. 根服务器告诉它去查顶级域服务器（比如 .com 的服务器），顶级域服务器再告诉它去查权威域名服务器，最终拿到 IP 地址返回给浏览器。

整个过程我在实际排查时常用 dig 命令分步观察：

bash复制dig www.example.com A +trace

这个命令能逐级展示根服务器、.com 服务器、权威服务器返回的内容，非常直观。我在这里踩过一个坑：开发环境域名解析正常，但线上偶尔超时，最后发现是本地 DNS 服务器配置了两个上游 DNS，其中一个偶尔抽风，导致解析耗时长。解决方案是在 /etc/resolv.conf 里只保留一个稳定的 DNS 服务器，并设置了合理的超时时间。

6.2 HTTP 协议的状态码与报文结构

应用层里最常接触的协议就是 HTTP。你不需要把整个 RFC 背下来，但必须掌握状态码的分类逻辑：

• 1xx：信息性，比如 100 Continue
• 2xx：成功，比如 200 OK、204 No Content
• 3xx：重定向，比如 301 永久移动、302 临时移动
• 4xx：客户端错误，比如 400 请求有误、403 禁止访问、404 不存在
• 5xx：服务端错误，比如 500 服务器内部异常、502 网关异常、503 服务不可用

在调接口时，看到 4xx 第一反应应该是“检查我发的请求对不对”，看到 5xx 才应该去看服务器日志。很多新人拿到 500 就抓瞎，其实第一步是 tail -f 服务端日志，找到堆栈报错，而不是反复刷新页面。

HTTP 报文结构分请求行/状态行、首部行、空行、实体主体四部分。curl -v 命令可以完整展示这些头信息，强烈建议你跑一次：

bash复制curl -v https://www.example.com

看输出里的 > GET / HTTP/2 是请求头，< HTTP/2 200 是响应头，首部里的 content-type、set-cookie、cache-control 都是面试爱问的热门字段。

6.3 HTTPS：安全层的“加解密博弈”

HTTP 是明文传输，可以被中间人窃听和篡改，所以现在几乎全部切到 HTTPS。HTTPS 本质是 HTTP + TLS/SSL，核心机制分三步：

1. 客户端发送支持的加密套件列表和随机数给服务器。
2. 服务器返回证书（包含公钥和签名）。客户端验证证书是否可信（CA 是否受信任、域名是否匹配、是否过期）。
3. 双方通过密钥交换算法协商出会话密钥，之后的所有数据用对称加密传输。

这里总有人问：为什么非对称加密只用在握手阶段，之后改用对称加密？ 原因是性能。非对称加密（如 RSA）计算开销是同样强度对称加密的上百倍，如果所有数据都用它加密，网站的性能会崩掉。所以工程上的标准做法是：用非对称加密安全地传递对称密钥，再用对称加密高效传输数据。

排查 HTTPS 问题时，openssl s_client 是你的好帮手：

bash复制openssl s_client -connect example.com:443 -servername example.com

它能展示证书链、协议版本、加密套件、会话票据等全部握手信息，比浏览器按 F12 看证书详细得多。

7. 这一天的实操任务与学习心得

7.1 三步实操：从环境到抓包的完整闭环

第二天的学习不能停留在“看懂”，必须亲手做一遍。我建议按这个顺序：

第一步，用 ip a 或 ifconfig 查看本机网络配置，对照学到的概念，找到 IP 地址、子网掩码、网关、MAC 地址分别在哪里。

第二步，用 ping 和 traceroute 组合使用，确认网络连通性并看清每一跳节点。ping 的 -c 参数控制发包数，traceroute 的 -n 参数可以不做域名反解，输出更快。

第三步，用 Wireshark 完整抓取一次 curl 请求的全过程。观察 DNS 查询、TCP 握手、HTTP 请求响应、TCP 挥手的抓包序列，并把每个包的标志位、序号和课本上的描述做一一对应。

这三步做完，你会发现之前靠死记硬背的概念突然有了画面感。我在带新人时无数次验证过：能画出发包时序图的人，才是真正学懂网络基础的人。

7.2 易错点与高频面试题速查

下面这些是我在面试和带项目过程中总结出的高频易错点，整理成一张备忘表：

如果你在准备面试，这几个问题建议都能用 3 分钟以内的时间讲清楚：三次握手为什么不是两次；输入 URL 后的完整流程；TCP 与 UDP 如何选择；HTTP 状态码体系；HTTPS 的握手与加密策略。

7.3 给新人的一条实在建议：别贪多，把每个协议“跑通”一次

刚入门时我有个坏毛病，喜欢一口气看完一章就赶着看下一章，结果到后面发现前面的概念全忘了。后来我调整了策略：每学一个协议，就写一个能“触发”它的最小例子。学 HTTP 就起一个最简单的 Python HTTP 服务器用 curl 访问，学 HTTPS 就申请一个免费证书配置一遍，学 DNS 就用 dig 把每个查询级别都跑一遍。

这种“学一个、跑一个、抓包看一次”的节奏，比刷十遍书都高效。记忆会淡忘，但“我亲手抓到过那个 SYN 包”的画面感，会一直留在脑子里。

联网世界里的每一次点击，背后都是 IP 寻址、TCP 握手、DNS 解析、HTTP 请求这些基础模块在协同工作。Day02 的价值就在于此：它建立的是你对整个网络体系的空间感。之后无论学 VLAN、学 BGP、学 Kubernetes 网络，都是在今天这张认知地图上不断细化分支。

所以，别嫌今天的知识点“太基础”。基础从来都不是简单，而是所有复杂机制的底层公约数。把这一天学扎实了，后面会轻松得多。